Logowanie do usługi Azure AD przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania (wersja zapoznawcza)

Uwaga

Logowanie do usługi Azure AD przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania to funkcja publicznej wersji zapoznawczej usługi Azure Active Directory. Aby uzyskać więcej informacji na temat wersji zapoznawczych, zobacz Dodatkowe warunki użytkowania dotyczące wersji Microsoft Azure zapoznawczych.

Wiele organizacji chce, aby użytkownicy logować się do usługi Azure Active Directory (Azure AD) przy użyciu tych samych poświadczeń co lokalne środowisko katalogowe. W przypadku tego podejścia, nazywanego uwierzytelnianiem hybrydowym, użytkownicy muszą pamiętać tylko jeden zestaw poświadczeń.

Niektóre organizacje nie zostały przeniesione do uwierzytelniania hybrydowego z następujących powodów:

  • Domyślnie główna nazwa użytkownika usługi Azure AD (UPN) jest ustawiona na tę samą wartość co lokalna nazwa UPN.
  • Zmiana upn usługi Azure AD powoduje niezgodność między środowiskami lokalnymi i azure AD, które mogą powodować problemy z określonymi aplikacjami i usługami.
  • Ze względu na działalność biznesową lub zgodność organizacja nie chce używać lokalnej sieci UPN do logowania się do usługi Azure AD.

Aby ułatwić przejście do uwierzytelniania hybrydowego, możesz skonfigurować usługę Azure AD, aby umożliwiać użytkownikom logowanie się przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania. Jeśli na przykład firma Contoso ma nazwę Fabrikam, zamiast nadal logować się przy użyciu starszej nazwy UPN, można użyć adresu e-mail jako alternatywnego balas@contoso.com identyfikatora logowania. Aby uzyskać dostęp do aplikacji lub usługi, użytkownicy logują się do usługi Azure AD przy użyciu poczty e-mail spoza tej usługi, takiej jak balas@fabrikam.com .

W tym artykule pokazano, jak włączyć i używać poczty e-mail jako alternatywnego identyfikatora logowania.

Zanim rozpoczniesz

Oto co należy wiedzieć o adresie e-mail jako alternatywnym identyfikatorze logowania:

  • Ta funkcja jest dostępna w Azure AD — wersja Bezpłatna i wyższych wersjach.
  • Ta funkcja umożliwia logowanie się przy użyciu zweryfikowanych adresów ProxyAddresses domeny dla użytkowników usługi Azure AD uwierzytelnionych w chmurze.
  • Gdy użytkownik korzysta z adresu e-mail spoza nazwy UPN, oświadczenia i (jeśli są obecne) w tokenie identyfikatora będą mieć wartość adresu e-mail spoza unique_name preferred_username nazwy UPN.
  • Istnieją dwie opcje konfigurowania funkcji:

Ograniczenia wersji zapoznawczej

