Fout AADSTS50020: gebruikersaccount van id-provider bestaat niet in de tenant

Dit artikel helpt u bij het oplossen van foutcodes AADSTS50020 die worden geretourneerd als een gastgebruiker van een id-provider (IdP) zich niet kan aanmelden bij een resourcetenant in Microsoft Entra ID.

Symptomen

Wanneer een gastgebruiker probeert toegang te krijgen tot een toepassing of resource in de resourcetenant, mislukt de aanmelding en wordt het volgende foutbericht weergegeven:

AADSTS50020: Gebruikersaccount 'user@domain.com' van id-provider {IdentityProviderURL} bestaat niet in tenant {ResourceTenantName}.

Wanneer een beheerder de aanmeldingslogboeken op de basistenant controleert, geeft een foutcodevermelding 90072 een aanmeldingsfout aan. In het foutbericht wordt het volgende aangegeven:

Gebruikersaccount {email} van id-provider {idp} bestaat niet in tenant {tenant} en heeft geen toegang tot de toepassing {appId}({appName}) in die tenant. Het account moet eerst als externe gebruiker in de tenant worden toegevoegd. Meld u af en meld u opnieuw aan met een ander Microsoft Entra-gebruikersaccount.

Oorzaak 1:Gebruikers melden zich aan bij het Microsoft Entra-beheercentrum met behulp van persoonlijke Microsoft-accounts

Wanneer u zich probeert aan te melden bij het Microsoft Entra-beheercentrum met uw persoonlijke Microsoft-accounts (Outlook, Hotmail of OneDrive), bent u standaard verbonden met de Microsoft Services-tenant. Binnen de standaardtenant is er geen gekoppelde map voor het uitvoeren van acties. Dit gedrag is verwacht.

In de vorige ervaring wordt een map (bijvoorbeeld: UserNamehotmail735.onmicrosoft.com) gemaakt en gekoppeld aan het persoonlijke account en kunt u acties uitvoeren, zoals het maken van gebruikersaccounts in de directory. Het gedrag is nu gewijzigd.

Oplossing: Een Azure-account maken met een nieuwe tenant

Als u een directory wilt aanmaken, moet u een Azure-account aanmaken en een nieuwe tenant instellen.

1. Blader naar https://azure.microsoft.com/en-us/free/ en selecteer vervolgens Gratis Starten.
2. Volg de instructies voor het maken van een Azure-account.
3. Er wordt een tenant gegenereerd naast het Azure-account en u wordt automatisch aangewezen als globale beheerder. Hiermee krijgt u volledige toegang tot alle opties binnen deze tenant.

Oorzaak 2: Gebruikt niet-ondersteund accounttype (multitenant- en persoonlijke accounts)

Als uw app-registratie is ingesteld op een accounttype met één tenant, kunnen gebruikers van andere directory's of id-providers zich niet aanmelden bij die toepassing.

Oplossing: De instelling voor de aanmeldingsdoelgroep wijzigen in het app-registratiemanifest

Voer de volgende stappen uit om ervoor te zorgen dat uw app-registratie geen accounttype met één tenant is:

1. Zoek in de Azure-portalApp-registraties en selecteer deze optie.

2. Selecteer de naam van uw app-registratie.

3. Selecteer Manifest in de zijbalk.

4. Zoek in de JSON-code de instelling signInAudience .

5. Controleer of de instelling een van de volgende waarden bevat:

   • AzureAD en Persoonlijk Microsoft Account
   • AzureADMultipleOrgs
   • Persoonlijk Microsoft-account

   Als de signInAudience-instelling geen van deze waarden bevat, maakt u de app-registratie opnieuw door het juiste accounttype te selecteren. U kunt signInAudience momenteel niet wijzigen in het manifest.

Zie quickstart: Een toepassing registreren bij het Microsoft Identity Platform voor meer informatie over het registreren van toepassingen.

Oorzaak 3: Het verkeerde eindpunt gebruikt (persoonlijke accounts en organisatieaccounts)

Uw verificatieoproep moet zich richten op een URL die overeenkomt met uw selectie als het ondersteunde accounttype van uw app-registratie is ingesteld op een van de volgende waarden:

• Accounts in elke organisatiemap (Elke Microsoft Entra-map - Multitenant)

