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

Nota

Accedere a Microsoft Entra ID con posta elettronica come ID di accesso alternativo è una funzionalità 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 vogliono consentire agli utenti di accedere a Microsoft Entra ID usando le stesse credenziali dell'ambiente 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.
• La modifica dell'UPN di Microsoft Entra crea una mancata corrispondenza tra ambienti locali e Microsoft Entra che potrebbero 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 all'ID Microsoft Entra.

Per passare all'autenticazione ibrida, è possibile configurare Microsoft Entra ID per consentire agli utenti di accedere con il proprio messaggio 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 accedono all'ID Microsoft Entra usando il messaggio di posta elettronica non UPN, ad esempio ana@fabrikam.com.

Questo articolo illustra come abilitare e usare la posta elettronica come ID di accesso alternativo.

Operazioni preliminari

Ecco cosa è necessario sapere sulla 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. Altre informazioni su come si applicano alla collaborazione business-to-business (B2B) di Microsoft Entra nella sezione B2B .
• Quando un utente accede con un messaggio di posta elettronica non UPN, le unique_name attestazioni e preferred_username (se presenti) nel token ID restituiranno il messaggio di posta elettronica non UPN.
  • Se il messaggio di posta elettronica 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).
• 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 il ruolo Amministrazione istrator globale, Application Amministrazione istrator o Cloud Application Amministrazione istrator.
  • Criteri di implementazione a fasi : usare questa opzione per testare la funzionalità con specifici gruppi di Microsoft Entra. Sono necessari privilegi di Amministrazione istrator globali. Quando si aggiunge un gruppo di sicurezza per l'implementazione a fasi, sono limitati a 200 utenti per evitare un timeout dell'esperienza utente. Dopo aver aggiunto il gruppo, è possibile aggiungere altri utenti direttamente al gruppo, in base alle esigenze.

Limiti dell'anteprima

Nello stato di anteprima corrente, le limitazioni seguenti si applicano alla 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 l'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:

  • Identity Protection non corrisponde ai messaggi di posta elettronica non UPN con il rilevamento dei rischi delle credenziali perse. Questo rilevamento dei rischi usa l'UPN per trovare le corrispondenze con le credenziali perse. Per altre informazioni, vedere Procedura: Analizzare i rischi.
  • Quando un utente ha eseguito l'accesso con un messaggio di posta elettronica non UPN, non può modificare la password. La reimpostazione della password self-service di Microsoft Entra dovrebbe funzionare come previsto. Durante la reimpostazione della password self-service, l'utente potrebbe visualizzare l'UPN se verifica la propria identità usando un messaggio di posta elettronica non UPN.

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

  • Dispositivi ibridi aggiunti a Microsoft Entra
  • Dispositivi aggiunti a Microsoft Entra
  • Dispositivi registrati di Microsoft Entra
  • Credenziali della password del proprietario della risorsa (ROPC)
  • Criteri di protezione dell'accesso Single Sign-On e delle app in Mobile Platform
  • 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 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 dinamici.
  • Gli oggetti contatto all'interno del gruppo impediranno l'aggiunta del gruppo a un criterio 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 alternative per l'ID di accesso

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

Per le organizzazioni in cui l'UPN locale è l'indirizzo di posta elettronica di accesso preferito dell'utente, questo approccio è stato ottimale. Queste organizzazioni impostano l'UPN di Microsoft Entra sullo stesso valore dell'UPN locale e gli utenti avranno 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 perché Microsoft Entra ID richiederebbe quindi agli utenti di accedere con tale valore.

ID di accesso alternativo in Microsoft Entra Connessione

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 di posta elettronica come ID di accesso alternativo

Un approccio diverso consiste nel sincronizzare l'ID Microsoft Entra e gli UPN locali con lo stesso valore e quindi configurare l'ID Entra di Microsoft per consentire agli utenti di accedere all'ID Microsoft Entra con un messaggio 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 Connessione.

Opzione	Descrizione
ID di accesso alternativo per AD FS	Abilitare l'accesso con un attributo alternativo (ad esempio Mail) per gli utenti di AD FS.
ID di accesso alternativo in Microsoft Entra Connessione	Sincronizzare un attributo alternativo, ad esempio Mail, come UPN di Microsoft Entra.
Indirizzo di posta elettronica come ID di accesso alternativo	Abilitare l'accesso con proxyAddresses di dominio 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 all'ID Microsoft Entra.

Per supportare questo approccio di autenticazione ibrida, sincronizzare l'ambiente di Active Directory Domain Services locale con Microsoft Entra ID usando Microsoft Entra Connessione 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 invia il nome utente e la password a Microsoft Entra ID, che convalida le credenziali e rilascia un ticket. Quando gli utenti accedono all'ID Microsoft Entra, rimuove la necessità dell'organizzazione di ospitare e gestire un'infrastruttura AD FS.

