Accedere a Microsoft Entra ID usando l'indirizzo di posta elettronica come ID di accesso alternativo (Anteprima)

Molte organizzazioni desiderano consentire agli utenti di accedere a Microsoft Entra ID usando le stesse credenziali dell'ambiente della directory locale. Tramite questo approccio, noto come autenticazione ibrida, gli utenti dovranno ricordare solo una coppia di credenziali.

Alcune organizzazioni non sono passate all'autenticazione ibrida per i motivi seguenti:

• Per impostazione predefinita, l'UPN (nome dell'entità utente) di Microsoft Entra è impostato sullo stesso valore dell'UPN locale.
• Modificando l'UPN di Microsoft Entra viene creata una mancata corrispondenza tra gli ambienti locali e quelli di Microsoft Entra che potrebbe causare problemi con alcune applicazioni e servizi.
• Per motivi aziendali o di conformità, l'organizzazione non desidera usare l'UPN locale per accedere a Microsoft Entra ID.

Per passare all'autenticazione ibrida, è possibile configurare Microsoft Entra ID per consentire agli utenti di accedere con il proprio indirizzo di posta elettronica come ID di accesso alternativo. Ad esempio, se Contoso cambiasse nome in Fabrikam, invece di continuare ad accedere con il vecchio UPN ana@contoso.com, sarà possibile usare l'indirizzo di posta elettronica come ID di accesso alternativo. Per accedere a un'applicazione o a un servizio, gli utenti dovevano effettuare l'accesso a Microsoft Entra ID usando il proprio indirizzo di posta elettronica non UPN, ad esempio ana@fabrikam.com.

Questo articolo illustra come abilitare e usare l'indirizzo di posta elettronica come ID di accesso alternativo.

Operazioni preliminari

Ecco cosa occorre sapere sull'indirizzo di posta elettronica come ID di accesso alternativo:

• La funzionalità è disponibile in Microsoft Entra ID Free Edition e versioni successive.

• La funzionalità consente l'accesso con ProxyAddress, oltre all'UPN, per gli utenti Microsoft Entra autenticati nel cloud. Per ulteriori informazioni sull'applicazione della collaborazione B2B (Business to Business) di Microsoft Entra, consultare la sezione B2B.

• Quando un utente accede con un indirizzo di posta elettronica non UPN, le attestazioni unique_name e preferred_username (se presenti) nel token ID restituiranno l'indirizzo di posta elettronica non UPN.

  • Se l'indirizzo di posta elettronica non UPN usato diventa obsoleto (non è più associato all'utente), tali attestazioni restituiranno invece l'UPN.

• La funzionalità supporta l'autenticazione gestita con PHS (Sincronizzazione dell'hash delle password) o PTA (autenticazione pass-through).

• Per configurare la funzionalità, ci sono due opzioni:

  • Criteri di individuazione dell'area di autenticazione principale (HRD): usare questa opzione per abilitare la funzionalità per l'intero tenant. È necessario almeno il ruolo Amministratore applicazione.
  • Criteri di implementazione a fasi: usare questa opzione per testare la funzionalità con specifici gruppi di Microsoft Entra. Quando un gruppo di sicurezza viene aggiunto per la prima volta per l'implementazione a fasi, il limite di utenti è fissato a 200 per evitare che si verifichi un timeout nell'esperienza utente. Dopo aver aggiunto il gruppo, è possibile includervi ulteriori utenti direttamente, se necessario.

  Per gestire questa funzionalità è necessario un amministratore globale.

Limiti dell'anteprima

Nello stato di anteprima attuale, le seguenti limitazioni si applicano all'indirizzo di posta elettronica come ID di accesso alternativo:

• Esperienza utente: gli utenti possono consultare il proprio UPN, anche quando hanno effettuato l'accesso con un indirizzo di posta elettronica non UPN. È possibile visualizzare il comportamento di esempio seguente:

  • All'utente viene richiesto di accedere con UPN quando viene indirizzato all'accesso a Microsoft Entra con login_hint=<non-UPN email>.
  • Quando un utente effettua l'accesso con un indirizzo di posta elettronica non UPN e inserisce una password errata, la pagina “Immetti la password” verrà aggiornata per visualizzare l'UPN.
  • In alcuni siti e applicazioni Microsoft, come Microsoft Office, il controllo Account Manager tipicamente visualizzato in alto a destra potrebbe visualizzare l'UPN dell'utente invece dell'indirizzo di posta elettronica non UPN usato per l'accesso.