W bieżącym stanie wersji zapoznawczej następujące ograniczenia dotyczą poczty e-mail jako alternatywnego identyfikatora logowania:

  • Użytkownicy mogą zobaczyć swoją upn, nawet gdy zalogowali się przy użyciu adresu e-mail spoza tej sieci. Może być widoczne następujące przykładowe zachowanie:

    • Użytkownik jest monitowany o zalogowanie się przy użyciu nazwy UPN po wyświetleniu monitu o zalogowanie się do usługi Azure AD za pomocą polecenia login_hint=<non-UPN email> .
    • Gdy użytkownik jest logowania przy użyciu adresu e-mail spoza nazwy UPN i wprowadza nieprawidłowe hasło, strona "Wprowadź hasło" zmienia się, aby wyświetlić nazwę UPN.
    • W niektórych witrynach i aplikacjach firmy Microsoft, takich jak Microsoft Office, kontrolka Menedżer konta zwykle wyświetlana w prawym górnym rogu może wyświetlać nazwę UPN użytkownika zamiast adresu e-mail spoza nazwy UPN używanego do logowania.
  • Niektóre przepływy nie są obecnie zgodne z adresami e-mail innymi niż upn, na przykład:

    • Ochrona tożsamości nie jest dopasowana do wiadomości e-mail innych niż upn z wykrywaniem ryzyka wycieku poświadczeń. To wykrywanie ryzyka używa upn do dopasowania poświadczeń, które zostały ujawnione. Aby uzyskać więcej informacji, zobacz Azure AD Identity Protection i korygowanie ryzyka.
    • Zaproszenia B2B wysyłane na adres e-mail spoza upn nie są w pełni obsługiwane. Po zaakceptowaniu zaproszenia wysłanego na adres e-mail spoza nazwy UPN logowanie się przy użyciu adresu e-mail spoza nazwy UPN może nie działać dla użytkownika-gościa w punkcie końcowym dzierżawy zasobów.
    • Gdy użytkownik jest zalogowany przy użyciu adresu e-mail spoza nazwy UPN, nie może zmienić hasła. Samoobsługowe resetowanie hasła (SSPR) usługi Azure AD powinno działać zgodnie z oczekiwaniami. Podczas SSPR użytkownik może zobaczyć swoją nazwę UPN, jeśli zweryfikuje swoją tożsamość za pośrednictwem alternatywnej poczty e-mail.
  • Poniższe scenariusze nie są obsługiwane. Zaloguj się przy użyciu adresu e-mail spoza upn, aby:

    • Urządzenia dołączone hybrydowo do usługi Azure AD
    • Urządzenia dołączone do usługi Azure AD
    • Skype dla firm
    • Microsoft Office w systemie macOS
    • OneDrive (jeśli przepływ logowania nie obejmuje uwierzytelniania wieloskładnikowego)
    • Aplikacja Microsoft Teams w Sieci Web
    • Przepływy poświadczeń hasła właściciela zasobu (PRZEPŁYWC)
  • Zmiany wprowadzone w konfiguracji funkcji w zasadach HRD nie są jawnie wyświetlane w dziennikach inspekcji.

  • Zasady etapowego wycofywania nie działają zgodnie z oczekiwaniami w przypadku użytkowników, którzy są uwzględnioni w wielu zasadach etapowego.

  • W ramach dzierżawy nazwa UPN użytkownika tylko w chmurze może być taka sama jak adres serwera proxy innego użytkownika synchronizowany z katalogu lokalnego. W tym scenariuszu po włączeniu tej funkcji użytkownik tylko w chmurze nie będzie mógł zalogować się przy użyciu nazwy UPN. Więcej informacji na temat tego problemu można uzyskać w sekcji Rozwiązywanie problemów.

Omówienie alternatywnych opcji identyfikatora logowania

Aby zalogować się do usługi Azure AD, użytkownicy wprowadź wartość, która unikatowo identyfikuje ich konto. W przeszłości jako identyfikatora logowania można było używać tylko nazwy UPN usługi Azure AD.

W przypadku organizacji, w których lokalna nazwa UPN jest preferowaną przez użytkownika pocztą e-mail logowania, to podejście było doskonałe. Te organizacje ustawiłyby dla usługi Azure AD upn dokładnie taką samą wartość jak lokalna upn, a użytkownicy będą mieć spójne środowisko logowania.

Alternatywny identyfikator logowania dla AD FS

Jednak w niektórych organizacjach lokalna nazwy UPN nie jest używana jako identyfikator logowania. W środowiskach lokalnych należy skonfigurować lokalne konto AD DS, aby zezwolić na logowanie przy użyciu alternatywnego identyfikatora logowania. Ustawienie dla usługi Azure AD upn tej samej wartości co lokalna wartość upn nie jest opcją, ponieważ usługa Azure AD będzie wymagać od użytkowników zalogowania się przy użyciu tej wartości.

Alternatywny identyfikator logowania w Azure AD Connect

Typowym obejściem tego problemu było ustawienie nazwy UPN usługi Azure AD na adres e-mail, za pomocą których użytkownik chce się zalogować. To podejście działa, chociaż powoduje różne upn między lokalną usługą AD i usługą Azure AD, a ta konfiguracja nie jest zgodna ze wszystkimi Microsoft 365 obciążeniami.

