Errore AADSTS50020 - L'account utente del provider di identità non esiste nel tenant

Questo articolo illustra come risolvere i problemi relativi al codice AADSTS50020 di errore restituito se un utente guest di un provider di identità (IdP) non riesce ad accedere a un tenant di risorse in Microsoft Entra ID.

Sintomi

Quando un utente guest tenta di accedere a un'applicazione o a una risorsa nel tenant della risorsa, l'accesso ha esito negativo e viene visualizzato il messaggio di errore seguente:

AADSTS50020: l'account utente 'user@domain.com' dal provider di identità {IdentityProviderURL} non esiste nel tenant {ResourceTenantName}.

Quando un amministratore esamina i log di accesso nel tenant principale, una voce di codice di errore "90072" indica un errore di accesso. Il messaggio di errore indica:

L'account utente {email} dal provider di identità {idp} non esiste nel tenant {tenant} e non può accedere all'applicazione {appId}({appName}) in tale tenant. L'account deve prima essere aggiunto come utente esterno nel tenant. Disconnettersi e accedere di nuovo con un account utente Microsoft Entra diverso.

Causa 1: Gli utenti accedono all'interfaccia di amministrazione di Microsoft Entra usando account Microsoft personali

Quando si tenta di accedere all'interfaccia di amministrazione di Microsoft Entra usando gli account Microsoft personali (Outlook, Hotmail o OneDrive), si è connessi al tenant dei servizi Microsoft per impostazione predefinita. All'interno del tenant predefinito non esiste alcuna directory collegata per l'esecuzione di alcuna azione. Si tratta di un comportamento previsto.

Nell'esperienza precedente, viene creata una directory (ad esempio: UserNamehotmail735.onmicrosoft.com) e collegata all'account personale ed è possibile eseguire azioni come la creazione di account utente nella directory. Il comportamento è stato modificato.

Soluzione: Creare un account Azure con un nuovo tenant

Se si intende avere una directory, è necessario creare un account Azure e un nuovo tenant:

1. Passare a https://azure.microsoft.com/en-us/free/e quindi selezionare Avvia gratuito .
2. Seguire le istruzioni per creare un account Azure.
3. Un tenant verrà generato insieme all'account Azure e verrà designato automaticamente come amministratore globale. In questo modo si concede l'accesso completo a tutte le opzioni all'interno del tenant.

Causa 2: Tipo di account non supportato (account multi-tenant e personali)

Se la registrazione dell'app è impostata su un tipo di account a tenant singolo, gli utenti di altre directory o provider di identità non possono accedere a tale applicazione.

Soluzione: Modificare l'impostazione del gruppo di destinatari di accesso nel manifesto di registrazione dell'app

Per assicurarsi che la registrazione dell'app non sia un tipo di account a tenant singolo, seguire questa procedura:

1. Nel portale di Azure, cerca e seleziona Registrazioni app.

2. Selezionare il nome della registrazione dell'app.

3. Nella barra laterale selezionare Manifesto.

4. Nel codice JSON trovare l'impostazione signInAudience .

5. Controllare se l'impostazione contiene uno dei valori seguenti:

   • AzureADandPersonalMicrosoftAccount
   • AzureADMultipleOrgs
   • PersonalMicrosoftAccount

   Se l'impostazione signInAudience non contiene uno di questi valori, ricreare la registrazione dell'app selezionando il tipo di account corretto. Attualmente non è possibile modificare signInAudience nel manifesto.

Per altre informazioni su come registrare le applicazioni, vedere Guida introduttiva: Registrare un'applicazione con Microsoft Identity Platform.

Causa 3: Usato l'endpoint errato (account personali e dell'organizzazione)

La chiamata di autenticazione deve avere come destinazione un URL corrispondente alla selezione se il tipo di account supportato dalla registrazione dell'app è stato impostato su uno dei valori seguenti:

• Account in qualsiasi directory organizzativa (qualsiasi directory di Microsoft Entra - Multi-tenant)