• Flussi non supportati: alcuni flussi non sono attualmente compatibili con indirizzi e-mail non UPN, ad esempio i seguenti:

  • Microsoft Entra ID Protection non abbina indirizzi e-mail non UPN con il rilevamento dei rischi Credenziali perse. Questo rilevamento dei rischi usa l'UPN per abbinare le credenziali che sono andate perse. Per ulteriori informazioni, consultare Procedura: analizzare i rischi.
  • Quando un utente accede con un indirizzo di posta elettronica non UPN, non può modificare la propria password. La reimpostazione della password self-service (SSPR) di Microsoft Entra dovrebbe funzionare come previsto. Durante la reimpostazione della password self-service, l'utente può visualizzare il proprio UPN se verifica la propria identità usando un indirizzo di posta elettronica non UPN.

• Scenari non supportati: i seguenti scenari non sono supportati. Accedere con un indirizzo di posta elettronica non UPN per:

  • Dispositivi ibridi aggiunti a Microsoft Entra
  • Dispositivi aggiunti a Microsoft Entra
  • Dispositivi registrati di Microsoft Entra
  • Credenziali password del proprietario della risorsa (ROPC)
  • Criteri di protezione delle app e Single Sign-On sulla piattaforma per dispositivi mobili
  • Autenticazione legacy, ad esempio POP3 e SMTP
  • Skype for Business

• Applicazioni non supportate: alcune applicazioni di terze parti potrebbero non funzionare correttamente se considerano le richieste unique_name o preferred_username come immutabili o legate sempre a un attributo specifico dell'utente, come l'UPN.

• Registrazione: le modifiche apportate alla configurazione della funzionalità nei criteri HRD non vengono visualizzate in modo esplicito nei log di controllo.

• Criteri di implementazione a fasi: le limitazioni seguenti si applicano solo quando la funzionalità è abilitata usando i criteri di implementazione a fasi:

  • La funzionalità non funziona come previsto per gli utenti inclusi in altri criteri di implementazione a fasi.
  • I criteri di implementazione a fasi supportano un massimo di 10 gruppi per funzionalità.
  • I criteri di implementazione a fasi non supportano i gruppi annidati.
  • I criteri di implementazione a fasi non supportano i gruppi di appartenenza dinamica.
  • Gli oggetti Contact all'interno del gruppo impediscono l'aggiunta del gruppo a criteri di implementazione a fasi.

• Valori duplicati: all'interno di un tenant, l'UPN di un utente solo cloud può coincidere con il valore dell'indirizzo proxy di un altro utente sincronizzato dalla directory locale. In questo scenario, con la funzionalità abilitata, l'utente solo cloud non sarà in grado di accedere con il proprio UPN. Per ulteriori informazioni su questo problema, consultare la sezione Risoluzione dei problemi.

Panoramica delle opzioni per l'ID di accesso alternativo

Per accedere a Microsoft Entra ID, gli utenti inseriscono un valore che identifica in modo univoco l'account. In passato, era possibile usare solo l'UPN di Microsoft Entra come identificatore di accesso.

Per le organizzazioni in cui l'UPN locale rappresenta l'indirizzo di posta elettronica preferito dall'utente, questo approccio era ottimo. Queste organizzazioni potevano impostare l'UPN di Microsoft Entra esattamente sullo stesso valore dell'UPN locale, garantendo agli utenti un'esperienza di accesso coerente.

ID di accesso alternativo per AD FS

Tuttavia, in alcune organizzazioni l'UPN locale non viene usato come identificatore di accesso. Negli ambienti locali, è necessario configurare l'AD DS locale per consentire l'accesso con un ID di accesso alternativo. Impostare l'UPN di Microsoft Entra sullo stesso valore dell'UPN locale non è un'opzione, poiché Microsoft Entra ID richiederebbe agli utenti di effettuare l'accesso usando tale valore.

ID di accesso alternativo in Microsoft Entra Connect

La soluzione più comune a questo problema consisteva nell'impostare l'UPN di Microsoft Entra sull'indirizzo di posta elettronica con cui l'utente intendeva effettuare l'accesso. Questo approccio è efficace, ma comporta UPN diversi tra AD locale e Microsoft Entra ID, una configurazione che non è compatibile con tutti i carichi di lavoro di Microsoft 365.

