Logga in i Microsoft Entra ID med en e-postadress som alternativt inloggnings-ID (förhandsversion)

Kommentar

Inloggning till Microsoft Entra-ID med e-post som alternativt inloggnings-ID är en offentlig förhandsversionsfunktion i Microsoft Entra-ID. Mer information om förhandsversioner finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Många organisationer vill låta användare logga in på Microsoft Entra-ID med samma autentiseringsuppgifter som sin lokala katalogmiljö. Med den här metoden, som kallas hybridautentisering, behöver användarna bara komma ihåg en uppsättning autentiseringsuppgifter.

Vissa organisationer har inte övergått till hybridautentisering av följande skäl:

• Som standard är Microsoft Entra-användarens huvudnamn (UPN) inställt på samma värde som det lokala UPN:t.
• Om du ändrar Microsoft Entra UPN skapas ett matchningsfel mellan lokala miljöer och Microsoft Entra-miljöer som kan orsaka problem med vissa program och tjänster.
• På grund av affärs- eller efterlevnadsskäl vill organisationen inte använda det lokala UPN:t för att logga in på Microsoft Entra-ID.

För att gå mot hybridautentisering kan du konfigurera Microsoft Entra-ID så att användarna kan logga in med sin e-post som ett alternativt inloggnings-ID. Om Contoso till exempel byter namn till Fabrikam, i stället för att fortsätta logga in med det äldre ana@contoso.com UPN:t, kan e-post som ett alternativt inloggnings-ID användas. För att få åtkomst till ett program eller en tjänst loggar användarna in på Microsoft Entra-ID med sin icke-UPN-e-post, till exempel ana@fabrikam.com.

Den här artikeln visar hur du aktiverar och använder e-post som ett alternativt inloggnings-ID.

Innan du börjar

Här är vad du behöver veta om e-post som ett alternativt inloggnings-ID:

• Funktionen är tillgänglig i Microsoft Entra ID Free Edition och senare.

• Funktionen möjliggör inloggning med ProxyAddresses, förutom UPN, för molnautentiserade Microsoft Entra-användare. Mer information om hur detta gäller för Microsoft Entra-samarbete mellan företag (B2B) i B2B-avsnittet .

• När en användare loggar in med ett icke-UPN-e-postmeddelande returnerar anspråken unique_name och preferred_username (om de finns) i ID-token det icke-UPN-e-postmeddelandet.

  • Om det icke-UPN-e-postmeddelande som används blir inaktuellt (tillhör inte längre användaren) returnerar dessa anspråk UPN i stället.

• Funktionen stöder hanterad autentisering med synkronisering av lösenordshash (PHS) eller direktautentisering (PTA).

• Det finns två alternativ för att konfigurera funktionen:

  • Princip för identifiering av hemsfär (HRD) – Använd det här alternativet för att aktivera funktionen för hela klientorganisationen. Programadministratörsrollen krävs åtminstone.
  • Stegvis distributionsprincip – Använd det här alternativet för att testa funktionen med specifika Microsoft Entra-grupper. När du först lägger till en säkerhetsgrupp för stegvis distribution är du begränsad till 200 användare för att undvika en tidsgräns för UX. När du har lagt till gruppen kan du lägga till fler användare direkt till den efter behov.

  En global administratör krävs för att hantera den här funktionen.

Begränsningar i förhandsversionen

I det aktuella förhandsversionstillståndet gäller följande begränsningar för e-post som ett alternativt inloggnings-ID:

• Användarupplevelse – Användarna kan se sitt UPN, även när de har loggat in med sin icke-UPN-e-post. Följande exempelbeteende kan ses:

  • Användaren uppmanas att logga in med UPN när den dirigeras till Microsoft Entra-inloggning med login_hint=<non-UPN email>.
  • När en användare loggar in med ett icke-UPN-e-postmeddelande och anger ett felaktigt lösenord ändras sidan "Ange ditt lösenord" för att visa UPN.
  • På vissa Microsoft-webbplatser och -appar, till exempel Microsoft Office, kan account manager-kontrollen som vanligtvis visas i det övre högra hörnet visa användarens UPN i stället för det icke-UPN-e-postmeddelande som används för att logga in.

