Se connecter à Microsoft Entra ID avec un e-mail comme ID de connexion de substitution (Aperçu)

De nombreuses organisations souhaitent permettre aux utilisateurs de se connecter à Microsoft Entra ID en utilisant les informations d’identification de leur environnement de répertoire local. En vertu de cette approche, dite d’authentification hybride, les utilisateurs ne doivent se souvenir que d’un seul ensemble d’informations d’identification.

Certaines organisations n’ont pas adopté l’authentification hybride pour les raisons suivantes :

• Par défaut, le nom d’utilisateur principal (UPN) Microsoft Entra a la même valeur que l’UPN local.
• Le changement de l’UPN Microsoft Entra provoque une discordance entre l’environnement local et celui de Microsoft Entra, ce qui peut entraîner des problèmes avec certains services et applications.
• Pour des raisons commerciales ou de conformité, l’organisation ne souhaite pas utiliser l’UPN local pour se connecter à Microsoft Entra ID.

Pour adopter l’authentification hybride, vous pouvez configurer Microsoft Entra ID de façon à permettre aux utilisateurs de se connecter en utilisant leur e-mail comme autre ID de connexion. Par exemple, si Contoso a été rebaptisé Fabrikam, au lieu de continuer à se connecter avec l’UPN ana@contoso.com hérité, il est possible d’utiliser une adresse e-mail comme autre ID de connexion. Pour accéder à une application ou un service, les utilisateurs se connectent à Microsoft Entra ID avec leur e-mail non-UPN (par exemple, ana@fabrikam.com).

Cet article explique comment activer et utiliser une adresse e-mail comme ID de connexion de substitution.

Avant de commencer

Voici ce que vous devez savoir sur l’utilisation d’un e-mail comme autre ID de connexion :

• La fonctionnalité est disponible dans l’édition Microsoft Entra ID Gratuit et éditions supérieures.

• La fonctionnalité permet aux utilisateurs Microsoft Entra ID authentifiés dans le cloud de se connecter à l’aide de l’attribut ProxyAddresses, en plus du nom d’utilisateur principal (UPN). Pour en savoir plus sur la façon dont cela s’applique à la collaboration entre entreprises (B2B) Microsoft Entra, consultez la section B2B.

• Lorsqu’un utilisateur se connecte avec un e-mail non UPN, les revendications unique_name et preferred_username (le cas échéant) dans le jeton d’ID renvoient l’e-mail non UPN.

  • Si l’e-mail non UPN utilisé devient obsolète (n’appartient plus à l’utilisateur), ces revendications retournent l’UPN à la place.

• La fonctionnalité prend en charge l’authentification managée avec la synchronisation de la synthèse du mot de passe (PHS) ou l’authentification directe (PTA).

• Il y a deux options possibles pour configurer la fonctionnalité :

  • Stratégie de découverte du domaine d’accueil (HRD) : utilisez cette option pour activer la fonctionnalité sur l’ensemble du locataire. Au moins le rôle Administrateur d’application est requis.
  • Stratégie de déploiement par étapes : utilisez cette option pour tester la fonctionnalité avec des groupes Microsoft Entra spécifiques. Lorsque vous ajoutez pour la première fois un groupe de sécurité au déploiement par étapes, vous êtes limité à 200 utilisateurs pour éviter que l’expérience utilisateur n’expire. Une fois que vous avez ajouté le groupe, vous pouvez y ajouter directement d’autres utilisateurs, en fonction des besoins.

  Un administrateur général est nécessaire pour gérer cette fonctionnalité.

Limitations de la version préliminaire

Dans la préversion actuelle, les limitations suivantes s’appliquent à l’utilisation d’un e-mail comme autre ID de connexion :

• Expérience utilisateur : les utilisateurs peuvent voir leur UPN, même quand ils sont connectés avec leur e-mail non-UPN. L’exemple de comportement suivant peut être observé :

  • L’utilisateur est invité à se connecter avec l’UPN lorsqu’il est dirigé vers la connexion Microsoft Entra avec login_hint=<non-UPN email>.
  • Quand un utilisateur se connecte avec un e-mail non-UPN et qu’il entre un mot de passe incorrect, la page Entrez votre mot de passe change pour afficher l’UPN.
  • Sur certains sites et applications Microsoft, tels que Microsoft Office, le contrôle du gestionnaire de comptes, qui apparaît généralement en haut à droite, peut afficher l’UPN de l’utilisateur au lieu de l’e-mail non-UPN utilisé pour la connexion.