Adres e-mail jako alternatywny identyfikator logowania

Innym podejściem jest zsynchronizowanie usługi Azure AD i lokalnych sieci UPN z taką samą wartością, a następnie skonfigurowanie usługi Azure AD, aby umożliwić użytkownikom logowanie się do usługi Azure AD przy użyciu zweryfikowanej wiadomości e-mail. Aby zapewnić tę możliwość, należy zdefiniować co najmniej jeden adres e-mail w atrybutie ProxyAddresses użytkownika w katalogu lokalnym. ProxyAddresses są następnie automatycznie synchronizowane z usługą Azure AD przy użyciu Azure AD Connect.

Opcja Opis
Alternatywny identyfikator logowania dla AD FS Włącz logowanie przy użyciu atrybutu alternatywnego (takiego jak Poczta) dla AD FS użytkowników.
Alternatywny identyfikator logowania w Azure AD Connect Zsynchronizuj atrybut alternatywny (np. Mail) jako upn usługi Azure AD.
Adres e-mail jako alternatywny identyfikator logowania Włącz logowanie przy użyciu zweryfikowanego adresu ProxyAddresses domeny dla użytkowników usługi Azure AD.

Synchronizowanie adresów e-mail logowania do usługi Azure AD

Uwierzytelnianie Active Directory Domain Services (AD DS) lub Active Directory Federation Services (AD FS) odbywa się bezpośrednio w sieci i jest obsługiwane przez AD DS infrastrukturę. W przypadku uwierzytelniania hybrydowego użytkownicy mogą zamiast tego logować się bezpośrednio do usługi Azure AD.

Aby obsługiwać to podejście do uwierzytelniania hybrydowego, należy zsynchronizować lokalne środowisko usługi AD DS z usługą Azure AD przy użyciu usługi Azure AD Connect i skonfigurować je do używania synchronizacji skrótów haseł (PHS) lub uwierzytelniania Pass-Through Authentication (PTA). Aby uzyskać więcej informacji, zobacz Wybieranie właściwej metody uwierzytelniania dla rozwiązania tożsamości hybrydowej usługi Azure AD.

W obu opcjach konfiguracji użytkownik przesyła swoją nazwę użytkownika i hasło do usługi Azure AD, która weryfikuje poświadczenia i wydaje bilet. Gdy użytkownicy logują się do usługi Azure AD, nie ma potrzeby, aby organizacja hostować infrastrukturę AD FS zarządzać nią.

Jednym z atrybutów użytkownika, który jest automatycznie synchronizowany przez usługę Azure AD Connect jest proxyAddresses. Jeśli użytkownicy mają adres e-mail zdefiniowany w środowisku AD DS jako część atrybutu ProxyAddresses, zostanie on automatycznie zsynchronizowany z usługą Azure AD. Tego adresu e-mail można następnie użyć bezpośrednio w procesie logowania usługi Azure AD jako alternatywnego identyfikatora logowania.

Ważne

Tylko wiadomości e-mail w zweryfikowanych domenach dzierżawy są synchronizowane z usługą Azure AD. Każda dzierżawa usługi Azure AD ma co najmniej jedną zweryfikowaną domenę, dla której sprawdzono własność i która jest jednoznacznie powiązana z Dzierżawą.

Aby uzyskać więcej informacji, zobacz Dodawanie i weryfikowanie niestandardowej nazwy domeny w usłudze Azure AD.

Włączanie logowania użytkownika przy użyciu adresu e-mail

Uwaga

Ta opcja konfiguracji używa zasad HRD. Aby uzyskać więcej informacji, zobacz typ zasobu homeRealmDiscoveryPolicy.

Po zsynchronizowaniu użytkowników z zastosowanym atrybutem ProxyAddresses z usługą Azure AD przy użyciu usługi Azure AD Connect należy włączyć tę funkcję, aby użytkownicy logowali się przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania dla dzierżawy. Ta funkcja nakazuje serwerom logowania usługi Azure AD nie tylko sprawdzenie identyfikatora logowania względem wartości nazwy UPN, ale także wartości ProxyAddresses adresu e-mail.

