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

Molte organizzazioni vogliono 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 (User Principal Name) di Microsoft Entra è impostato sullo stesso valore dell'UPN locale.
• Modificando l'UPN di Microsoft Entra si crea una corrispondenza errata tra gli ambienti locali e di Microsoft Entra che potrebbe causare problemi con determinate applicazioni e servizi.
• A causa di motivi aziendali o di conformità, l'organizzazione non vuole 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 è stato rinominato in Fabrikam, anziché continuare ad accedere con l'UPN ana@contoso.com precedente è possibile usare l'indirizzo e-mail come ID di accesso alternativo. Per accedere a un'applicazione o a un servizio, gli utenti accedono a Microsoft Entra ID usando l'indirizzo e-mail non UPN, come ana@fabrikam.com.

Questo articolo illustra come abilitare e usare l’indirizzo e-mail come ID di accesso alternativo.

Operazioni preliminari

Ecco cosa è necessario sapere sull’indirizzo e-mail come ID di accesso alternativo:

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

• La funzionalità abilita l'accesso con ProxyAddresses, oltre all'UPN, per gli utenti di Microsoft Entra autenticati nel cloud. Altre informazioni su come questo si applica alla collaborazione business-to-business (B2B) di Microsoft Entra sono disponibili nella sezione B2B.