• Flux non pris en charge : certains flux ne sont actuellement pas compatibles avec les e-mails non-UPN, notamment :

  • Protection des ID Microsoft Entra ne fait pas correspondre les e-mails non-UPN avec la détection du risque Informations d’identification fuitées. Cette détection de risque utilise l’UPN pour faire correspondre les informations d’identification qui ont été divulguées. Pour plus d’informations, consultez Guide pratique : Examiner les risques.
  • Quand un utilisateur s’est connecté avec un e-mail non-UPN, il ne peut pas changer son mot de passe. La réinitialisation de mot de passe en libre-service (SSPR) Microsoft Entra fonctionne en principe comme prévu. Pendant le processus de réinitialisation de mot de passe en libre-service (SSPR), l’utilisateur peut voir son UPN s’il vérifie son identité avec un e-mail non UPN.

• Scénarios non pris en charge : les scénarios suivants ne sont pas pris en charge. Connexion avec un e-mail non UPN à :

  • Appareils connectés hybrides Microsoft Entra
  • Appareils joints à Microsoft Entra
  • Appareils enregistrés auprès de Microsoft Entra
  • Informations d’identification de mot de passe du propriétaire de ressource (ROPC)
  • Stratégies d’authentification unique et de protection des applications sur plateforme mobile
  • Authentification héritée de type POP3 et SMTP
  • Skype Entreprise

• Applications non prises en charge : certaines applications tierces peuvent ne pas fonctionner comme prévu si elles partent du principe que les revendications unique_name ou preferred_username sont immuables ou correspondent toujours à un attribut utilisateur spécifique, tel que UPN.

• Enregistrement : les modifications apportées à la configuration de la fonctionnalité dans la stratégie de découverte du domaine d’accueil ne sont pas explicitement indiquées dans les journaux d’audit.

• Stratégie de déploiement par étapes : les limitations suivantes s’appliquent uniquement lorsque la fonctionnalité est activée à l’aide de la stratégie de déploiement par étapes :

  • La fonctionnalité ne fonctionne pas comme prévu pour les utilisateurs qui sont inclus dans plusieurs stratégies de déploiement par étapes.
  • La stratégie de déploiement par étapes prend en charge un maximum de 10 groupes par fonctionnalité.
  • La stratégie de déploiement par étapes ne prend pas en charge les groupes imbriqués.
  • La stratégie de déploiement par étapes ne prend pas en charge les groupes d’appartenance dynamique.
  • Le contact d’objets à l’intérieur du groupe bloque l’ajout du groupe à une stratégie de déploiement par étapes.

• Valeurs dupliquées : au sein d’un abonné, un UPN d’utilisateur du cloud uniquement peut avoir la même valeur que l’adresse proxy d’un autre utilisateur, synchronisée à partir du répertoire local. Dans ce scénario, si la fonctionnalité est activée, l’utilisateur du cloud uniquement ne pourra pas se connecter au moyen de son UPN. Pour plus d’informations sur ce problème, consultez la section Dépanner.

Vue d’ensemble des options pour l’ID de connexion alternatif

Pour se connecter à Microsoft Entra ID, les utilisateurs entrent une valeur qui identifie leur compte de manière unique. Historiquement, vous pouviez uniquement utiliser l’UPN Microsoft Entra en tant qu’identificateur de connexion.

Pour les organisations dont l’UPN local correspond à l’adresse e-mail de connexion préférée de l’utilisateur, cette approche est intéressante. Ces organisations définissent l’UPN Microsoft Entra sur la même valeur que l’UPN local, et les utilisateurs bénéficient d’une expérience de connexion cohérente.

ID de connexion alternatif pour AD FS

Cela étant, dans certaines organisations, l’UPN local n’est pas utilisé comme identifiant de connexion. Dans les environnements locaux, vous configurez l’instance AD DS locale de façon à autoriser la connexion avec un ID de connexion alternatif. Définir l’UPN Microsoft Entra sur la même valeur que l’UPN local n’est pas possible, car le cas échéant, Microsoft Entra impose aux utilisateurs de se connecter avec cette valeur.

Autre ID de connexion dans Microsoft Entra Connect

