Delen via

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

  • Artikel

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 map wilt hebben, moet u een Azure-account en een nieuwe tenant maken:

  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-portal App-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:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    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 organisatiedirectory (Elke Microsoft Entra-directory - Multitenant) 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 de gebruiker toegang te geven 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, is 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 vereiste optie Toewijzing 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:

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

Als een gebruiker de stroom wachtwoordreferenties 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:

Verificatieoptie 1: Controleren of de gastgebruiker van de resourcetenant ouder is dan het gebruikersaccount van de thuistenant

De eerste verificatieoptie omvat het vergelijken van de leeftijd van de gastgebruiker van de resourcetenant met het gebruikersaccount van de thuistenant. U kunt deze verificatie uitvoeren met Behulp van Microsoft Graph of MSOnline PowerShell.

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.

MSOnline PowerShell

Notitie

De MSOnline PowerShell-module is ingesteld op afgeschaft. Omdat het ook niet compatibel is met PowerShell Core, moet u ervoor zorgen dat u een compatibele PowerShell-versie gebruikt, zodat u de volgende opdrachten kunt uitvoeren.

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

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

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.

Notitie

Azure AD- en MSOnline PowerShell-modules zijn vanaf 30 maart 2024 afgeschaft. Lees de afschaffingsupdate voor meer informatie. Na deze datum is ondersteuning voor deze modules beperkt tot migratieondersteuning voor Microsoft Graph PowerShell SDK en beveiligingsoplossingen. De afgeschafte modules blijven functioneren tot en met 30 maart 2025.

Het is raadzaam om te migreren naar Microsoft Graph PowerShell om te communiceren met Microsoft Entra ID (voorheen Azure AD). Raadpleeg de veelgestelde vragen over migratie voor veelgestelde vragen over migratie. Opmerking: versies 1.0.x van MSOnline kunnen na 30 juni 2024 onderbrekingen ondervinden.

Verificatieoptie 2: Controleer of de alternatieve beveiligings-id van de resourcetenant verschilt van de gebruikersnet-id van de thuistenant

Notitie

De MSOnline PowerShell-module is ingesteld op afgeschaft. Omdat het ook niet compatibel is met PowerShell Core, moet u ervoor zorgen dat u een compatibele PowerShell-versie gebruikt, zodat u de volgende opdrachten kunt uitvoeren.

Wanneer een gastgebruiker een uitnodiging accepteert, wordt het kenmerk van de gebruiker LiveID (de unieke aanmeldings-id van de gebruiker) opgeslagen AlternativeSecurityIds in het key kenmerk. Omdat het gebruikersaccount is verwijderd en gemaakt in de thuistenant, is de NetID waarde voor het account gewijzigd voor de gebruiker in de thuistenant. Vergelijk de NetID waarde van het gebruikersaccount in de thuistenant met de sleutelwaarde die is opgeslagen in AlternativeSecurityIds het gastaccount in de resourcetenant, als volgt:

  1. Haal in de thuistenant de waarde van het LiveID kenmerk op met behulp van de Get-MsolUser PowerShell-cmdlet:

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

  2. Converteer in de resourcetenant de waarde van het key kenmerk in AlternativeSecurityIds een met base64 gecodeerde tekenreeks:

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

  3. Converteer de met base64 gecodeerde tekenreeks naar een hexadecimale waarde met behulp van een online converter (zoals base64.guru).

  4. Vergelijk de waarden uit stap 1 en stap 3 om te controleren of ze verschillen. Het NetID gebruikersaccount in de thuistenant is gewijzigd toen het account werd verwijderd en opnieuw werd gemaakt.

Oplossing: de inwisselingsstatus van het gastgebruikersaccount opnieuw instellen

Stel de inwisselingsstatus van het gastgebruikersaccount in de resourcetenant opnieuw in. 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. Zie De inwisselingsstatus voor een gastgebruiker opnieuw instellen voor instructies.

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.