Share via

Errore AADSTS50020: l'account utente del provider di identità non esiste nel tenant

  • Articolo

Questo articolo consente di 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 non riesce e viene visualizzato il messaggio di errore seguente:

AADSTS50020: l'account utente 'user@domain.com' del 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 essere aggiunto prima come utente esterno nel tenant. Disconnettersi e accedere di nuovo con un altro account utente Microsoft Entra.

Causa 1: Gli utenti accedono a Interfaccia di amministrazione di Microsoft Entra usando account Microsoft personali

Quando si tenta di accedere a Interfaccia di amministrazione di Microsoft Entra usando gli account Microsoft personali (Outlook, Hotmail o OneDrive), per impostazione predefinita si è connessi al tenant di Servizi Microsoft. All'interno del tenant predefinito non è presente alcuna directory collegata per l'esecuzione di azioni. Questo comportamento è previsto.

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

Soluzione: Create un account Azure con un nuovo tenant

Se si vuole 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 libera .
  2. Seguire le istruzioni per creare un account Azure.
  3. Un tenant verrà generato insieme all'account Azure e l'utente verrà automaticamente designato come amministratore globale. In questo modo si concede l'accesso completo a tutte le opzioni all'interno del tenant.

Causa 2: usato 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 cercare e selezionare 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. Verificare 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 il Microsoft Identity Platform.

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

La chiamata di autenticazione deve essere destinata a un URL corrispondente alla selezione se il tipo di account supportato della registrazione dell'app è stato impostato su uno dei valori seguenti:

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

  • Account in qualsiasi directory organizzativa (qualsiasi directory 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 acceda usando la federazione con un altro tenant o 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 Microsoft Identity Platform opzioni di configurazione dell'applicazione.

Causa 4: Accesso al tenant errato

Quando gli utenti provano ad accedere all'applicazione, gli viene inviato un collegamento diretto all'applicazione oppure tentano di ottenere l'accesso tramite https://myapps.microsoft.com. In entrambi i casi, gli utenti vengono reindirizzati per accedere 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. In alternativa, hanno una sessione che usa l'account dell'organizzazione, sebbene intendessero 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é al 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 privata

Indicare all'utente di aprire una nuova sessione del browser privata o di fare in modo che l'utente tenti di accedere da un browser diverso. In questo caso, gli utenti devono disconnettersi dalla sessione attiva e quindi provare di nuovo 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 Guida introduttiva: 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 degli utenti autorizzati a cui viene assegnato l'accesso all'applicazione. Per verificare se l'applicazione aziendale richiede l'assegnazione dell'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 della 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 . Il Microsoft Identity Platform supporta ROPC solo all'interno di tenant Microsoft Entra, non di account personali.

Soluzione: usare un endpoint specifico del tenant o dell'organizzazione

Usare un endpoint specifico del tenant (https://login.microsoftonline.com/<TenantIDOrName>) o l'endpoint dell'organizzazione. Gli account personali invitati a un tenant Microsoft Entra non possono usare ROPC. Per altre informazioni, vedere Microsoft Identity Platform e OAuth 2.0 Resource Owner Password Credentials.

Causa 8: un nome utente eliminato in precedenza è stato ricreato dall'amministratore del tenant principale

È possibile che si verifichi un errore AADSTS50020 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 delle risorse 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 di risorse è più vecchio dell'account utente del tenant principale

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

Microsoft Graph

Inviare una richiesta al API Graph ms 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

Nota

Il modulo PowerShell MSOnline è impostato per essere deprecato. Poiché è incompatibile anche con PowerShell Core, assicurarsi di usare una versione di PowerShell compatibile in modo da poter eseguire i comandi seguenti.

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.

Nota

I moduli PowerShell di Azure AD e MSOnline saranno deprecati a partire dal 30 marzo 2024. Per ulteriori informazioni, leggere l'aggiornamento sulla deprecazione. Dopo questa data, il supporto per questi moduli è limitato all'assistenza per la migrazione a Microsoft Graph PowerShell SDK e alle correzioni per la sicurezza. I moduli deprecati continueranno a funzionare fino al 30 marzo 2025.

È consigliabile effettuare la migrazione a Microsoft Graph PowerShell per interagire con Microsoft Entra ID (in precedenza Azure AD). Per le domande più comuni sulla migrazione, consultare Domande frequenti sulla migrazione. Nota: le versioni 1.0.x di MSOnline potrebbero subire interruzioni dopo il 30 giugno 2024.

Opzione di verifica 2: verificare se l'ID di sicurezza alternativo guest del tenant di risorse differisce dall'ID rete utente del tenant principale

Nota

Il modulo PowerShell MSOnline è impostato per essere deprecato. Poiché è incompatibile anche con PowerShell Core, assicurarsi di usare una versione di PowerShell compatibile in modo da poter eseguire i comandi seguenti.

Quando un utente guest accetta un invito, l'attributo dell'utente LiveID (l'ID di accesso univoco dell'utente) viene archiviato all'interno dell'attributo AlternativeSecurityIdskey . Poiché l'account utente è stato eliminato e creato nel tenant principale, il NetID valore dell'account sarà cambiato per l'utente nel tenant principale. Confrontare il NetID valore dell'account utente nel tenant principale con il valore della chiave archiviato all'interno dell'account AlternativeSecurityIds 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 all'interno AlternativeSecurityIds di in 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 dei passaggi 1 e 3 per verificare che siano diversi. L'oggetto NetID dell'account utente nel tenant principale è stato 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 delle risorse. È quindi possibile mantenere l'oggetto utente guest senza dover eliminare e quindi ricreare l'account guest. È possibile reimpostare lo stato di riscatto usando portale di Azure, Azure PowerShell o microsoft API 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.