Indirizzo di posta elettronica come ID di accesso alternativo

Un approccio alternativo consiste nel sincronizzare l'UPN di Microsoft Entra ID con quello locale, mantenendo lo stesso valore, e configurare Microsoft Entra ID in modo che gli utenti possano accedere usando un indirizzo di posta elettronica verificato. Per consentire questa possibilità, vengono definiti uno o più indirizzi di posta elettronica nell'attributo ProxyAddresses dell'utente nella directory locale. ProxyAddresses viene quindi sincronizzato automaticamente con Microsoft Entra ID usando Microsoft Entra Connect.

Sincronizzare gli indirizzi di posta elettronica di accesso con Microsoft Entra ID

L'autenticazione tradizionale di Active Directory Domain Services o di Active Directory Federation Services (AD FS) viene eseguita direttamente nella rete e viene gestita dall'infrastruttura di Active Directory Domain Services. Con l'autenticazione ibrida, gli utenti possono invece accedere direttamente a Microsoft Entra ID.

Per supportare questo approccio di autenticazione ibrida, occorre sincronizzare l'ambiente AD DS locale con Microsoft Entra ID usando Microsoft Entra Connect e configurarlo per l'uso di PHS o PTA. Per altre informazioni, vedere Scegliere il metodo di autenticazione appropriato per la soluzione di gestione ibrida dell’identità di Microsoft Entra.

In entrambe le opzioni di configurazione, l'utente fornisce il proprio nome utente e la propria password a Microsoft Entra ID, che convalida le credenziali ed emette un ticket. Quando gli utenti accedono a Microsoft Entra ID, l'organizzazione non ha più bisogno di ospitare e gestire un'infrastruttura AD FS.

Uno degli attributi utente che viene sincronizzato automaticamente da Microsoft Entra Connect è ProxyAddress. Se gli utenti dispongono di un indirizzo di posta elettronica definito nell'ambiente AD DS locale come parte dell'attributo ProxyAddresses, questo viene automaticamente sincronizzato con Microsoft Entra ID. Questo indirizzo di posta elettronica può essere usato direttamente nel processo di accesso a Microsoft Entra come ID di accesso alternativo.

Accesso degli utenti guest B2B con un indirizzo e-mail

L'indirizzo di posta elettronica come ID di accesso alternativo si applica a Collaborazione B2B di Microsoft Entra con un modello "Bring Your Own Sign-In Identifiers". Quando l'indirizzo e-mail come ID di accesso alternativo è abilitato nel tenant principale, gli utenti di Microsoft Entra possono eseguire l'accesso guest con un indirizzo e-mail non UPN nell'endpoint del tenant della risorsa. Non è necessaria alcuna azione dal tenant della risorsa per abilitare questa funzionalità.

Abilitare l'accesso degli utenti con un indirizzo e-mail

Quando gli utenti ai quali è stato applicato l'attributo ProxyAddresses vengono sincronizzati su Microsoft Entra ID usando Microsoft Entra Connect, è necessario abilitare la funzione per far sì che gli utenti accedano con il proprio indirizzo e-mail come ID di accesso alternativo per il tenant. Questa funzionalità indica ai server di accesso di Microsoft Entra di controllare l'identificatore di accesso non solo rispetto ai valori UPN, ma anche rispetto ai valori dell'attributo ProxyAddresses per l'indirizzo e-mail.

Per configurare la funzionalità è possibile utilizzare l'interfaccia di amministrazione di Microsoft Entra o PowerShell di Microsoft Graph.

Per gestire questa funzionalità è necessario un amministratore globale.

Interfaccia di amministrazione di Microsoft Entra

1. Accedi all'Interfaccia di amministrazione di Microsoft Entra come Amministratore globale.

2. Dal menu di spostamento sul lato sinistro della finestra di Microsoft Entra selezionare Microsoft Entra Connect > Indirizzo e-mail come ID di accesso alternativo.

   

3. Fare clic sulla casella di controllo accanto a Indirizzo e-mail come ID di accesso alternativo.

4. Fare clic su Salva.

   

Una volta applicati i criteri, può essere necessaria fino a un'ora per la propagazione e per consentire agli utenti di accedere utilizzando l'ID di accesso alternativo.