• Quando un utente accede con un indirizzo e-mail non UPN, le attestazioni unique_name e preferred_username (se presenti) nel token ID restituiranno l’indirizzo e-mail non UPN.

  • Se l’indirizzo e-mail non UPN in uso diventa obsoleto (non appartiene più all'utente), queste attestazioni restituiranno invece l'UPN.

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

• 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 l'implementazione a fasi per la prima volta, il limite di utenti è 200 per evitare che si verifichi un timeout nell'esperienza utente. Dopo aver aggiunto il gruppo, è possibile aggiungervi altri utenti direttamente, se necessario.

  Per gestire questa funzionalità è necessario un amministratore globale.

Limiti dell'anteprima

Nello stato di anteprima corrente, i limiti seguenti si applicano all’indirizzo e-mail come ID di accesso alternativo:

• Esperienza utente: gli utenti possono visualizzare il proprio UPN, anche quando hanno eseguito l'accesso con l’indirizzo e-mail non UPN. È possibile visualizzare il comportamento di esempio seguente:

  • All'utente viene richiesto di accedere con l'UPN quando viene indirizzato all'accesso a Microsoft Entra con login_hint=<non-UPN email>.
  • Quando un utente accede con un indirizzo e-mail non UPN e immette una password non corretta, la pagina "Immetti la password" cambia per visualizzare l'UPN.
  • In alcuni siti e app Microsoft, ad esempio Microsoft Office, il controllo Gestione account visualizzato in genere in alto a destra potrebbe mostrare l'UPN dell'utente anziché l’indirizzo e-mail non UPN usato per accedere.

• 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 altre informazioni, vedere Procedura: Analizzare i rischi.
  • Quando un utente ha eseguito l'accesso con un indirizzo e-mail non UPN, non può modificare la password. La reimpostazione della password self-service di Microsoft Entra (SSPR) dovrebbe funzionare come previsto. Durante la reimpostazione della password self-service, l'utente può visualizzare l'UPN se verifica la propria identità usando un indirizzo e-mail non UPN.

• Scenari non supportati: gli scenari seguenti non sono supportati. Accedere con un indirizzo e-mail 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
  • Criteri di protezione delle app e Single Sign-On in Piattaforma per dispositivi mobili
  • Autenticazione legacy, ad esempio POP3 e SMTP
  • Skype for Business

• App non supportate: alcune applicazioni di terze parti potrebbero non funzionare come previsto se presuppongono che le attestazioni unique_name o preferred_username siano non modificabili o corrispondano sempre a un attributo utente specifico, ad esempio 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ò essere 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. Per altre informazioni su questo problema, vedere la sezione Risoluzione dei problemi.

Panoramica delle opzioni per l'ID di accesso alternativo

Per accedere a Microsoft Entra ID, gli utenti immettono un valore che identifica in modo univoco il proprio account. In passato, si poteva usare solo l'UPN di Microsoft Entra come identificatore di accesso.

Per le organizzazioni in cui l'UPN locale è l'indirizzo di posta elettronica di accesso preferito dell'utente, questo approccio era ottimale. Queste organizzazioni impostavano l'UPN di Microsoft Entra sullo stesso valore dell'UPN locale, e gli utenti avrebbero avuto 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 Active Directory Domain Services locale per consentire l'accesso con un ID di accesso alternativo. L'impostazione dell'UPN di Microsoft Entra sullo stesso valore dell'UPN locale non è un'opzione possibile, perché Microsoft Entra ID richiederebbe poi agli utenti di accedere con tale valore.

ID di accesso alternativo in Microsoft Entra Connect

La soluzione alternativa tipica a questo problema consiste nell'impostare l'UPN di Microsoft Entra sull'indirizzo di posta elettronica con cui l'utente si aspetta di eseguire l'accesso. Questo approccio funziona, anche se comporta UPN diversi tra AD locale e Microsoft Entra ID, e questa configurazione non è compatibile con tutti i carichi di lavoro di Microsoft 365.

Indirizzo e-mail come ID di accesso alternativo

Un approccio diverso consiste nel sincronizzare Microsoft Entra ID e gli UPN locali sullo stesso valore e quindi configurare Microsoft Entra ID per consentire agli utenti di accedere a Microsoft Entra ID con un indirizzo e-mail verificato. Per consentire questa funzionalità, si specifica uno o più indirizzi e-mail 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, è necessario sincronizzare l'ambiente di Active Directory Domain Services 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 immette il proprio nome utente e la password in Microsoft Entra ID, il che convalida le credenziali ed emette un ticket. Quando gli utenti accedono a Microsoft Entra ID, elimina la necessità da parte dell'organizzazione di ospitare e gestire un'infrastruttura di AD FS.

Uno degli attributi utente che viene automaticamente sincronizzato da Microsoft Entra Connect è ProxyAddresses. Se per gli utenti è stato definito un indirizzo e-mail nell'ambiente di Active Directory Domain Services locale come parte dell'attributo ProxyAddresses, questo viene automaticamente sincronizzato in Microsoft Entra ID. L'indirizzo e-mail può quindi essere usato direttamente nel processo di accesso di 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 Microsoft Entra B2B Collaboration 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 da parte del 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 non controllare solo l’identificatore di accesso 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 Graph PowerShell.

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 > Email come ID di accesso alternativo.

   

3. Fare clic sulla casella di controllo accanto a Email 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 non controllare solo l’identificatore di accesso 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 sull’installazione, 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 sia 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 o abilitato oppure se sono presenti altri attributi sul criterio che si vuole preservare, 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 viene aggiunto l'attributo AlternateIdLogin e viene mantenuto 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 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 funzionalità per specifici gruppi di Microsoft Entra. È consigliabile che gli amministratori tenant usino l'implementazione a fasi per testare l'accesso degli utenti con un indirizzo di posta elettronica. 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, quindi 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 esistenti per questa funzionalità, creare un nuovo criterio di implementazione a fasi e prendere nota dell'ID criterio:

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

5. Trovare l'ID directoryObject del gruppo da aggiungere ai criteri di implementazione a fasi. Annotare il valore restituito per il parametro Id, perché 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. Potrebbe essere necessaria fino a 1 ora prima che gli utenti del gruppo possano accedere a Microsoft Entra ID con un indirizzo e-mail come 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 prima che possano accedere a Microsoft Entra ID con un indirizzo e-mail come 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 criteri

Per rimuovere un criterio di implementazione a fasi, disabilitare prima di tutto il criterio e quindi rimuoverlo dal sistema:

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

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

Per verificare che gli utenti possano accedere con un indirizzo e-mail, passare a https://myprofile.microsoft.com e accedere con un indirizzo e-mail non UPN, ad esempio balas@fabrikam.com. L'esperienza di accesso deve essere analoga a quella di un accesso con l’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 è stato abilitato l’indirizzo 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 criteri HRD, verificare che il criterio HomeRealmDiscoveryPolicy di Microsoft Entra ID abbia la proprietà di 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 il criterio FeatureRolloutPolicy di Microsoft Entra ID abbia la proprietà IsEnabled impostata su True:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

3. Assicurarsi che l'account utente abbia l'indirizzo di posta elettronica impostato nell'attributo ProxyAddresses in Microsoft Entra ID.

Log di accesso

Per altre informazioni, è possibile consultare i log di accesso in Microsoft Entra ID. Gli accessi con indirizzo e-mail come ID di accesso alternativo genereranno 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. Di seguito è riportata la procedura per rilevare le istanze di questo 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. Ottenere 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, ad esempio l’Application Proxy Microsoft Entra o Microsoft Entra Domain Services, vedere Identità ibrida di Microsoft Entra 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.