• Flöden som inte stöds – Vissa flöden är för närvarande inte kompatibla med icke-UPN-e-postmeddelanden, till exempel följande:

  • Microsoft Entra ID Protection matchar inte icke-UPN-e-postmeddelanden med riskidentifiering av läckta autentiseringsuppgifter . Den här riskidentifieringen använder UPN för att matcha autentiseringsuppgifter som har läckt ut. Mer information finns i Så här: Undersöka risker.
  • När en användare är inloggad med ett icke-UPN-e-postmeddelande kan de inte ändra sitt lösenord. Microsoft Entra-självbetjäning av lösenordsåterställning (SSPR) bör fungera som förväntat. Under SSPR kan användaren se sitt UPN om de verifierar sin identitet med hjälp av ett icke-UPN-e-postmeddelande.

• Scenarier som inte stöds – Följande scenarier stöds inte. Logga in med icke-UPN-e-post för:

  • Microsoft Entra Hybrid-anslutna enheter
  • Microsoft Entra-anslutna enheter
  • Microsoft Entra-registrerade enheter
  • Autentiseringsuppgifter för resursägares lösenord (ROPC)
  • Principer för enkel inloggning och appskydd på mobilplattform
  • Föråldrad autentisering som POP3 och SMTP
  • Skype för företag

• Appar som inte stöds – Vissa program från tredje part kanske inte fungerar som förväntat om de antar att anspråken unique_name eller preferred_username är oföränderliga eller alltid matchar ett specifikt användarattribut, till exempel UPN.

• Loggning – Ändringar som gjorts i funktionens konfiguration i HRD-principen visas inte uttryckligen i granskningsloggarna.

• Stegvis distributionsprincip – Följande begränsningar gäller endast när funktionen är aktiverad med hjälp av stegvis distributionsprincip:

  • Funktionen fungerar inte som förväntat för användare som ingår i andra stegvisa distributionsprinciper.
  • Stegvis distributionsprincip stöder högst 10 grupper per funktion.
  • Stegvis distributionsprincip stöder inte kapslade grupper.
  • Stegvis distributionsprincip stöder inte dynamiska medlemskapsgrupper.
  • Kontaktobjekt i gruppen blockerar gruppen från att läggas till i en stegvis distributionsprincip.

• Duplicerade värden – I en klientorganisation kan en användares UPN för endast molnet vara samma värde som en annan användares proxyadress som synkroniseras från den lokala katalogen. I det här scenariot, med funktionen aktiverad, kommer den molnbaserade användaren inte att kunna logga in med sitt UPN. Mer information om det här problemet finns i avsnittet Felsök .

Översikt över alternativ för alternativ för inloggnings-ID

Om du vill logga in på Microsoft Entra-ID anger användarna ett värde som unikt identifierar deras konto. Tidigare kunde du bara använda Microsoft Entra UPN som inloggningsidentifierare.

För organisationer där det lokala UPN:t är användarens föredragna e-post för inloggning var den här metoden bra. Dessa organisationer skulle ange Microsoft Entra UPN till exakt samma värde som det lokala UPN och användarna skulle ha en konsekvent inloggningsupplevelse.

Alternativt inloggnings-ID för AD FS

I vissa organisationer används dock inte det lokala UPN:t som inloggningsidentifierare. I de lokala miljöerna konfigurerar du den lokala AD DS för att tillåta inloggning med ett alternativt inloggnings-ID. Att ställa in Microsoft Entra UPN till samma värde som det lokala UPN är inte ett alternativ eftersom Microsoft Entra-ID:t då kräver att användarna loggar in med det värdet.

Alternativt inloggnings-ID i Microsoft Entra Connect

Den vanliga lösningen på det här problemet var att ställa in Microsoft Entra UPN på den e-postadress som användaren förväntar sig att logga in med. Den här metoden fungerar, men resulterar i olika UPN:er mellan det lokala AD- och Microsoft Entra-ID:t, och den här konfigurationen är inte kompatibel med alla Microsoft 365-arbetsbelastningar.

E-post som alternativt inloggnings-ID

En annan metod är att synkronisera Microsoft Entra-ID och lokala UPN:er till samma värde och sedan konfigurera Microsoft Entra-ID så att användare kan logga in på Microsoft Entra-ID med ett verifierat e-postmeddelande. För att ge den här möjligheten definierar du en eller flera e-postadresser i användarens ProxyAddresses-attribut i den lokala katalogen. ProxyAddresses synkroniseras sedan automatiskt med Microsoft Entra ID med Hjälp av Microsoft Entra Connect.