La solution de contournement à ce problème consiste à définir l’UPN Microsoft Entra sur l’adresse e-mail que l’utilisateur envisage d’utiliser pour se connecter. Cette approche fonctionne, mais elle produit des UPN différents entre le domaine d’application local et Microsoft Entra ID. Qui plus est, cette configuration n’est pas compatible avec toutes les charges de travail Microsoft 365.

E-mail utilisé comme autre ID de connexion

Une autre approche consiste à synchroniser Microsoft Entra ID et les UPN locaux avec la même valeur, puis à configurer Microsoft Entra ID pour permettre aux utilisateurs de se connecter à Microsoft Entra ID avec un e-mail vérifié. Pour ce faire, vous définissez une ou plusieurs adresses e-mail dans l’attribut ProxyAddresses de l’utilisateur dans le répertoire local. ProxyAddresses sont ensuite synchronisées automatiquement avec Microsoft Entra ID à l’aide de Microsoft Entra Connect.

Synchroniser les adresses e-mail de connexion sur Microsoft Entra ID

L’authentification traditionnelle d’Active Directory Domain Services (AD DS) ou des services de fédération Active Directory (AD FS) s’effectue directement sur votre réseau et est gérée par votre infrastructure AD DS. Avec une authentification hybride, les utilisateurs peuvent se connecter directement à Microsoft Entra ID.

Pour prendre en charge cette approche d’authentification hybride, vous synchronisez votre environnement AD DS local sur Microsoft Entra ID à l’aide de Microsoft Entra Connect et le configurez pour utiliser PHS ou PTA. Pour plus d’informations, consultez Choisir la méthode d’authentification adaptée à votre solution d’identité hybride Microsoft Entra.

Dans les deux options de configuration, l’utilisateur envoie son nom d’utilisateur et son mot de passe à Microsoft Entra ID qui valide les informations d’identification et émet un ticket. Lorsque les utilisateurs se connectent à Microsoft Entra ID, cela évite à votre organisation de devoir héberger et gérer une infrastructure AD FS.

L’un des attributs utilisateur automatiquement synchronisés par Microsoft Entra Connect est ProxyAddresses. Si un utilisateur a une adresse e-mail définie dans l’environnement AD DS local comme faisant partie de l’attribut ProxyAddresses, cette adresse est automatiquement synchronisée avec Microsoft Entra. Cette adresse e-mail peut ensuite être utilisée directement dans le processus de connexion Microsoft Entra en tant qu’ID de connexion alternatif.

Connexion B2B des utilisateurs invités avec une adresse e-mail

L’utilisation d’une adresse e-mail comme autre ID de connexion s’applique à la collaboration B2B Microsoft Entra selon le modèle « Apportez vos propres identifiants de connexion ». Lorsque l’utilisation d’une adresse e-mail comme autre ID de connexion est activée dans le tenant principal, les utilisateurs Microsoft Entra peuvent effectuer des connexions d’invité avec une adresse e-mail non UPN sur le point de terminaison du tenant de la ressource. Aucune action n’est requise du locataire de ressources pour activer cette fonctionnalité.

Permettre à un utilisateur de se connecter avec une adresse e-mail

Une fois que les utilisateurs auxquels l’attribut ProxyAddresses est appliqué sont synchronisés avec Microsoft Entra ID à l’aide de Microsoft Entra Connect, vous devez activer la fonctionnalité pour que les utilisateurs se connectent avec leur adresse e-mail en guise d’ID de connexion alternatif pour votre tenant. Cette fonctionnalité indique aux serveurs de connexion Microsoft Entra de vérifier l’identificateur de connexion non seulement par rapport aux valeurs d’UPN, mais aussi par rapport aux valeurs de l’attribut ProxyAddresses pour l’adresse e-mail.

Vous pouvez utiliser le Centre d’administration Microsoft Entra ou Graph PowerShell pour configurer la fonctionnalité.

Un administrateur général est nécessaire pour gérer cette fonctionnalité.

Centre d'administration Microsoft Entra

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’Administrateur général.

2. Dans le menu de navigation à gauche de la fenêtre Microsoft Entra, sélectionnez l’e-mail de Microsoft Entra Connect > comme autre ID de connexion.

   

3. Cochez la case à côté de E-mail comme ID de connexion secondaire.

4. Cliquez sur Enregistrer.

   

Une fois la stratégie appliquée, il peut falloir jusqu’à une heure pour qu’elle se propage et que les utilisateurs puissent se connecter avec leur ID de connexion alternatif.