Uno degli attributi utente sincronizzati automaticamente da Microsoft Entra Connessione è 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ò quindi essere usato direttamente nel processo di accesso di Microsoft Entra come ID di accesso alternativo.

Importante

Solo i messaggi di posta elettronica nei domini verificati per il tenant vengono sincronizzati con Microsoft Entra ID. Ogni tenant di Microsoft Entra ha uno o più domini verificati, per i quali si è dimostrata la proprietà e sono associati in modo univoco al tenant.

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

Accesso utente guest B2B con un indirizzo di posta elettronica

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 la posta elettronica come ID di accesso alternativo è abilitata nel tenant principale, gli utenti di Microsoft Entra possono eseguire l'accesso guest con posta elettronica 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 che non dispone della funzionalità abilitata, 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 Connessione, è 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.

Durante l'anteprima sono attualmente necessarie le autorizzazioni di Global Amministrazione istrator per abilitare l'accesso con posta elettronica come ID di accesso alternativo. È possibile usare l'interfaccia di amministrazione di Microsoft Entra o Graph PowerShell per configurare la funzionalità.

Interfaccia di amministrazione di Microsoft Entra

Suggerimento

I passaggi descritti in questo articolo possono variare leggermente in base al portale da cui si inizia.

1. Accedere all'interfaccia di amministrazione di Microsoft Entra come global Amministrazione istrator.

2. Dal menu di spostamento sul lato sinistro della finestra Microsoft Entra selezionare Microsoft Entra Connessione > Posta elettronica come ID di accesso alternativo.

   

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

4. Fare clic su Salva.

   

Dopo aver applicato i criteri, la propagazione può richiedere fino a un'ora e consentire agli utenti di accedere usando l'ID di accesso alternativo.

PowerShell

Nota

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

Dopo che gli utenti con l'attributo ProxyAddresses applicato vengono sincronizzati con Microsoft Entra ID usando Microsoft Entra Connessione, è 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 completare i passaggi seguenti, sono necessari privilegi globali Amministrazione istrator:

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 Connect-MgGraph cmdlet :

   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 AlternateIdLogin su "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
   

   Quando il criterio è stato creato correttamente, il comando restituisce l'ID criterio, come illustrato 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
   

   Confermare che il criterio aggiornato riflette le modifiche e che l'attributo AlternateIdLogin sia ora abilitato:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Nota

Dopo l'applicazione dei criteri, la propagazione può richiedere fino a un'ora e consentire agli utenti di accedere usando posta elettronica come ID di accesso alternativo.

Rimozione dei criteri

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

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

Abilitare l'implementazione a fasi per testare l'accesso dell'utente con un indirizzo di posta elettronica

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. È consigliabile che gli amministratori tenant usino l'implementazione a fasi per testare l'accesso utente con un indirizzo di posta elettronica. Quando gli amministratori sono pronti a distribuire questa funzionalità nell'intero tenant, devono usare i criteri HRD.

Per completare i passaggi seguenti, sono necessarie le autorizzazioni global Amministrazione istrator:

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 Connessione-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 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-MgGroup -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. Potrebbero essere necessarie fino a 1 ora prima che gli utenti del gruppo possano accedere a Microsoft Entra ID con posta elettronica 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 di poter accedere a Microsoft Entra ID con posta elettronica 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 dei 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 dell'utente con un indirizzo di posta elettronica

Per verificare che gli utenti possano accedere con posta elettronica, passare a https://myprofile.microsoft.com e accedere con un messaggio di posta elettronica non UPN, ad esempio balas@fabrikam.com. L'esperienza di accesso dovrebbe avere lo stesso aspetto dell'accesso con l'UPN.

Risoluzione dei problemi

Se gli utenti hanno problemi di accesso con il proprio indirizzo di posta elettronica, esaminare la procedura di risoluzione dei problemi seguente:

1. Assicurarsi che sia stata abilitata almeno un'ora dal momento che la posta elettronica come ID di accesso alternativo è stata abilitata. 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 la proprietà Didefinizione AlternateIdLogin sia 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 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

Per altre informazioni, vedere i log di accesso in Microsoft Entra ID . Gli accessi con indirizzo di posta elettronica come ID di accesso alternativo verranno generati proxyAddress nel campo Tipo di identificatore di accesso e nel 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. Ecco i passaggi 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. Accedere al tenant di Microsoft Entra come global Amministrazione istrator usando il cmdlet Connessione-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 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 con l'identità ibrida, vedere Funzionamento della sincronizzazione dell'hash delle password o Funzionamento della sincronizzazione con autenticazione pass-through.