Dela via

Fel AADSTS50020 – Användarkontot från identitetsprovidern finns inte i klientorganisationen

Den här artikeln hjälper dig att felsöka felkod AADSTS50020 som returneras om en gästanvändare från en identitetsprovider (IdP) inte kan logga in på en resursklient i Microsoft Entra-ID.

Symptom

När en gästanvändare försöker komma åt ett program eller en resurs i resursklientorganisationen misslyckas inloggningen och följande felmeddelande visas:

AADSTS50020: Användarkontotuser@domain.com från identitetsprovidern {IdentityProviderURL} finns inte i klientorganisationen {ResourceTenantName}.

När en administratör granskar inloggningsloggarna på hemklientorganisationen anger en felkodspost "90072" ett inloggningsfel. Felmeddelandet anger:

Användarkontot {email} från identitetsprovidern {idp} finns inte i klientorganisationen {tenant} och kan inte komma åt programmet {appId}({appName}) i klientorganisationen. Kontot måste läggas till som en extern användare i klientorganisationen först. Logga ut och logga in igen med ett annat Microsoft Entra-användarkonto.

Orsak 1:Användare loggar in på administrationscentret för Microsoft Entra med hjälp av personliga Microsoft-konton

När du försöker logga in på administrationscentret för Microsoft Entra med dina personliga Microsoft-konton (Outlook, Hotmail eller OneDrive) är du ansluten till Microsoft Services-klientorganisationen som standard. I standardklientorganisationen finns det ingen länkad katalog för att utföra några åtgärder. Detta är ett förväntat beteende.

I tidigare erfarenhet skapas en katalog (till exempel UserNamehotmail735.onmicrosoft.com) och länkas till det personliga kontot, och du kan utföra åtgärder som att skapa användarkonton i katalogen. Beteendet har nu ändrats.

Lösning: Skapa ett Azure-konto med en ny tenant

Om du vill ha en katalog måste du skapa ett Azure-konto och en ny klientorganisation:

  1. Bläddra till Webbplatsen för Azure-kontot och välj sedan Prova Azure kostnadsfritt.
  2. Följ anvisningarna för att skapa ett Azure-konto.
  3. En klientorganisation genereras tillsammans med Azure-kontot och du kommer automatiskt att utses till global administratör. Detta ger dig fullständig åtkomst till alla alternativ i denna kundmiljö.

Orsak 2: Använd kontotyp som inte stöds (konton med flera klientorganisationer och personliga konton)

Om din appregistrering är inställd på en kontotyp för en enda klientorganisation kan användare från andra kataloger eller identitetsleverantörer inte logga in på programmet.

Lösning: Ändra inställningen för inloggningspublik i appregistreringsmanifestet

Utför följande steg för att se till att appregistreringen inte är en kontotyp för en enda klientorganisation:

  1. I Azure Portal söker du efter och väljer Appregistreringar.

  2. Välj namnet på din appregistrering.

  3. I sidofältet väljer du Manifest.

  4. Leta reda på inställningen signInAudience i JSON-koden.

  5. Kontrollera om inställningen innehåller något av följande värden:

    • AzureAD-och-personligt-Microsoft-konto
    • AzureADMultipleOrgs
    • PersonligtMicrosoftKonto

    Om inställningen signInAudience inte innehåller något av dessa värden skapar du appregistreringen igen genom att välja rätt kontotyp. Du kan för närvarande inte ändra signInAudience i manifestet.

Mer information om hur du registrerar program finns i Snabbstart: Registrera ett program med Microsofts identitetsplattform.

Orsak 3: Använde fel slutpunkt (personliga konton och organisationskonton)

Ditt autentiseringsanrop måste rikta in sig på en URL som matchar ditt val om appregistreringens kontotyp som stöds har angetts till något av följande värden:

  • Konton i valfri organisationskatalog (Alla Microsoft Entra-kataloger – Multitenant)

  • Konton i valfri organisationskatalog (Alla Microsoft Entra-kataloger – Multitenant) och personliga Microsoft-konton (t.ex. Skype, Xbox)

  • Endast personliga Microsoft-konton

Om du använder https://login.microsoftonline.com/<YourTenantNameOrID>kan användare från andra organisationer inte komma åt programmet. Du måste lägga till dessa användare som gäster i klientorganisationen som anges i begäran. I så fall förväntas autentiseringen köras endast på din hyresvärd. Det här scenariot orsakar inloggningsfelet om du förväntar dig att användarna loggar in med hjälp av federation med en annan klientorganisation eller identitetsprovider.

Lösning: Använd rätt inloggnings-URL

Använd motsvarande inloggnings-URL för den specifika programtypen enligt listan i följande tabell:

Apptyp Inloggnings-URL
Program för flera klienter https://login.microsoftonline.com/organizations
Konton för flera klientorganisationer och personliga konton https://login.microsoftonline.com/common
Endast personliga konton https://login.microsoftonline.com/consumers

I din programkod, använd det här URL-värdet i inställningen Authority. Mer information om Authorityfinns i Microsofts identitetsplattform programkonfigurationsalternativ.

Orsak 4: Inloggad på fel klientorganisation

