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 toegang probeert 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 thuistenant controleert, geeft een foutcode '90072' een aanmeldingsfout aan. Het foutbericht geeft aan:

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 worden toegevoegd als een externe gebruiker in de tenant. Meld u af en meld u opnieuw aan met een ander Microsoft Entra gebruikersaccount.

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

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

In de vorige ervaring is 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 om een Azure-account te maken.
  3. Er wordt een tenant gegenereerd naast het Azure-account en u wordt automatisch aangewezen als de 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 mappen 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 en selecteer App-registraties in de Azure Portal.

  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 instelling signInAudience niet een 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 met de Microsoft identity platform voor meer informatie over het registreren van toepassingen.

Oorzaak 3: het verkeerde eindpunt gebruikt (persoonlijke en organisatieaccounts)

Uw verificatieoproep moet zijn gericht 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 directory - multitenant)

  • Accounts in elke organisatiemap (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 de verificatie naar verwachting alleen uitgevoerd op uw tenant. Dit scenario veroorzaakt de aanmeldingsfout als u verwacht dat gebruikers zich aanmelden met federatie met een andere tenant of id-provider.

Oplossing: Gebruik de juiste aanmeldings-URL

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

Toepassingstype Aanmeldings-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 Microsoft identity platform toepassing voor meer informatie overAuthority.

Oorzaak 4: aangemeld bij de verkeerde tenant

Wanneer gebruikers toegang proberen te krijgen tot uw toepassing, ontvangen ze een directe koppeling naar de toepassing 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 een ander persoonlijk account gebruikt dan het account dat bedoeld is om te worden gebruikt. Of ze hebben een sessie waarin hun organisatieaccount wordt gebruikt, hoewel ze van plan waren een persoonlijk gastaccount te gebruiken (of omgekeerd).

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

Oplossing: Meld u af en meld u vervolgens opnieuw aan vanuit een andere browser of een privébrowsersessie

Instrueer de gebruiker om een nieuwe in-private browsersessie te openen of laat de gebruiker toegang proberen te krijgen vanuit een andere browser. In dit geval moeten gebruikers zich afmelden bij hun actieve sessie en zich 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 volgt in Quickstart: Gastgebruikers toevoegen aan uw directory in de Azure Portal om de gastgebruiker uit te nodigen.

Oorzaak 6: App vereist gebruikerstoewijzing

Als uw toepassing een bedrijfstoepassing is waarvoor gebruikerstoewijzing is vereist, treedt er een fout AADSTS50020 op als de gebruiker niet voorkomt in de lijst met toegestane gebruikers aan wie toegang tot de toepassing is toegewezen. 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 Toewijzing 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:

Oorzaak 7: geprobeerd een stroom met wachtwoordreferenties van resource-eigenaar te gebruiken voor persoonlijke accounts

Als een gebruiker probeert de ropc-stroom (wachtwoordreferenties voor resource-eigenaar) te gebruiken voor persoonlijke accounts, treedt er een fout AADSTS50020 op. De Microsoft identity platform ondersteunt ROPC alleen binnen Microsoft Entra tenants, niet binnen persoonlijke accounts.

Oplossing: Gebruik een eindpunt 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 zijn uitgenodigd voor een Microsoft Entra tenant, kunnen ropc niet gebruiken. Zie wachtwoordreferenties voor Microsoft identity platform en OAuth 2.0-resource-eigenaar 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 thuistenant:

Verificatieoptie 1: controleer 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

Verzend als volgt een aanvraag naar de MS-Graph API 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

Opmerking

De MSOnline PowerShell-module is ingesteld om te worden afgeschaft. Omdat deze 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 Get-MsolUser PowerShell-cmdlet als volgt uit om de aanmaakdatum van de gebruiker 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.

Opmerking

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

U wordt aangeraden 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 worden onderbroken.

Verificatieoptie 2: controleer of de alternatieve gastbeveiligings-id van de resourcetenant verschilt van de net-id van de gebruiker van de tenant thuis

Opmerking

De MSOnline PowerShell-module is ingesteld om te worden afgeschaft. Omdat deze 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 LiveID de gebruiker (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 home-tenant. Vergelijk de NetID waarde van het gebruikersaccount in de thuistenant als volgt met de sleutelwaarde die is opgeslagen in AlternativeSecurityIds het gastaccount in de resourcetenant:

  1. Haal in de home-tenant 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 binnen AlternativeSecurityIds naar 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. De NetID van het 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 de Azure Portal, Azure PowerShell of de Microsoft-Graph API. Zie 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 Feedback-community van Azure.