• Account in qualsiasi directory organizzativa (qualsiasi directory Di Microsoft Entra - Multi-tenant) e account Microsoft personali (ad esempio Skype, Xbox)

• Solo account Microsoft personali

Se si usa https://login.microsoftonline.com/<YourTenantNameOrID>, gli utenti di altre organizzazioni non possono accedere all'applicazione. È necessario aggiungere questi utenti come guest nel tenant specificato nella richiesta. In tal caso, l'autenticazione dovrebbe essere eseguita solo nel tenant. Questo scenario causa l'errore di accesso se si prevede che gli utenti eseseguono l'accesso usando la federazione con un altro tenant o un altro provider di identità.

Soluzione: usare l'URL di accesso corretto

Usare l'URL di accesso corrispondente per il tipo di applicazione specifico, come indicato nella tabella seguente:

Nel codice dell'applicazione applicare questo valore URL nell'impostazione Authority . Per altre informazioni su Authority, vedere Opzioni di configurazione dell'applicazione Microsoft Identity Platform.

Causa 4: Accesso al tenant errato

Quando gli utenti tentano di accedere all'applicazione, vengono inviati un collegamento diretto all'applicazione oppure tentano di ottenere l'accesso tramite https://myapps.microsoft.com. In entrambi i casi, gli utenti vengono reindirizzati all'accesso all'applicazione. In alcuni casi, l'utente potrebbe avere già una sessione attiva che usa un account personale diverso da quello che deve essere usato. Oppure hanno una sessione che usa l'account dell'organizzazione anche se intende usare un account guest personale (o viceversa).

Per assicurarsi che questo scenario sia il problema, cercare i User account valori e Identity provider nel messaggio di errore. Questi valori corrispondono o meno alla combinazione prevista? Ad esempio, un utente ha eseguito l'accesso usando l'account dell'organizzazione al tenant anziché il tenant principale? Oppure un utente ha eseguito l'accesso live.com al provider di identità usando un account personale diverso da quello già invitato?

Soluzione: disconnettersi, quindi accedere di nuovo da un browser diverso o da una sessione del browser privato

Indicare all'utente di aprire una nuova sessione del browser privato o di tentare l'accesso da un browser diverso. In questo caso, gli utenti devono disconnettersi dalla sessione attiva e quindi riprovare ad accedere.

Causa 5: L'utente guest non è stato invitato

L'utente guest che ha tentato di accedere non è stato invitato al tenant.

Soluzione: invitare l'utente guest

Assicurarsi di seguire la procedura descritta in Avvio rapido: Aggiungere utenti guest alla directory nel portale di Azure per invitare l'utente guest.

Causa 6: L'app richiede l'assegnazione dell'utente

Se l'applicazione è un'applicazione aziendale che richiede l'assegnazione dell'utente, si verifica un errore AADSTS50020 se l'utente non è presente nell'elenco di utenti autorizzati a cui è assegnato l'accesso all'applicazione. Per verificare se l'applicazione aziendale richiede l'assegnazione utente:

1. Nella portale di Azure cercare e selezionare Applicazioni aziendali.

2. Selezionare l'applicazione aziendale.

3. Nella barra laterale selezionare Proprietà.

4. Controllare se l'opzione Assegnazione obbligatoria è impostata su Sì.

Soluzione: Assegnare l'accesso agli utenti singolarmente o come parte di un gruppo

Usare una delle opzioni seguenti per assegnare l'accesso agli utenti:

• Per assegnare singolarmente l'accesso utente all'applicazione, vedere Assegnare un account utente a un'applicazione aziendale.

• Per assegnare gli utenti se sono membri di un gruppo assegnato o di un gruppo dinamico, vedere Gestire l'accesso a un'applicazione.

Causa 7: Si è tentato di usare un flusso di credenziali password del proprietario della risorsa per gli account personali