När användarna försöker komma åt ditt program skickas antingen en direktlänk till programmet eller så försöker de få åtkomst via https://myapps.microsoft.com. I båda fallen omdirigeras användarna för att logga in på programmet. I vissa fall kanske användaren redan har en aktiv session som använder ett annat personligt konto än det som är avsett att användas. Eller så har de en session som använder sitt organisationskonto även om de avsåg att använda ett personligt gästkonto (eller vice versa).

Kontrollera att det här scenariot är problemet genom att leta efter värdena User account och Identity provider i felmeddelandet. Matchar dessa värden den förväntade kombinationen eller inte? Loggade en användare till exempel in med sitt organisationskonto till din klientorganisation i stället för sin hemklient? Eller loggade en användare in på identitetsprovidern live.com med ett annat personligt konto än det som redan har bjudits in?

Lösning: Logga ut och logga sedan in igen från en annan webbläsare eller en privat webbläsarsession

Instruera användaren att öppna en ny privat webbläsarsession eller låta användaren försöka komma åt från en annan webbläsare. I det här fallet måste användarna logga ut från sin aktiva session och sedan försöka logga in igen.

Orsak 5: Gästanvändaren har inte bjudits in

Gästanvändaren som försökte logga in var inte inbjuden till hyresgästen.

Lösning: Bjud in gästanvändaren

Se till att du följer stegen i Snabbstart: Lägg till gästanvändare i din katalog i Azure Portal för att bjuda in gästanvändaren.

Orsak 6: Appen kräver användartilldelning

Om ditt program är ett företagsprogram som kräver användartilldelning uppstår ett fel AADSTS50020 om användaren inte finns med i listan över tillåtna användare som har tilldelats åtkomst till programmet. Så här kontrollerar du om ditt företagsprogram kräver användartilldelning:

  1. I Azure-portalen söker du efter och väljer Företagsprogram.

  2. Välj ditt företagsprogram.

  3. I sidofältet väljer du Egenskaper.

  4. Kontrollera om alternativet Tilldelning krävs är inställt på Ja.

Lösning: Tilldela åtkomst till användare individuellt eller som en del av en grupp

Använd något av följande alternativ för att tilldela åtkomst till användare:

Orsak 7: Försökte använda ett flöde för lösenordsautentiseringsuppgifter för resursägare för personliga konton

Om en användare försöker använda flödet ROPC (Resource Owner Password Credentials) för personliga konton, uppstår ett fel AADSTS50020. Microsofts identitetsplattform stöder endast ROPC i Microsoft Entra-klientorganisationer, inte personliga konton.

Lösning: Använd en slutpunkt som är specifik för hyresgästen eller organisationen

Använd en klientspecifik slutpunkt (https://login.microsoftonline.com/<TenantIDOrName>) eller organisationens slutpunkt. Personliga konton som bjuds in till en Microsoft Entra-klient kan inte använda ROPC. Mer information finns i Microsofts identitetsplattform och autentiseringsuppgifter för OAuth 2.0-resursägares lösenord.

Orsak 8: Ett tidigare borttaget användarnamn skapades på nytt av hemklientadministratören

Ett fel AADSTS50020 kan inträffa om namnet på en gästanvändare som har tagits bort i en resursklient skapas på nytt av administratören för hemklientorganisationen. Om du vill kontrollera att gästanvändarkontot i resursklientorganisationen inte är associerat med ett användarkonto i hemklientorganisationen använder du något av följande alternativ:

Verifiering: Kontrollera om resursklientens gästanvändare är äldre än hemklientens användarkonto

Om du vill kontrollera skapandedatumet för gästanvändarkontot kan du använda Microsoft Graph, Microsoft Entra PowerShell eller Microsoft Graph PowerShell SDK.

Microsoft Graph

Utfärda en begäran till MS Graph-API:et för att granska användargenereringsdatumet på följande sätt:

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

Kontrollera sedan skapandedatumet för gästanvändaren i resursklientorganisationen mot skapandedatumet för användarkontot i hemklientorganisationen. Scenariot bekräftas om gästanvändarens konto skapades innan huvudklientens användarkonto skapades.

Microsoft Entra PowerShell

Kör PowerShell-cmdleten Get-EntraUser för att granska användargenereringsdatumet på följande sätt:

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

Kontrollera sedan skapandedatumet för gästanvändaren i resursklientorganisationen mot skapandedatumet för användarkontot i hemklientorganisationen. Scenariot bekräftas om gästanvändarens konto skapades innan huvudklientens användarkonto skapades.

Microsoft Graph PowerShell SDK

Kör PowerShell-cmdleten Get-MgUser för att granska användargenereringsdatumet på följande sätt:

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

Kontrollera sedan skapandedatumet för gästanvändaren i resursklientorganisationen mot skapandedatumet för användarkontot i hemklientorganisationen. Scenariot bekräftas om gästanvändarens konto skapades innan huvudklientens användarkonto skapades.

Lösning: Återställa inlösenstatusen för gästanvändarkontot

Återställ inlösningsstatusen för gästanvändarkontot i resursklientorganisationen. Sedan kan du behålla gästanvändarobjektet utan att behöva ta bort och sedan återskapa gästkontot. Du kan återställa inlösenstatusen med hjälp av Azure Portal, Azure PowerShell eller Microsoft Graph API. Anvisningar finns i Återställa inlösenstatus för en gästanvändare.

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.