Alternativ	Description
Alternativt inloggnings-ID för AD FS	Aktivera inloggning med ett alternativt attribut (till exempel e-post) för AD FS-användare.
Alternativt inloggnings-ID i Microsoft Entra Connect	Synkronisera ett alternativt attribut (till exempel e-post) som Microsoft Entra UPN.
E-post som alternativt inloggnings-ID	Aktivera inloggning med verifierad domän ProxyAddresses för Microsoft Entra-användare.

Synkronisera inloggnings-e-postadresser till Microsoft Entra-ID

Traditionell autentisering med Active Directory-domän Services (AD DS) eller Active Directory Federation Services (AD FS) (AD FS) sker direkt i nätverket och hanteras av DIN AD DS-infrastruktur. Med hybridautentisering kan användarna i stället logga in direkt på Microsoft Entra-ID.

För att stödja den här hybridautentiseringsmetoden synkroniserar du din lokala AD DS-miljö med Microsoft Entra ID med hjälp av Microsoft Entra Connect och konfigurerar den så att den använder PHS eller PTA. Mer information finns i Välj rätt autentiseringsmetod för din Hybrididentitetslösning för Microsoft Entra.

I båda konfigurationsalternativen skickar användaren sitt användarnamn och lösenord till Microsoft Entra-ID, vilket validerar autentiseringsuppgifterna och utfärdar ett ärende. När användare loggar in på Microsoft Entra-ID tar det bort behovet av att din organisation är värd för och hanterar en AD FS-infrastruktur.

Ett av de användarattribut som automatiskt synkroniseras av Microsoft Entra Connect är ProxyAddresses. Om användarna har en e-postadress som definierats i den lokala AD DS-miljön som en del av attributet ProxyAddresses synkroniseras den automatiskt med Microsoft Entra-ID. Den här e-postadressen kan sedan användas direkt i Inloggningsprocessen för Microsoft Entra som ett alternativt inloggnings-ID.

Viktigt!

Endast e-postmeddelanden i verifierade domäner för klientorganisationen synkroniseras med Microsoft Entra-ID. Varje Microsoft Entra-klientorganisation har en eller flera verifierade domäner som du har beprövat ägarskap för och som är unikt bundna till din klientorganisation.

Mer information finns i Lägga till och verifiera ett anpassat domännamn i Microsoft Entra-ID.

B2B-gästanvändare loggar in med en e-postadress

E-post som alternativt inloggnings-ID gäller för Microsoft Entra B2B-samarbete under en "bring your own sign-in identifiers"-modell. När e-post som ett alternativt inloggnings-ID är aktiverat i hemklientorganisationen kan Microsoft Entra-användare utföra gästinloggning med icke-UPN-e-post på resursklientslutpunkten. Ingen åtgärd krävs från resursklientorganisationen för att aktivera den här funktionen.

Kommentar

När ett alternativt inloggnings-ID används på en resursklientslutpunkt som inte har funktionen aktiverad fungerar inloggningsprocessen sömlöst, men enkel inloggning avbryts.

Aktivera användarinloggning med en e-postadress

Kommentar

Det här konfigurationsalternativet använder HRD-princip. Mer information finns i resurstypen homeRealmDiscoveryPolicy.

När användare med attributet ProxyAddresses har synkroniserats med Microsoft Entra-ID med hjälp av Microsoft Entra Connect måste du aktivera funktionen för användare att logga in med e-post som ett alternativt inloggnings-ID för din klientorganisation. Den här funktionen instruerar Microsoft Entra-inloggningsservrarna att inte bara kontrollera inloggningsidentifieraren mot UPN-värden, utan även mot ProxyAddresses-värden för e-postadressen.

Du kan använda antingen Administrationscenter för Microsoft Entra eller Graph PowerShell för att konfigurera funktionen.

En global administratör krävs för att hantera den här funktionen.

Microsoft Entra administrationscenter

Dricks

Stegen i den här artikeln kan variera något beroende på vilken portal du börjar från.

1. Logga in på administrationscentret för Microsoft Entra som global administratör.

2. På navigeringsmenyn till vänster i Microsoft Entra-fönstret väljer du Microsoft Entra Connect > Email som alternativt inloggnings-ID.

   

3. Klicka på kryssrutan bredvid E-post som ett alternativt inloggnings-ID.