PowerShell

Une fois que les utilisateurs auxquels l’attribut ProxyAddresses est appliqué sont synchronisés avec Microsoft Entra ID à l’aide de Microsoft Entra Connect, vous devez activer la fonctionnalité pour que les utilisateurs se connectent avec leur adresse e-mail en guise d’ID de connexion alternatif pour votre tenant. Cette fonctionnalité indique aux serveurs de connexion Microsoft Entra de vérifier l’identificateur de connexion non seulement par rapport aux valeurs d’UPN, mais aussi par rapport aux valeurs de l’attribut ProxyAddresses pour l’adresse e-mail.

Un administrateur général est nécessaire pour gérer cette fonctionnalité.

1. Ouvrez une session PowerShell comme administrateur, puis installez le module Microsoft.Graph avec l’applet de commande Install-Module :

   Install-Module Microsoft.Graph
   

   Pour plus d’informations sur l’installation, consultez Installer le SDK PowerShell Microsoft Graph.

2. Connectez-vous à votre tenant Microsoft Entra à l’aide de la cmdlet Connect-MgGraph :

   Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration" -TenantId organizations
   

   La commande vous demande de vous authentifier dans un navigateur web.

3. Vérifiez si HomeRealmDiscoveryPolicy existe déjà dans votre locataire en utilisant l’applet de commande Get-MgPolicyHomeRealmDiscoveryPolicy comme suit :

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