PowerShell

Quando gli utenti ai quali è stato applicato l'attributo ProxyAddresses vengono sincronizzati su Microsoft Entra ID usando Microsoft Entra Connect è necessario abilitare la funzione per far sì che gli utenti accedano con il proprio indirizzo e-mail come ID di accesso alternativo per il tenant. Questa funzionalità indica ai server di accesso di Microsoft Entra di controllare l'identificatore di accesso non solo rispetto ai valori UPN, ma anche rispetto ai valori dell'attributo ProxyAddresses per l'indirizzo e-mail.

Per gestire questa funzionalità è necessario un amministratore globale.

1. Aprire una sessione di PowerShell come amministratore, quindi installare il modulo Microsoft.Graph usando il cmdlet Install-Module:

   Install-Module Microsoft.Graph
   

   Per altre informazioni, vedere Installare l'SDK di Microsoft Graph PowerShell

2. Accedere al tenant di Microsoft Entra usando il cmdlet Connect-MgGraph:

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

   Il comando chiederà di eseguire l'autenticazione usando un Web browser.

3. Verificare se è già presente un criterio HomeRealmDiscoveryPolicy nel tenant usando il cmdlet Get-MgPolicyHomeRealmDiscoveryPolicy come segue:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

4. In assenza di un criterio attualmente configurato, il comando non restituisce alcun valore. Se viene restituito un criterio, ignorare questo passaggio e passare a quello successivo per aggiornare un criterio esistente.

   Per aggiungere il criterio HomeRealmDiscoveryPolicy al tenant, usare il cmdlet New-MgPolicyHomeRealmDiscoveryPolicy e impostare l'attributo AlternateIdLogin su "Enabled": true come mostrato nell'esempio seguente:

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

   Dopo aver completato la creazione del criterio, il comando restituisce l'ID del criterio come mostrato nell'output di esempio seguente:

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

5. Se è già stato configurato un criterio, verificare che l'attributo AlternateIdLogin è abilitato, come mostrato nell'output del criterio di esempio seguente:

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

   Se il criterio esiste ma l'attributo AlternateIdLogin non è presente, non è abilitato oppure sono presenti altri attributi sul criterio che si vuole conservare, aggiornare il criterio esistente usando il cmdlet Update-MgPolicyHomeRealmDiscoveryPolicy.

   Importante

   Quando si aggiornano i criteri, assicurarsi di includere le impostazioni precedenti e il nuovo attributo AlternateIdLogin .

   Nell'esempio seguente si aggiunge l'attributo AlternateIdLogin e si conserva l'attributo AllowCloudPasswordValidation impostato in precedenza:

   $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
   

   Verificare che il criterio aggiornato rifletta le modifiche e che l'attributo AlternateIdLogin sia ora abilitato:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Rimozione di criteri

Per rimuovere un criterio HRD, usare il cmdlet Remove-MgPolicyHomeRealmDiscoveryPolicy:

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

Abilitare l'implementazione a fasi per testare l'accesso degli utenti con un indirizzo e-mail

I criteri di implementazione a fasi consentono agli amministratori tenant di abilitare le funzionalità per specifici gruppi di Microsoft Entra. Si consiglia agli amministratori tenant di usare l'implementazione a fasi per testare l'accesso degli utenti con un indirizzo e-mail. Quando gli amministratori sono pronti a distribuire questa funzionalità nell'intero tenant, devono usare i criteri HRD.

Per gestire questa funzionalità è necessario un amministratore globale.

1. Aprire una sessione di PowerShell come amministratore, installare il modulo Microsoft.Graph.Beta usando il cmdlet Install-Module:

   Install-Module Microsoft.Graph.Beta
   

   Se richiesto, selezionare Y per installare NuGet o per eseguire l'installazione da un repository non attendibile.

2. Accedere al tenant di Microsoft Entra usando il cmdlet Connect-MgGraph:

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

   Il comando restituisce informazioni su account, ambiente e ID del tenant.

3. Elencare tutti i criteri di implementazione a fasi esistenti usando il cmdlet seguente:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

4. Se non sono presenti criteri di implementazione a fasi per questa funzionalità, creare un nuovo criterio di implementazione a fasi e prendere nota dell'ID del criterio:

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