4. Klicka på Spara.

   

Med principen tillämpad kan det ta upp till en timme att sprida och för användare att kunna logga in med sitt alternativa inloggnings-ID.

PowerShell

Kommentar

Det här konfigurationsalternativet använder HRD-princip. Mer information finns i resurstypen homeRealmDiscoveryPolicy.

När användare med attributet ProxyAddresses har synkroniserats med Microsoft Entra-ID med hjälp av Microsoft Entra Connect måste du aktivera funktionen för användare att logga in med e-post som ett alternativt inloggnings-ID för din klientorganisation. Den här funktionen instruerar Microsoft Entra-inloggningsservrarna att inte bara kontrollera inloggningsidentifieraren mot UPN-värden, utan även mot ProxyAddresses-värden för e-postadressen.

En global administratör krävs för att hantera den här funktionen.

1. Öppna en PowerShell-session som administratör och installera sedan Microsoft.Graph-modulen med hjälp av cmdleten Install-Module :

   Install-Module Microsoft.Graph
   

   Mer information om installation finns i Installera Microsoft Graph PowerShell SDK.

2. Logga in på din Microsoft Entra-klientorganisation med hjälp av cmdleten Connect-MgGraph :

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

   Kommandot ber dig att autentisera med hjälp av en webbläsare.

3. Kontrollera om det redan finns en HomeRealmDiscoveryPolicy i klientorganisationen med hjälp av cmdleten Get-MgPolicyHomeRealmDiscoveryPolicy på följande sätt:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

4. Om ingen princip har konfigurerats för tillfället returnerar kommandot ingenting. Om en princip returneras hoppar du över det här steget och går vidare till nästa steg för att uppdatera en befintlig princip.

   Om du vill lägga till HomeRealmDiscoveryPolicy i klientorganisationen använder du cmdleten New-MgPolicyHomeRealmDiscoveryPolicy och anger attributet AlternateIdLogin till "Enabled": true enligt följande exempel:

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

   När principen har skapats returnerar kommandot princip-ID:t enligt följande exempelutdata:

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

5. Om det redan finns en konfigurerad princip kontrollerar du om attributet AlternateIdLogin är aktiverat, som du ser i följande exempel på principutdata:

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

   Om principen finns men attributet AlternateIdLogin som inte finns eller är aktiverat, eller om det finns andra attribut för principen som du vill bevara, uppdaterar du den befintliga principen med hjälp av cmdleten Update-MgPolicyHomeRealmDiscoveryPolicy .

   Viktigt!

   När du uppdaterar principen måste du inkludera alla gamla inställningar och det nya Attributet AlternateIdLogin .

   I följande exempel läggs attributet AlternateIdLogin till och attributet AllowCloudPasswordValidation bevaras som tidigare angetts:

   $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
   

   Bekräfta att den uppdaterade principen visar dina ändringar och att attributet AlternateIdLogin nu är aktiverat:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Kommentar

Med principen tillämpad kan det ta upp till en timme att sprida och för användare att kunna logga in med e-post som ett alternativt inloggnings-ID.

Ta bort principer

Om du vill ta bort en HRD-princip använder du cmdleten Remove-MgPolicyHomeRealmDiscoveryPolicy :

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

Aktivera stegvis distribution för att testa användarens inloggning med en e-postadress

Kommentar

Det här konfigurationsalternativet använder stegvis distributionsprincip. Mer information finns i resurstypen featureRolloutPolicy.

Stegvis distributionsprincip gör det möjligt för klientadministratörer att aktivera funktioner för specifika Microsoft Entra-grupper. Vi rekommenderar att klientadministratörer använder stegvis distribution för att testa användarens inloggning med en e-postadress. När administratörer är redo att distribuera den här funktionen till hela klientorganisationen bör de använda HRD-principen.

En global administratör krävs för att hantera den här funktionen.

1. Öppna en PowerShell-session som administratör och installera sedan Microsoft.Graph.Beta-modulen med hjälp av cmdleten Install-Module :

   Install-Module Microsoft.Graph.Beta
   

   Om du uppmanas till det väljer du Y för att installera NuGet eller för att installera från en ej betrodd lagringsplats.

2. Logga in på din Microsoft Entra-klientorganisation med hjälp av cmdleten Connect-MgGraph :

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

   Kommandot returnerar information om ditt konto, din miljö och ditt klient-ID.