Obecnie w wersji zapoznawczej można włączyć logowanie za pomocą poczty e-mail tylko jako alternatywną funkcję identyfikatora logowania przy użyciu programu PowerShell. Aby wykonać następujące czynności, musisz mieć uprawnienia administratora globalnego:

  1. Otwórz sesję programu PowerShell jako administrator, a następnie zainstaluj moduł AzureADPreview za pomocą polecenia cmdlet Install-Module:

    Install-Module AzureADPreview
    

    Jeśli zostanie wyświetlony monit, wybierz pozycję Y, aby zainstalować pakiet NuGet lub zainstalować go z niezaufanego repozytorium.

  2. Zaloguj się do dzierżawy usługi Azure AD jako administrator globalny za pomocą polecenia cmdlet Connect-AzureAD:

    Connect-AzureAD
    

    Polecenie zwraca informacje o Twoim koncie, środowisku i identyfikatorze dzierżawy.

  3. Sprawdź, czy w dzierżawie istnieje już plik HomeRealmDiscoveryPolicy, używając polecenia cmdlet Get-AzureADPolicy w następujący sposób:

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    
  4. Jeśli obecnie nie skonfigurowano żadnych zasad, polecenie nie zwraca żadnych danych. Jeśli zasady są zwracane, pomiń ten krok i przejdź do następnego kroku, aby zaktualizować istniejące zasady.

    Aby dodać zasady HomeRealmDiscoveryPolicy do dzierżawy, użyj polecenia cmdlet New-AzureADPolicy i ustaw atrybut AlternateIdLogin na wartość "Enabled": true, jak pokazano w poniższym przykładzie:

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

    Po pomyślnym utworzeniu zasad polecenie zwraca identyfikator zasad, jak pokazano w następujących przykładowych danych wyjściowych:

    Id                                   DisplayName                 Type                     IsOrganizationDefault
    --                                   -----------                 ----                     ---------------------
    5de3afbe-4b7a-4b33-86b0-7bbe308db7f7 BasicAutoAccelerationPolicy HomeRealmDiscoveryPolicy True
    
  5. Jeśli skonfigurowano już zasady, sprawdź, czy atrybut AlternateIdLogin jest włączony, jak pokazano w   następujących przykładowych danych wyjściowych zasad:

    Id : 5de3afbe-4b7a-4b33-86b0-7bbe308db7f7
    OdataType :
    AlternativeIdentifier :
    Definition : {{"HomeRealmDiscoveryPolicy" :{"AlternateIdLogin":{"Enabled": true}}}}
    DisplayName : BasicAutoAccelerationPolicy
    IsOrganizationDefault : True
    KeyCredentials : {}
    Type : HomeRealmDiscoveryPolicy
    

    Jeśli zasady istnieją, ale atrybut AlternateIdLogin, który nie jest obecny lub włączony, lub jeśli w zasadach, które chcesz zachować, istnieją inne atrybuty, zaktualizuj istniejące zasady przy użyciu polecenia cmdlet Set-AzureADPolicy.

    Ważne

    Podczas aktualizowania zasad upewnij się, że dołączyć wszystkie stare ustawienia i nowy atrybut AlternateIdLogin.

    Poniższy przykład dodaje atrybut AlternateIdLogin i zachowuje atrybut AllowCloudPasswordValidation, który mógł już być ustawiony:

    $AzureADPolicyDefinition = @(
      @{
         "HomeRealmDiscoveryPolicy" = @{
            "AllowCloudPasswordValidation" = $true
            "AlternateIdLogin" = @{
               "Enabled" = $true
            }
         }
      } | ConvertTo-JSON -Compress
    )
    $AzureADPolicyParameters = @{
      ID                    = "b581c39c-8fe3-4bb5-b53d-ea3de05abb4b"
      Definition            = $AzureADPolicyDefinition
      DisplayName           = "BasicAutoAccelerationPolicy"
      IsOrganizationDefault = $true
      Type                  = "HomeRealmDiscoveryPolicy"
    }
    
    Set-AzureADPolicy @AzureADPolicyParameters
    

    Upewnij się, że zaktualizowane zasady pokazują zmiany i czy atrybut AlternateIdLogin jest teraz włączony:

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    

