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

Nota

L'accesso a Microsoft Entra ID usando l'indirizzo di posta elettronica come ID di accesso alternativo è una funzione di anteprima pubblica di Microsoft Entra ID. Per altre informazioni sulle anteprime, vedere Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.

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 ha rinominato Fabrikam anziché continuare ad accedere con l'UPN legacy ana@contoso.com , è 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à abilita l'accesso con ProxyAddresses, oltre all'UPN, per gli utenti di Microsoft Entra autenticati nel cloud. Maggiori informazioni su come questo si applica alla collaborazione business-to-business (B2B) di Microsoft Entra nella sezione B2B.
• Quando un utente effettua l'accesso con un'email che non è un UPN, le attestazioni unique_name e preferred_username (se presenti) nel token ID restituiranno l'email 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).
• Sono disponibili due opzioni per la configurazione della funzionalità:
  • 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.

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 visualizzare il proprio UPN, anche quando hanno eseguito l'accesso con il messaggio 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 accede con un messaggio di posta elettronica 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 Account Manager visualizzato in genere in alto a destra potrebbe visualizzare l'UPN dell'utente anziché il messaggio di posta elettronica non UPN usato per accedere.

• Flussi non supportati : alcuni flussi non sono attualmente compatibili con messaggi di posta elettronica non UPN, ad esempio i seguenti:

  • Microsoft Entra ID Protection non associa le email senza UPN con il rilevamento dei rischi delle credenziali trapelate. 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 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 : gli scenari seguenti non sono supportati. Accedere con un indirizzo di posta elettronica non UPN per:

  • Dispositivi aggiunti ibridi di Microsoft Entra
  • Dispositivi associati a Microsoft Entra
  • Dispositivi Microsoft Entra registrati
  • Singolo Sign-On e politiche di protezione delle app su piattaforma mobile
  • Autenticazione legacy, ad esempio POP3 e SMTP

• App non supportate : alcune applicazioni di terze parti potrebbero non funzionare come previsto se presuppongono che le unique_name attestazioni 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 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 offrire questa possibilità, definire 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.

Opzione	Descrizione
ID di accesso alternativo per AD FS	Abilitare l'accesso con un attributo alternativo (come posta elettronica) per gli utenti di AD FS.
ID di accesso alternativo in Microsoft Entra Connect	Sincronizzare un attributo alternativo (come posta elettronica) come UPN di Microsoft Entra.
Indirizzo di posta elettronica come ID di accesso alternativo	Abilitare l'accesso con dominio ProxyAddresses verificato per gli utenti di Microsoft Entra.

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 corretto per la soluzione di gestione delle identità ibrida 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 sincronizzati automaticamente da Microsoft Entra Connect è ProxyAddresses. Se gli utenti hanno un indirizzo di posta elettronica definito nell'ambiente di Active Directory Domain Services locale come parte dell'attributo ProxyAddresses , viene sincronizzato automaticamente 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.

Importante

Solo gli indirizzi di posta elettronica nei domini verificati per il tenant vengono sincronizzati in Microsoft Entra ID. Ogni tenant di Microsoft Entra presenta uno o più domini verificati per i quali si può dimostrare la proprietà e che sono associati in modo univoco al tenant.

Per altre informazioni, vedere Aggiungere e verificare un nome di dominio personalizzato in Microsoft Entra ID.

Accesso degli utenti ospiti 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 dal tenant della risorsa per abilitare questa funzionalità.

Nota

Quando si usa un ID di accesso alternativo in un endpoint tenant di risorse per cui non è abilitata la funzionalità, il processo di accesso funzionerà senza problemi, ma l'accesso SSO verrà interrotto.

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

Nota

Questa opzione di configurazione usa criteri HRD. Per altre informazioni, vedere tipo di risorsa homeRealmDiscoveryPolicy.

