Dela via

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

  • Artikel

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 klientorganisation

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

  1. Bläddra till https://azure.microsoft.com/en-us/free/och välj sedan Starta 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 den här klientorganisationen.

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 identitetsprovidrar 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:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

    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 endast köras på din klientorganisation. 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

Använd det här URL-värdet i inställningen i Authority programkoden. 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 User account efter värdena 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 bjöds inte in till klientorganisationen.

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 Portal 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 ropc-flödet (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 klientorganisationen eller organisationen

Använd en klientspecifik slutpunkt (https://login.microsoftonline.com/<TenantIDOrName>) eller organisationens slutpunkt. Personliga konton som bjuds in till en Microsoft Entra-klientorganisation 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:

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

Det första verifieringsalternativet handlar om att jämföra resursklientens gästanvändares ålder med hemklientens användarkonto. Du kan göra den här verifieringen med hjälp av Microsoft Graph eller MSOnline PowerShell.

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ändaren skapades innan hemklientorganisationens användarkonto skapades.

MSOnline PowerShell

Kommentar

MSOnline PowerShell-modulen är inställd på att vara inaktuell. Eftersom det också är inkompatibelt med PowerShell Core kontrollerar du att du använder en kompatibel PowerShell-version så att du kan köra följande kommandon.

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

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

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

Kommentar

Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.

Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.

Verifieringsalternativ 2: Kontrollera om resursklientens alternativa säkerhets-ID för gäst skiljer sig från hemklientorganisationens användarnät-ID

Kommentar

MSOnline PowerShell-modulen är inställd på att vara inaktuell. Eftersom det också är inkompatibelt med PowerShell Core kontrollerar du att du använder en kompatibel PowerShell-version så att du kan köra följande kommandon.

När en gästanvändare accepterar en inbjudan lagras användarens attribut (användarens unika inloggnings-ID LiveID ) i AlternativeSecurityIds key attributet. Eftersom användarkontot har tagits bort och skapats i hemklientorganisationen NetID har värdet för kontot ändrats för användaren i hemklientorganisationen. NetID Jämför värdet för användarkontot i hemklientorganisationen med nyckelvärdet som lagras i AlternativeSecurityIds gästkontot i resursklientorganisationen enligt följande:

  1. I hemklientorganisationen hämtar du värdet för LiveID attributet med hjälp av PowerShell-cmdleten Get-MsolUser :

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

  2. I resursklientorganisationen konverterar du värdet för key attributet inom AlternativeSecurityIds till en base64-kodad sträng:

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

  3. Konvertera den base64-kodade strängen till ett hexadecimalt värde med hjälp av en onlinekonverterare (till exempel base64.guru).

  4. Jämför värdena från steg 1 och steg 3 för att kontrollera att de är olika. Användarkontot NetID i hemklientorganisationen ändrades när kontot togs bort och återskapades.

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.