4. Si aucune stratégie n’est actuellement configurée, la commande ne retourne rien. Si une stratégie est retournée, ignorez cette étape et passez à l’étape suivante pour mettre à jour une stratégie existante.

   Pour ajouter HomeRealmDiscoveryPolicy au locataire, utilisez l’applet de commande New-MgPolicyHomeRealmDiscoveryPolicy et définissez l’attribut AlternateIdLogin sur « Enabled » : true comme dans l’exemple suivant :

   $AzureADPolicyDefinition = @(
     @{
        "HomeRealmDiscoveryPolicy" = @{
           "AlternateIdLogin" = @{
              "Enabled" = $true
           }
        }
     } | ConvertTo-JSON -Compress
   )
   
   $AzureADPolicyParameters = @{
     Definition            = $AzureADPolicyDefinition
     DisplayName           = "BasicAutoAccelerationPolicy"
     AdditionalProperties  = @{ IsOrganizationDefault = $true }
   }
   
   New-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
   

   Une fois la stratégie créée, la commande renvoie l’ID de stratégie, comme illustré dans l’exemple de sortie suivant :

   Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
   ----------                                                           --------------- ----------- -----------                 --            ---------------------
   {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
   

5. Si une stratégie est déjà configurée, vérifiez si l’attribut AlternateIdLogin est activé, comme le montre l’exemple de sortie de stratégie suivant :

   Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
   ----------                                                           --------------- ----------- -----------                 --            ---------------------
   {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
   

   Si la stratégie existe mais que l’attribut AlternateIdLogin n’est pas présent ou activé, ou s’il existe sur la stratégie d’autres attributs que vous souhaitez conserver, mettez à jour la stratégie existante à l’aide de la cmdlet Update-MgPolicyHomeRealmDiscoveryPolicy.

   Important

   Lorsque vous mettez à jour la stratégie, veillez à inclure les anciens paramètres et le nouvel attribut AlternateIdLogin.

   L’exemple suivant ajoute l’attribut AlternateIdLogin et conserve l’attribut AllowCloudPasswordValidation précédemment défini :

   $AzureADPolicyDefinition = @(
     @{
        "HomeRealmDiscoveryPolicy" = @{
           "AllowCloudPasswordValidation" = $true
           "AlternateIdLogin" = @{
              "Enabled" = $true
           }
        }
     } | ConvertTo-JSON -Compress
   )
   
   $AzureADPolicyParameters = @{
     HomeRealmDiscoveryPolicyId = "HRD_POLICY_ID"
     Definition                 = $AzureADPolicyDefinition
     DisplayName                = "BasicAutoAccelerationPolicy"
     AdditionalProperties       = @{ "IsOrganizationDefault" = $true }
   }
   
   Update-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
   

   Vérifiez que la stratégie mise à jour affiche vos modifications et que l’attribut AlternateIdLogin est désormais activé :

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Suppression de stratégies

Pour supprimer une stratégie HRD, utilisez l’applet de commande Remove-MgPolicyHomeRealmDiscoveryPolicy :

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

Activer le lancement intermédiaire pour tester la connexion de l’utilisateur avec une adresse e-mail

La stratégie de déploiement par étapes permet aux administrateurs tenant d’activer des fonctionnalités pour des groupes Microsoft Entra spécifiques. Il est recommandé aux administrateurs du locataire d’utiliser le lancement intermédiaire pour tester la connexion de l’utilisateur avec une adresse e-mail. Lorsque les administrateurs sont prêts à déployer cette fonctionnalité sur la totalité de leur locataire, ils doivent utiliser une stratégie de découverte du domaine d’accueil (HRD).

Un administrateur général est nécessaire pour gérer cette fonctionnalité.

1. Ouvrez une session PowerShell en tant qu’administrateur, puis installez le module Microsoft.Graph.Beta à l’aide du cmdlet Install-Module :

   Install-Module Microsoft.Graph.Beta
   

   Si vous y êtes invité, sélectionnez Y pour installer NuGet ou pour installer à partir d’un dépôt non approuvé.

2. Connectez-vous à votre locataire Microsoft Entra à l’aide du cmdlet Connect-MgGraph :

   Connect-MgGraph -Scopes "Directory.ReadWrite.All"
   

   La commande retourne des informations sur votre compte, votre environnement et votre ID de locataire.

3. Répertoriez toutes les stratégies de lancement intermédiaires existantes à l’aide de la cmdlet suivante :

   Get-MgBetaPolicyFeatureRolloutPolicy
   

4. S’il n’existe aucune stratégie de lancement intermédiaire pour cette fonctionnalité, créez une stratégie de lancement intermédiaire et prenez note de l’ID de stratégie :

   $MgPolicyFeatureRolloutPolicy = @{
   Feature    = "EmailAsAlternateId"
   DisplayName = "EmailAsAlternateId Rollout Policy"
   IsEnabled   = $true
   }
   New-MgBetaPolicyFeatureRolloutPolicy @MgPolicyFeatureRolloutPolicy
   

5. Recherchez l’ID directoryObject du groupe à ajouter à la stratégie de lancement intermédiaire. Notez la valeur retournée pour le paramètre ID, car elle sera utilisée à l’étape suivante.

   Get-MgBetaGroup -Filter "DisplayName eq 'Name of group to be added to the staged rollout policy'"
   

6. Ajoutez le groupe à la stratégie de lancement intermédiaire, comme indiqué dans l’exemple suivant. Remplacez la valeur du paramètre -FeatureRolloutPolicyId par la valeur retournée pour l’ID de stratégie à l’étape 4 et remplacez la valeur du paramètre -OdataId par l’ID noté à l’étape 5. Il peut falloir jusqu’à 1 heure avant que les utilisateurs membres du groupe puissent se connecter à Microsoft Entra ID en utilisant leur e-mail comme autre ID de connexion.

   New-MgBetaDirectoryFeatureRolloutPolicyApplyToByRef `
      -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" `
      -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/{GROUP_OBJECT_ID}"
   

Pour les nouveaux membres ajoutés au groupe, ce délai peut aller jusqu’à 24 heures avant qu’ils puissent se connecter à Microsoft Entra ID en utilisant leur e-mail comme autre ID de connexion.

Suppression de groupes

Pour supprimer un groupe d’une stratégie de lancement intermédiaire, exécutez la commande suivante :

Remove-MgBetaPolicyFeatureRolloutPolicyApplyToByRef -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -DirectoryObjectId "GROUP_OBJECT_ID"

Suppression de stratégies

Pour supprimer une stratégie de lancement intermédiaire, commencez par désactiver la stratégie, puis supprimez-la du système :

Update-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -IsEnabled:$false 
Remove-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID"

Tester la connexion des utilisateurs avec une adresse e-mail

Pour tester la possibilité de connexion des utilisateurs au moyen de l’e-mail, accédez à https://myprofile.microsoft.com et connectez-vous avec un e-mail non UPN (par exemple, balas@fabrikam.com ). L’expérience de connexion doit être similaire à celle de la connexion avec l’UPN.

Détecter un problème

Si des utilisateurs rencontrent des difficultés à se connecter avec leur adresse e-mail, essayez les étapes de dépannage suivantes :

1. Assurez-vous qu’au moins une heure s’est écoulée depuis l’activation de l’e-mail comme ID de connexion alternatif. Si l’utilisateur a récemment été ajouté à un groupe pour la stratégie de déploiement par étapes, assurez-vous que son ajout date de plus de 24 heures.

2. Si vous utilisez la stratégie de découverte du domaine d’accueil, vérifiez que la ressource HomeRealmDiscoveryPolicy de Microsoft Entra ID a sa propriété AlternateIdLogin définie sur "Enabled" : true et sa propriété IsOrganizationDefault définie sur True :

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Si vous utilisez la stratégie de déploiement par étapes, vérifiez que la ressource FeatureRolloutPolicy de Microsoft Entra ID a sa propriété IsEnabled définie sur True :

   Get-MgBetaPolicyFeatureRolloutPolicy
   

3. Vérifiez que l’adresse e-mail du compte d’utilisateur est définie dans l’attribut ProxyAddresses dans Microsoft Entra ID.

Journaux de connexion

Vous pouvez consulter les journaux de connexion dans Microsoft Entra ID pour plus d’informations. Les connexions avec l’e-mail comme ID de connexion secondaire envoient proxyAddress dans le champ Type d’identificateur de connexion et le nom d’utilisateur entré dans le champ Identificateur de connexion.

Valeurs conflictuelles entre les utilisateurs du cloud uniquement et les utilisateurs synchronisés

Au sein d’un locataire, l’UPN d’un utilisateur du cloud uniquement peut avoir la même valeur que l’adresse proxy d’un autre utilisateur, synchronisée à partir de l’annuaire local. Dans ce scénario, si la fonctionnalité est activée, l’utilisateur du cloud uniquement ne pourra pas se connecter au moyen de son UPN. Voici les étapes à suivre pour détecter les instances de ce problème.

1. Ouvrez une session PowerShell en tant qu’administrateur, puis installez le module AzureADPreview à l’aide de la cmdlet Install-Module :

   Install-Module Microsoft.Graph.Beta
   

   Si vous y êtes invité, sélectionnez Y pour installer NuGet ou pour installer à partir d’un dépôt non approuvé.

2. Un administrateur général est nécessaire pour gérer cette fonctionnalité.

   Connectez-vous à votre client Microsoft Entra à l’aide de la cmdlet Connect-AzureAD :

   Connect-MgGraph -Scopes "User.Read.All"
   

3. Obtenez les utilisateurs affectés.

   # Get all users
   $allUsers = Get-MgUser -All
   
   # Get list of proxy addresses from all synced users
   $syncedProxyAddresses = $allUsers |
       Where-Object {$_.ImmutableId} |
       Select-Object -ExpandProperty ProxyAddresses |
       ForEach-Object {$_ -Replace "smtp:", ""}
   
   # Get list of user principal names from all cloud-only users
   $cloudOnlyUserPrincipalNames = $allUsers |
       Where-Object {!$_.ImmutableId} |
       Select-Object -ExpandProperty UserPrincipalName
   
   # Get intersection of two lists
   $duplicateValues = $syncedProxyAddresses |
       Where-Object {$cloudOnlyUserPrincipalNames -Contains $_}
   

4. Pour lister les utilisateurs affectés :

   # Output affected synced users
   $allUsers |
       Where-Object {$_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0} |
       Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
   
   # Output affected cloud-only users
   $allUsers |
       Where-Object {!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName} |
       Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
   

5. Pour lister les utilisateurs affectés dans un fichier CSV :

   # Output affected users to CSV
   $allUsers |
       Where-Object {
           ($_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0) -Or
           (!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName)
       } |
       Select-Object ObjectId, DisplayName, UserPrincipalName, @{n="ProxyAddresses"; e={$_.ProxyAddresses -Join ','}}, @{n="IsSyncedUser"; e={$_.ImmutableId.Length -GT 0}}, UserType |
       Export-Csv -Path .\AffectedUsers.csv -NoTypeInformation
   

Étapes suivantes

Pour en savoir plus sur l’identité hybride, comme le proxy d’application Microsoft Entra ou Microsoft Entra Domain Services, consultez l’identité hybride Microsoft Entra pour l’accès et la gestion des charges de travail locales.

Pour plus d’informations sur les opérations d’identité hybrides, voyez comment fonctionnent les synchronisations par hachage de mot de passe et par authentification directe.