Una volta che gli utenti con l'attributo ProxyAddresses applicato vengono sincronizzati con Microsoft Entra ID usando Microsoft Entra Connect, è necessario abilitare la funzionalità per consentire agli utenti di accedere con posta elettronica come ID di accesso alternativo per il tenant. Questa funzionalità indica ai server di accesso di Microsoft Entra di controllare non solo l'identificatore di accesso rispetto ai valori UPN, ma anche rispetto ai valori ProxyAddresses per l'indirizzo di posta elettronica.

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

Interfaccia di amministrazione di Microsoft Entra

1. Accedi all'interfaccia di amministrazione di Microsoft Entra come almeno un amministratore di identità ibrida .

2. Passare a Entra ID>Entra Connect>Entra Connect Sync

3. Selezionare Email (Posta elettronica) come ID di accesso alternativo**.

   

4. Fare clic sulla casella di controllo accanto a Posta elettronica come ID di accesso alternativo.

5. 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

Nota

Questa opzione di configurazione usa criteri HRD. Per altre informazioni, vedere tipo di risorsa homeRealmDiscoveryPolicy.

Una volta che gli utenti con l'attributo ProxyAddresses applicato vengono sincronizzati con Microsoft Entra ID usando Microsoft Entra Connect, è necessario abilitare la funzionalità per consentire agli utenti di accedere con posta elettronica come ID di accesso alternativo per il tenant. Questa funzionalità indica ai server di accesso di Microsoft Entra di controllare non solo l'identificatore di accesso rispetto ai valori UPN, ma anche rispetto ai valori ProxyAddresses per l'indirizzo di posta elettronica.

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

   Install-Module Microsoft.Graph
   

   Per altre informazioni sull'installazione, vedere Installare Microsoft Graph PowerShell SDK.

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. Controllare se nel tenant esiste già un oggetto HomeRealmDiscoveryPolicy usando il Get-MgPolicyHomeRealmDiscoveryPolicy cmdlet come indicato di seguito:

   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 HomeRealmDiscoveryPolicy al tenant, usare il New-MgPolicyHomeRealmDiscoveryPolicy cmdlet e impostare l'attributo AlternateIdLoginsu "Enabled": true , come illustrato 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à presente un criterio configurato, verificare se l'attributo AlternateIdLogin è abilitato, come illustrato nell'output dei criteri 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 esistono altri attributi nel criterio che si desidera mantenere, aggiornare i criteri esistenti usando il Update-MgPolicyHomeRealmDiscoveryPolicy cmdlet .

   Importante

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

   L'esempio seguente aggiunge l'attributo AlternateIdLogin e mantiene 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 mostri le modifiche e che l'attributo AlternateIdLogin sia ora abilitato:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Nota

Dopo l'applicazione della politica, la propagazione può richiedere fino a un'ora e gli utenti potranno accedere utilizzando l'e-mail come ID di accesso alternativo.

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

Nota

Questa opzione di configurazione usa i criteri di implementazione a fasi. Per altre informazioni, vedere featureRolloutPolicy resource type (Tipo di risorsa FeatureRolloutPolicy).

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 ambiente, devono usare la politica HRD.

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 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. Si noti 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. 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"

Test di login dell'utente 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 utilizza la criteri HRD, verificare che la proprietà di definizione HomeRealmDiscoveryPolicyAlternateIdLogin sia impostata a "Enabled": true e che la proprietà IsOrganizationDefault sia impostata a True:

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Se si usano criteri di implementazione a fasi, verificare che la proprietà IsEnabled di Microsoft Entra ID FeatureRolloutPolicy sia 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

Puoi consultare i registri di accesso in Microsoft Entra ID per ulteriori informazioni. Gli accessi con indirizzo email 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 Microsoft Graph usando il cmdlet Install-Module :

   Install-Module Microsoft.Graph.Authentication
   

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

2. Connettersi a Microsoft Graph:

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

3. Raccogliere 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 visualizzare 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 il proxy dell'applicazione 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 di gestione delle identità ibride, vedere funzionamento della sincronizzazione dell'hash delle password o della sincronizzazione dell'autenticazione pass-through .