Po zastosowaniu zasad propagacja może potrwać do 1 godziny, a użytkownicy będą mogli zalogować się przy użyciu alternatywnego identyfikatora logowania.

Włączanie etapowego wycofywania w celu przetestowania logowania użytkownika przy użyciu adresu e-mail

Uwaga

Ta opcja konfiguracji używa zasad etapowego rozsyłania. Aby uzyskać więcej informacji, zobacz featureRolloutPolicy, typ zasobu.

Zasady etapowego wycofywania umożliwiają administratorom dzierżawy włączanie funkcji dla określonych grup usługi Azure AD. Zaleca się, aby administratorzy dzierżawy używali etapowego w celu przetestowania logowania użytkowników przy użyciu adresu e-mail. Gdy administratorzy będą gotowi do wdrożenia tej funkcji w całej dzierżawie, powinni używać zasad HRD.

Aby wykonać następujące czynności, musisz mieć uprawnienia administratora globalnego:

  1. Otwórz sesję programu PowerShell jako administrator, a następnie zainstaluj moduł AzureADPreview przy użyciu polecenia cmdlet Install-Module:

    Install-Module AzureADPreview
    

    Jeśli zostanie wyświetlony monit, wybierz pozycję Y, aby zainstalować pakiet NuGet lub zainstalować go z niezaufanego repozytorium.

  2. Zaloguj się do dzierżawy usługi Azure AD jako administrator globalny za pomocą polecenia cmdlet Connect-AzureAD:

    Connect-AzureAD
    

    Polecenie zwraca informacje o twoim koncie, środowisku i identyfikatorze dzierżawy.

  3. Lista wszystkich istniejących zasad etapowego stosowania przy użyciu następującego polecenia cmdlet:

    Get-AzureADMSFeatureRolloutPolicy
    
  4. Jeśli dla tej funkcji nie ma żadnych zasad etapowego wycofywania, utwórz nowe zasady etapowego wycofywania i zanotuj identyfikator zasad:

    $AzureADMSFeatureRolloutPolicy = @{
       Feature    = "EmailAsAlternateId"
       DisplayName = "EmailAsAlternateId Rollout Policy"
       IsEnabled   = $true
    }
    New-AzureADMSFeatureRolloutPolicy @AzureADMSFeatureRolloutPolicy
    
  5. Znajdź identyfikator directoryObject grupy, która ma zostać dodana do zasad etapowego wycofywania. Zanotuj wartość zwróconą dla parametru Id, ponieważ zostanie ona użyta w następnym kroku.

    Get-AzureADMSGroup -SearchString "Name of group to be added to the staged rollout policy"
    
  6. Dodaj grupę do zasad etapowego wycofywania, jak pokazano w poniższym przykładzie. Zastąp wartość w parametrze -Id wartością zwróconą dla identyfikatora zasad w kroku 4 i zastąp wartość w parametrze -RefObjectId identyfikatorem zanotowany w kroku 5. Może upłynieć do 1 godziny, zanim użytkownicy w grupie będą w stanie zalogować się do usługi Azure AD przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania.

    Add-AzureADMSFeatureRolloutPolicyDirectoryObject -Id "ROLLOUT_POLICY_ID" -RefObjectId "GROUP_OBJECT_ID"
    

W przypadku nowych członków dodanych do grupy może upłynieć do 24 godzin, zanim będą oni w stanie zalogować się do usługi Azure AD przy użyciu poczty e-mail jako alternatywnego identyfikatora logowania.

Usuwanie grup

Aby usunąć grupę z zasad etapowego wycofywania, uruchom następujące polecenie:

Remove-AzureADMSFeatureRolloutPolicyDirectoryObject -Id "ROLLOUT_POLICY_ID" -ObjectId "GROUP_OBJECT_ID" 

Usuwanie zasad