• Accounts in elke directory van een organisatie (Elke Microsoft Entra-directory - multi-tenant) en persoonlijke Microsoft-accounts (bijvoorbeeld Skype, Xbox)

• Alleen persoonlijke Microsoft-accounts

Als u gebruikt https://login.microsoftonline.com/<YourTenantNameOrID>, hebben gebruikers van andere organisaties geen toegang tot de toepassing. U moet deze gebruikers toevoegen als gasten in de tenant die is opgegeven in de aanvraag. In dat geval wordt verwacht dat de verificatie alleen op uw tenant wordt uitgevoerd. Dit scenario veroorzaakt de aanmeldingsfout als u verwacht dat gebruikers zich aanmelden met behulp van federatie met een andere tenant of id-provider.

Oplossing: de juiste aanmeldings-URL gebruiken

Gebruik de bijbehorende aanmeldings-URL voor het specifieke toepassingstype, zoals vermeld in de volgende tabel:

Toepassingstype	Aanmeld-URL
Toepassingen met meerdere tenants	https://login.microsoftonline.com/organizations
Multitenant- en persoonlijke accounts	https://login.microsoftonline.com/common
Alleen persoonlijke accounts	https://login.microsoftonline.com/consumers

Pas in uw toepassingscode deze URL-waarde toe in de Authority instelling. Zie configuratieopties voor AuthorityMicrosoft Identity Platform-toepassingen voor meer informatie.

Oorzaak 4: Aangemeld bij de verkeerde tenant

Wanneer gebruikers toegang proberen te krijgen tot uw toepassing, worden ze een directe koppeling naar de toepassing verzonden of proberen ze toegang te krijgen via https://myapps.microsoft.com. In beide gevallen worden gebruikers omgeleid om zich aan te melden bij de toepassing. In sommige gevallen heeft de gebruiker mogelijk al een actieve sessie die gebruikmaakt van een ander persoonlijk account dan het account dat bedoeld is om te worden gebruikt. Of ze hebben een sessie die hun organisatieaccount gebruikt, hoewel ze een persoonlijk gastaccount willen gebruiken (of omgekeerd).

Om ervoor te zorgen dat dit scenario het probleem is, zoekt u naar de User account en Identity provider waarden in het foutbericht. Komen deze waarden overeen met de verwachte combinatie of niet? Heeft een gebruiker zich bijvoorbeeld aangemeld met zijn of haar organisatieaccount bij uw tenant in plaats van de eigen tenant? Of heeft een gebruiker zich aangemeld bij de live.com id-provider met een ander persoonlijk account dan het account dat al is uitgenodigd?

Oplossing: Afmelden en vervolgens opnieuw aanmelden vanuit een andere browser of een privébrowsersessie

Instrueer de gebruiker om een nieuwe privébrowsersessie te openen of laat de gebruiker proberen toegang te krijgen vanuit een andere browser. In dit geval moeten gebruikers zich afmelden bij hun actieve sessie en vervolgens opnieuw proberen aan te melden.

Oorzaak 5: Gastgebruiker is niet uitgenodigd

De gastgebruiker die zich probeerde aan te melden, was niet uitgenodigd voor de tenant.

Oplossing: De gastgebruiker uitnodigen

Zorg ervoor dat u de stappen in quickstart volgt: Voeg gastgebruikers toe aan uw directory in Azure Portal om de gastgebruiker uit te nodigen.

Oorzaak 6: Voor de app is gebruikerstoewijzing vereist

Als uw toepassing een bedrijfstoepassing is waarvoor gebruikerstoewijzing is vereist, treedt er een fout AADSTS50020 op als de gebruiker zich niet in de lijst bevindt met toegestane gebruikers die toegang hebben tot de toepassing. Als u wilt controleren of voor uw bedrijfstoepassing gebruikerstoewijzing is vereist:

1. Zoek en selecteer bedrijfstoepassingen in De Azure-portal.

2. Selecteer uw bedrijfstoepassing.

3. Selecteer Eigenschappen in de zijbalk.

4. Controleer of de optie Opdracht vereist is ingesteld op Ja.

Oplossing: Toegang toewijzen aan gebruikers afzonderlijk of als onderdeel van een groep

Gebruik een van de volgende opties om toegang toe te wijzen aan gebruikers:

