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

Riassunto

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' fornito 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. Effettua il logout e accedi nuovamente con un altro account utente Microsoft Entra.

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 al sito Web dell'account Azure e quindi selezionare Prova azure gratuitamente.
  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 multiutenza 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
    • Account personale Microsoft

    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 - Multitenant)

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

  • Account Microsoft personali solo

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 ci si aspetta che gli utenti eseguano l'accesso utilizzando 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:

Tipo di applicazione URL di accesso
Applicazioni multi-tenant https://login.microsoftonline.com/organizations
Account multi-tenant e personali https://login.microsoftonline.com/common
Solo account personali https://login.microsoftonline.com/consumers

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 verificare che questo scenario sia il problema, cercare i valori all'interno di User account e Identity provider nel messaggio di errore. Questi valori corrispondono o meno alla combinazione prevista? Ad esempio, un utente ha eseguito l'accesso al tuo tenant utilizzando il proprio account dell'organizzazione anziché il tenant personale. Oppure un utente si è connesso al provider di identità live.com 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 ospite che ha tentato di accedere non è stato invitato al tenant.

Soluzione: invitare l'utente ospite

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. Nel 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:

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 ulteriori informazioni, vedere Piattaforma Microsoft Identity e le credenziali del proprietario della risorsa della password OAuth 2.0.

Causa 8: Un nome utente precedentemente eliminato è stato ricreato dall'amministratore del tenant principale

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 ospite nel tenant della risorsa non sia associato a un account utente nel tenant principale, usare una delle opzioni seguenti:

Verifica: usare gli strumenti seguenti per verificare lo stato dell'utente guest in Microsoft Entra ID

Per verificare se l'utente guest del tenant della risorsa è più vecchio dell'account utente del tenant principale, si può usare Microsoft Graph, Microsoft Entra PowerShell o Microsoft Graph PowerShell SDK.

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

Quindi, controllare la data di creazione dell'utente ospite nel tenant della risorsa e confrontarla con la 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.

Microsoft Entra PowerShell

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

Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime

Quindi, controllare la data di creazione dell'utente ospite nel tenant della risorsa e confrontarla con la 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.

SDK PowerShell di Microsoft Graph

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

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p

Quindi, controllare la data di creazione dell'utente ospite nel tenant della risorsa e confrontarla con la 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.

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

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 le istruzioni, vedere Reimpostare lo stato di riscatto per un utente ospite.

  • Last updated on