Aby usunąć zasady etapowego wycofywania, najpierw wyłącz zasady, a następnie usuń je z systemu:

Set-AzureADMSFeatureRolloutPolicy -Id "ROLLOUT_POLICY_ID" -IsEnabled $false 
Remove-AzureADMSFeatureRolloutPolicy -Id "ROLLOUT_POLICY_ID"

Testowanie logowania użytkownika przy użyciu adresu e-mail

Aby sprawdzić, czy użytkownicy mogą logować się za pomocą poczty e-mail, przejdź do adresu i zaloguj się przy użyciu adresu e-mail spoza tej https://myprofile.microsoft.com usługi, takiego jak balas@fabrikam.com . Środowisko logowania powinno wyglądać i wyglądać tak samo jak logowanie przy użyciu upn.

Rozwiązywanie problemów

Jeśli użytkownicy mają problemy z logowaniem się przy użyciu adresu e-mail, zapoznaj się z następującymi krokami rozwiązywania problemów:

  1. Upewnij się, że od czasu, gdy adres e-mail jako alternatywny identyfikator logowania został włączony, miej co najmniej 1 godzinę. Jeśli użytkownik został niedawno dodany do grupy dla zasad etapowego rozsyłania, upewnij się, że od momentu dodania użytkownika do grupy jego czas to co najmniej 24 godziny.

  2. Jeśli używasz zasad HRD, upewnij się, że właściwość HomeRealmDiscoveryPolicy usługi Azure AD ma właściwość definicji AlternateIdLogin ustawioną na wartość "Enabled": true i właściwość IsOrganizationDefault ustawioną na wartość True:

    Get-AzureADPolicy | Where-Object Type -eq "HomeRealmDiscoveryPolicy" | Format-List *
    

    W przypadku korzystania z zasad etapowego stosowania upewnij się, że właściwość FeatureRolloutPolicy usługi Azure AD ma właściwość IsEnabled ustawioną na wartość True:

    Get-AzureADMSFeatureRolloutPolicy
    
  3. Upewnij się, że konto użytkownika ma swój adres e-mail ustawiony w atrybutze ProxyAddresses w usłudze Azure AD.

Konflikt wartości między użytkownikami tylko w chmurze i zsynchronizowanymi

W ramach dzierżawy nazwa UPN użytkownika tylko w chmurze może przyjąć tę samą wartość, co adres serwera proxy innego użytkownika synchronizowany z katalogu lokalnego. W tym scenariuszu po włączeniu tej funkcji użytkownik tylko w chmurze nie będzie mógł zalogować się przy użyciu nazwy UPN. Poniżej znajdują się kroki wykrywania wystąpień tego problemu.

  1. Otwórz sesję programu PowerShell jako administrator, a następnie zainstaluj moduł AzureADPreview za pomocą polecenia cmdlet Install-Module:

    Install-Module AzureADPreview
    

    Jeśli zostanie wyświetlony monit, wybierz pozycję Y, aby zainstalować pakiet NuGet lub zainstalować go z niezaufanego repozytorium.

  2. Zaloguj się do dzierżawy usługi Azure AD jako administrator globalny za pomocą polecenia cmdlet Connect-AzureAD:

    Connect-AzureAD
    
  3. Uzyskaj użytkowników, których to dotyczy.

    # Get all users
    $allUsers = Get-AzureADUser -All $true
    
    # 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. Aby wyprowadzić użytkowników, których to dotyczy:

    # 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. Aby wyprowadzić użytkowników, których dotyczy problem, do pliku 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
    

Następne kroki

Aby dowiedzieć się więcej na temat tożsamości hybrydowej, takiej jak serwer proxy usługi aplikacja usługi Azure AD lub usługa Azure AD Domain Services, zobacz Tożsamość hybrydowa usługi Azure AD w celu uzyskiwania dostępu do obciążeń w środowiskach produkcyjnych i zarządzania nimi.

Aby uzyskać więcej informacji na temat operacji tożsamości hybrydowej, zobacz, jak działa synchronizacja skrótów haseł lub synchronizacja uwierzytelniania pass-through.