5. Trovare l'ID directoryObject per il gruppo da aggiungere ai criteri di implementazione a fasi. Prendere nota del valore restituito per il parametro Id che verrà usato nel passaggio successivo.

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

6. Aggiungere il gruppo ai criteri di implementazione a fasi, come illustrato nell'esempio seguente. Sostituire il valore nel parametro -FeatureRolloutPolicyId con il valore restituito per l'ID criterio nel passaggio 4 e sostituire il valore nel parametro -OdataId con l'Id annotato nel passaggio 5. Gli utenti nel gruppo dovranno attendere al massimo un'ora per poter accedere a Microsoft Entra ID via e-mail con ID di accesso alternativo.

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

Per i nuovi membri aggiunti al gruppo, potrebbero essere necessarie fino a 24 ore per poter accedere a Microsoft Entra ID via e-mail con ID di accesso alternativo.

Rimozione di gruppi

Per rimuovere un gruppo da un criterio di implementazione a fasi, eseguire il comando seguente:

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

Rimozione di criteri

Per rimuovere un criterio di implementazione a fasi, innanzitutto disabilitarlo e quindi rimuoverlo dal sistema:

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

Accesso degli utenti con un indirizzo e-mail

Per testare che gli utenti possano accedere via e-mail, passare a https://myprofile.microsoft.com e accedere con un indirizzo e-mail non UPN, ad esempio balas@fabrikam.com. L'esperienza d'accesso deve essere analoga a quella con UPN.

Risoluzione dei problemi

Se gli utenti hanno problemi ad accedere usando il proprio indirizzo e-mail, esaminare i passaggi di risoluzione dei problemi seguenti:

1. Assicurarsi che sia trascorsa almeno un'ora dal momento in cui è stata abilitata l'e-mail come ID di accesso alternativo. Se l'utente è stato aggiunto di recente a un gruppo per i criteri di implementazione a fasi, assicurarsi che siano trascorse almeno 24 ore dall'aggiunta al gruppo.

2. Se si usano i criteri HRD, verificare che Microsoft Entra ID HomeRealmDiscoveryPolicy abbia la proprietà di definizione definizione AlternateIdLogin impostata su "Enabled": true e la proprietà IsOrganizationDefault impostata su True:

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Se si usano criteri di implementazione a fasi, verificare che FeatureRolloutPolicy di Microsoft Entra ID abbia la proprietà IsEnabled impostata su True:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

3. Assicurarsi che per l'account utente sia stato impostato l'indirizzo e-mail nell'attributo ProxyAddresses in Microsoft Entra ID.

Log di accesso

Per altre informazioni, vedere i log di accesso in Microsoft Entra ID. Gli accessi con e-mail come ID di accesso alternativo emetteranno proxyAddress nel campo Tipo di identificatore di accesso e il nome utente immesso nel campo Identificatore di accesso.

Valori in conflitto tra utenti solo cloud e sincronizzati

All'interno di un tenant, l'UPN di un utente solo cloud può assumere lo stesso valore dell'indirizzo proxy di un altro utente sincronizzato dalla directory locale. In questo scenario, con la funzionalità abilitata, l'utente solo cloud non sarà in grado di accedere con il proprio UPN. Questi sono i passaggi per rilevare le istanze del problema.

1. Aprire una sessione di PowerShell come amministratore, quindi installare il modulo AzureADPreview usando il cmdlet Install-Module:

   Install-Module Microsoft.Graph.Beta
   

   Se richiesto, selezionare Y per installare NuGet o per eseguire l'installazione da un repository non attendibile.

2. Per gestire questa funzionalità è necessario un amministratore globale.

   Accedere al tenant di Microsoft Entra usando il cmdlet Connect-AzureAD:

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

3. Recuperare gli utenti interessati.

   # 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. Per restituire gli utenti interessati:

   # 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. Per restituire gli utenti interessati in 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
   

Passaggi successivi

Per altre informazioni sull'identità ibrida, come l'application proxy di Microsoft Entra o Microsoft Entra Domain Services, vedere Identità ibrida di Azure AD per l'accesso e la gestione dei carichi di lavoro locali.

Per altre informazioni sulle operazioni con l'identità ibrida, vedere Funzionamento della sincronizzazione dell'hash delle password o Funzionamento della sincronizzazione con autenticazione pass-through.