Se un utente tenta di usare il flusso ROPC (Resource Owner Password Credentials) per gli account personali, si verifica un errore AADSTS50020 . Microsoft Identity Platform supporta ROPC solo nei tenant di Microsoft Entra, non negli account personali.

Soluzione: usare un endpoint specifico per il tenant o l'organizzazione

Usare un endpoint specifico del tenant (https://login.microsoftonline.com/<TenantIDOrName>) o l'endpoint dell'organizzazione. Gli account personali che sono invitati in un tenant di Microsoft Entra non possono usare ROPC. Per altre informazioni, vedere Microsoft Identity Platform e Credenziali della password del proprietario della risorsa OAuth 2.0.

Causa 8: Un nome utente eliminato in precedenza è stato ricreato dall'amministratore tenant home

L'errore AADSTS50020 può verificarsi se il nome di un utente guest eliminato in un tenant di risorse viene ricreato dall'amministratore del tenant principale. Per verificare che l'account utente guest nel tenant della risorsa non sia associato a un account utente nel tenant principale, usare una delle opzioni seguenti:

Opzione di verifica 1: verificare se l'utente guest del tenant della risorsa è precedente all'account utente del tenant principale

La prima opzione di verifica prevede il confronto tra l'età dell'utente guest del tenant della risorsa e l'account utente del tenant principale. È possibile eseguire questa verifica usando Microsoft Graph o MSOnline PowerShell.

Microsoft Graph

Eseguire una richiesta all'API Microsoft Graph per esaminare la data di creazione dell'utente, come indicato di seguito:

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

Controllare quindi la data di creazione dell'utente guest nel tenant della risorsa rispetto alla data di creazione dell'account utente nel tenant principale. Lo scenario viene confermato se l'utente guest è stato creato prima della creazione dell'account utente del tenant principale.

MSOnline PowerShell

Eseguire il cmdlet Di PowerShell Get-MsolUser per esaminare la data di creazione dell'utente, come indicato di seguito:

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

Controllare quindi la data di creazione dell'utente guest nel tenant della risorsa rispetto alla data di creazione dell'account utente nel tenant principale. Lo scenario viene confermato se l'utente guest è stato creato prima della creazione dell'account utente del tenant principale.

Opzione di verifica 2: verificare se l'ID di sicurezza alternativo guest del tenant della risorsa è diverso dall'ID rete utente del tenant principale

Quando un utente guest accetta un invito, l'attributo dell'utente LiveID (l'ID di accesso univoco dell'utente) viene archiviato all'interno AlternativeSecurityIds dell'attributo key . Poiché l'account utente è stato eliminato e creato nel tenant principale, il NetID valore per l'account verrà modificato per l'utente nel tenant principale. Confrontare il NetID valore dell'account utente nel tenant principale con il valore della chiave archiviato all'interno AlternativeSecurityIds dell'account guest nel tenant della risorsa, come indicato di seguito:

1. Nel tenant principale recuperare il valore dell'attributo LiveID usando il Get-MsolUser cmdlet di PowerShell:

   Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID
   

2. Nel tenant della risorsa convertire il valore dell'attributo key in AlternativeSecurityIds una stringa con codifica Base64:

   [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
          ).AlternativeSecurityIds.key)
   

3. Convertire la stringa con codifica base64 in un valore esadecimale usando un convertitore online (ad esempio base64.guru).

4. Confrontare i valori del passaggio 1 e 3 per verificare che siano diversi. Oggetto NetID dell'account utente nel tenant principale modificato quando l'account è stato eliminato e ricreato.

Soluzione: reimpostare lo stato di riscatto dell'account utente guest

Reimpostare lo stato di riscatto dell'account utente guest nel tenant della risorsa. È quindi possibile mantenere l'oggetto utente guest senza dover eliminare e quindi ricreare l'account guest. È possibile reimpostare lo stato di riscatto usando il portale di Azure, Azure PowerShell o l'API Microsoft Graph. Per istruzioni, vedere Reimpostare lo stato di riscatto per un utente guest.

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.