3. Visa en lista över alla befintliga mellanlagrade distributionsprinciper med hjälp av följande cmdlet:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

4. Om det inte finns några befintliga mellanlagrade distributionsprinciper för den här funktionen skapar du en ny stegvis distributionsprincip och noterar princip-ID:t:

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

5. Leta reda på directoryObject-ID:t för gruppen som ska läggas till i den mellanlagrade distributionsprincipen. Observera värdet som returneras för ID-parametern eftersom det kommer att användas i nästa steg.

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

6. Lägg till gruppen i den stegvisa distributionsprincipen enligt följande exempel. Ersätt värdet i parametern -FeatureRolloutPolicyId med värdet som returneras för princip-ID:t i steg 4 och ersätt värdet i parametern -OdataId med det ID som anges i steg 5. Det kan ta upp till en timme innan användare i gruppen kan logga in på Microsoft Entra-ID med e-post som ett alternativt inloggnings-ID.

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

För nya medlemmar som läggs till i gruppen kan det ta upp till 24 timmar innan de kan logga in på Microsoft Entra-ID med e-post som alternativt inloggnings-ID.

Ta bort grupper

Kör följande kommando för att ta bort en grupp från en mellanlagrad distributionsprincip:

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

Ta bort principer

Om du vill ta bort en stegvis distributionsprincip inaktiverar du först principen och tar sedan bort den från systemet:

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

Testa användarens inloggning med en e-postadress

Om du vill testa att användare kan logga in med e-post går du till och loggar in med ett icke-UPN-e-postmeddelande, till https://myprofile.microsoft.com exempel balas@fabrikam.com. Inloggningsupplevelsen bör se ut och kännas likadan som när du loggar in med UPN.

Felsöka

Om användarna har problem med att logga in med sin e-postadress läser du följande felsökningssteg:

1. Kontrollera att det har gått minst en timme sedan e-post som alternativt inloggnings-ID aktiverades. Om användaren nyligen har lagts till i en grupp för stegvis distributionsprincip kontrollerar du att det har gått minst 24 timmar sedan de lades till i gruppen.

2. Om du använder HRD-principen kontrollerar du att Microsoft Entra ID HomeRealmDiscoveryPolicy har definitionsegenskapen AlternateIdLogin inställd på "Enabled": true och egenskapen IsOrganizationDefault inställd på True:

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Om du använder en stegvis distributionsprincip kontrollerar du att Microsoft Entra ID FeatureRolloutPolicy har egenskapen IsEnabled inställd på True:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

3. Kontrollera att användarkontot har angett sin e-postadress i attributet ProxyAddresses i Microsoft Entra-ID.

Inloggningsloggar

Du kan läsa inloggningsloggarna i Microsoft Entra-ID :t för mer information. Inloggningar med e-post som alternativt inloggnings-ID genereras proxyAddress i fältet Inloggnings-ID och det inmatade användarnamnet i fältet Inloggningsidentifierare .

Motstridiga värden mellan användare som endast är molnbaserade och synkroniserade

I en klientorganisation kan en molnbaserad användares UPN få samma värde som en annan användares proxyadress som synkroniseras från den lokala katalogen. I det här scenariot, med funktionen aktiverad, kommer den molnbaserade användaren inte att kunna logga in med sitt UPN. Här följer stegen för att identifiera instanser av det här problemet.

1. Öppna en PowerShell-session som administratör och installera sedan AzureADPreview-modulen med hjälp av cmdleten Install-Module :

   Install-Module Microsoft.Graph.Beta
   

   Om du uppmanas till det väljer du Y för att installera NuGet eller för att installera från en ej betrodd lagringsplats.

2. En global administratör krävs för att hantera den här funktionen.

   Logga in på din Microsoft Entra-klientorganisation med hjälp av cmdleten Connect-AzureAD :

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

3. Hämta berörda användare.

   # 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. Så här matar du ut berörda användare:

   # 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. Så här matar du ut berörda användare till 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
   

Nästa steg

Mer information om hybrididentitet, till exempel Microsoft Entra-programproxy eller Microsoft Entra Domain Services, finns i Microsoft Entra hybrididentitet för åtkomst och hantering av lokala arbetsbelastningar.

Mer information om hybrididentitetsåtgärder finns i hur synkronisering av lösenordshash eller direktautentisering fungerar.