• Zie Een gebruikersaccount toewijzen aan een bedrijfstoepassing om de gebruikerstoegang afzonderlijk toe te wijzen aan de toepassing.

• Als u gebruikers wilt toewijzen als ze lid zijn van een toegewezen groep of een dynamische groep, raadpleegt u Toegang tot een toepassing beheren.

Oorzaak 7: geprobeerd een wachtwoordgegevensstroom van de resource-eigenaar te gebruiken voor persoonlijke accounts

Als een gebruiker het proces voor aanmeldgegevens van de resource-eigenaar (ROPC) voor persoonlijke accounts probeert te gebruiken, treedt er een fout AADSTS50020 op. Het Microsoft Identity Platform ondersteunt alleen ROPC binnen Microsoft Entra-tenants, niet persoonlijke accounts.

Oplossing: Een eindpunt gebruiken dat specifiek is voor de tenant of organisatie

Gebruik een tenantspecifiek eindpunt (https://login.microsoftonline.com/<TenantIDOrName>) of het eindpunt van de organisatie. Persoonlijke accounts die voor een Microsoft Entra-tenant zijn uitgenodigd, kunnen ROPC niet gebruiken. Zie Microsoft Identity Platform en OAuth 2.0 Resource Owner Password Credentials voor meer informatie.

Oorzaak 8: Een eerder verwijderde gebruikersnaam is opnieuw gemaakt door de beheerder van de thuistenant

Er kan een fout AADSTS50020 optreden als de naam van een gastgebruiker die is verwijderd in een resourcetenant opnieuw wordt gemaakt door de beheerder van de thuistenant. Gebruik een van de volgende opties om te controleren of het gastgebruikersaccount in de resourcetenant niet is gekoppeld aan een gebruikersaccount in de basistenant:

Verificatie: Controleer of de gastgebruiker van de resourcetenant ouder is dan het gebruikersaccount van de thuistenant

Als u de aanmaakdatum van het gastgebruikersaccount wilt controleren, kunt u Microsoft Graph, Microsoft Entra PowerShell of de Microsoft Graph PowerShell SDK gebruiken.

Microsoft Graph

Geef als volgt een aanvraag voor de MS Graph API uit om de aanmaakdatum van de gebruiker te controleren:

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

Controleer vervolgens de aanmaakdatum van de gastgebruiker in de resourcetenant op basis van de aanmaakdatum van het gebruikersaccount in de thuistenant. Het scenario wordt bevestigd als de gastgebruiker is gemaakt voordat het gebruikersaccount van de thuistenant is gemaakt.

Microsoft Entra PowerShell

Voer de PowerShell-cmdlet Get-EntraUser uit om de aanmaakdatum van de gebruiker als volgt te controleren:

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

Controleer vervolgens de aanmaakdatum van de gastgebruiker in de resourcetenant op basis van de aanmaakdatum van het gebruikersaccount in de thuistenant. Het scenario wordt bevestigd als de gastgebruiker is gemaakt voordat het gebruikersaccount van de thuistenant is gemaakt.

Microsoft Graph PowerShell SDK

Voer de PowerShell-cmdlet Get-MgUser uit om de aanmaakdatum van de gebruiker als volgt te controleren:

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

Controleer vervolgens de aanmaakdatum van de gastgebruiker in de resourcetenant op basis van de aanmaakdatum van het gebruikersaccount in de thuistenant. Het scenario wordt bevestigd als de gastgebruiker is gemaakt voordat het gebruikersaccount van de thuistenant is gemaakt.

Oplossing: Stel de inwisselstatus van het gastgebruikersaccount opnieuw in

Stel de status van de gastgebruikersaccount in de resourcetenant terug naar de oorspronkelijke staat. Vervolgens kunt u het gastgebruikersobject behouden zonder dat u het gastaccount hoeft te verwijderen en vervolgens opnieuw hoeft te maken. U kunt de inwisselingsstatus opnieuw instellen met behulp van Azure Portal, Azure PowerShell of de Microsoft Graph API. Voor instructies, zie De inwisselingsstatus voor een gastgebruiker opnieuw instellen.

Contacteer ons voor hulp

Als u vragen hebt of hulp nodig hebt, maak een ondersteuningsaanvraag of vraag de Azure-communityondersteuning. U kunt ook productfeedback verzenden naar de Azure-feedbackcommunity.