Błąd AADSTS50020 — konto użytkownika od dostawcy tożsamości nie istnieje u dzierżawcy

2025-06-26

Ten artykuł ułatwia rozwiązywanie problemów z kodem błędu AADSTS50020, który jest zwracany, jeśli użytkownik-gość z dostawcy tożsamości (IdP) nie może zalogować się do dzierżawy zasobu w usłudze Microsoft Entra ID.

Objawy

Gdy użytkownik-gość próbuje uzyskać dostęp do aplikacji lub zasobu w dzierżawie zasobów, logowanie kończy się niepowodzeniem i zostanie wyświetlony następujący komunikat o błędzie:

AADSTS50020: konto użytkownika "user@domain.com" u dostawcy tożsamości {IdentityProviderURL} nie istnieje w dzierżawie {ResourceTenantName}.

Gdy administrator przegląda logi logowania w głównym dzierżawcy, wpis kodu błędu "90072" wskazuje błąd logowania. Komunikat o błędzie wskazuje:

Konto użytkownika {email} od dostawcy tożsamości {idp} nie istnieje w tenancie {tenant} i nie może uzyskać dostępu do aplikacji {appId}({appName}) w tym tenancie. Konto należy najpierw dodać jako użytkownik zewnętrzny w dzierżawie. Wyloguj się i zaloguj ponownie przy użyciu innego konta użytkownika Microsoft Entra.

Przyczyna 1: Użytkownicy logują się do centrum administracyjnego firmy Microsoft w usłudze Entra przy użyciu osobistych kont Microsoft

Podczas próby zalogowania się do centrum administracyjnego Microsoft Entra przy użyciu osobistych kont Microsoft (Outlook, Hotmail lub OneDrive) użytkownik jest domyślnie połączony z dzierżawą usług Microsoft. W ramach dzierżawy domyślnej nie ma połączonego katalogu do wykonywania żadnych czynności. To zachowanie jest oczekiwane.

W poprzednim środowisku katalog (na przykład: UserNamehotmail735.onmicrosoft.com) jest tworzony i połączony z kontem osobistym, a także można wykonywać akcje, takie jak tworzenie kont użytkowników w katalogu. Zachowanie zostało teraz zmienione.

Rozwiązanie: Założyć konto Azure z nowym dzierżawcą

Jeśli chcesz mieć katalog, musisz utworzyć konto Azure i nowego dzierżawcę.

Przejdź do https://azure.microsoft.com/en-us/free/strony , a następnie wybierz pozycję Rozpocznij bezpłatnie .
Postępuj zgodnie z instrukcjami, aby utworzyć konto platformy Azure.
Instancja zostanie wygenerowana wraz z Twoim kontem Microsoft Azure, a Ty zostaniesz automatycznie wyznaczony jako globalny administrator. Daje to pełny dostęp do wszystkich opcji w tej dzierżawie.

Przyczyna 2: Używany nieobsługiwany typ konta (wielodostępowe i osobiste konta)

Jeśli rejestracja aplikacji jest ustawiona na typ konta dla pojedynczego najemcy, użytkownicy z innych katalogów lub dostawców tożsamości nie mogą zalogować się do tej aplikacji.

Aby upewnić się, że rejestracja aplikacji nie jest pojedynczym typem konta dzierżawy, wykonaj następujące kroki:

W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.
Wybierz nazwę rejestracji aplikacji.
Na pasku bocznym wybierz pozycję Manifest.
W kodzie JSON znajdź ustawienie signInAudience.
Sprawdź, czy ustawienie zawiera jedną z następujących wartości:
- Azure AD oraz Osobiste Konto Microsoft
- AzureADMultipleOrgs
- Osobiste konto Microsoft
Jeśli ustawienie signInAudience nie zawiera jednej z tych wartości, utwórz ponownie rejestrację aplikacji, wybierając prawidłowy typ konta. Obecnie nie można zmienić signInAudience w manifeście.

Aby uzyskać więcej informacji na temat rejestrowania aplikacji, zobacz Szybki start: rejestrowanie aplikacji przy użyciu Platforma tożsamości Microsoft.

Przyczyna 3: Użyto niewłaściwego punktu końcowego (dla kont osobistych i kont organizacyjnych)

Wywołanie uwierzytelniania musi być skierowane na adres URL zgodny z wyborem, jeśli obsługiwany typ konta rejestracji aplikacji został ustawiony na jedną z następujących wartości:

Konta w dowolnym katalogu organizacyjnym (dowolny katalog Microsoft Entra — wielodostępny)
Konta w dowolnym katalogu organizacyjnym (dowolny katalog Microsoft Entra — multitenant) i osobiste konta Microsoft (np. Skype, Xbox)
Tylko osobiste konta Microsoft

Jeśli używasz usługi https://login.microsoftonline.com/<YourTenantNameOrID>, użytkownicy z innych organizacji nie będą mogli uzyskać dostępu do aplikacji. Musisz dodać tych użytkowników jako gości w dzierżawie określonej w żądaniu. W takim przypadku uwierzytelnianie powinno zostać uruchomione tylko w dzierżawie. Ten scenariusz powoduje błąd podczas logowania, jeśli oczekujesz, że użytkownicy będą logować się za pomocą federacji z innym klientem lub dostawcą tożsamości.

Użyj odpowiedniego adresu URL logowania dla określonego typu aplikacji, jak pokazano w poniższej tabeli:

Typ aplikacji	Adres URL logowania
Aplikacje wielozadaniowe	`https://login.microsoftonline.com/organizations`
Konta obsługujące wielu najemców i osobiste konta	`https://login.microsoftonline.com/common`
Tylko konta osobiste	`https://login.microsoftonline.com/consumers`

W kodzie aplikacji zastosuj tę wartość adresu URL w ustawieniu Authority . Aby uzyskać więcej informacji na temat Authority, zobacz opcje konfiguracji aplikacji platformy tożsamości Microsoft.

Przyczyna 4: Zalogowanie się do niewłaściwego konta/organizacji

Gdy użytkownicy próbują uzyskać dostęp do aplikacji, są oni kierowani bezpośrednio do aplikacji lub próbują uzyskać dostęp przy użyciu https://myapps.microsoft.com. W obu sytuacjach użytkownicy są przekierowywani do logowania się do aplikacji. W niektórych przypadkach użytkownik może mieć już aktywną sesję, która używa innego konta osobistego niż konto, które ma być używane. Albo mają sesję, która używa konta organizacyjnego, chociaż zamierzały używać osobistego konta gościa (lub odwrotnie).

Aby upewnić się, że ten scenariusz jest problemem, poszukaj wartości User account i Identity provider w komunikacie o błędzie. Czy te wartości są zgodne z oczekiwaną kombinacją, czy nie? Czy na przykład użytkownik zalogował się przy użyciu konta swojej organizacji do Twojego najemcy zamiast swojej dzierżawy macierzystej? Czy też użytkownik zalogował się do live.com dostawcy tożsamości przy użyciu innego konta osobistego niż to, które zostało już zaproszone?

Poinstruuj użytkownika, aby otworzył nową sesję przeglądarki w trybie prywatnym lub poproś użytkownika o próbę uzyskania dostępu z innej przeglądarki. W takim przypadku użytkownicy muszą wylogować się z aktywnej sesji, a następnie spróbować zalogować się ponownie.

Przyczyna 5. Użytkownik-gość nie został zaproszony

Gość, który próbował się zalogować, nie został zaproszony do najemcy.

Rozwiązanie: Zapraszanie użytkownika-gościa

Upewnij się, że wykonasz kroki opisane w przewodniku Szybki start: Dodawanie użytkowników-gości do katalogu w witrynie Azure Portal w celu zaproszenia użytkownika-gościa.

Przyczyna 6. Aplikacja wymaga przypisania użytkownika

Jeśli aplikacja jest aplikacją dla przedsiębiorstw, która wymaga przypisania użytkownika, błąd AADSTS50020 występuje, jeśli użytkownik nie znajduje się na liście dozwolonych użytkowników, którym przypisano dostęp do aplikacji. Aby sprawdzić, czy aplikacja dla przedsiębiorstw wymaga przypisania użytkownika:

W witrynie Azure Portal wyszukaj i wybierz pozycję Aplikacje dla przedsiębiorstw.
Wybierz aplikację dla przedsiębiorstw.
Na pasku bocznym wybierz pozycję Właściwości.
Sprawdź, czy opcja Wymagane przypisanie jest ustawiona na Tak.

Rozwiązanie: Przypisywanie dostępu do użytkowników indywidualnie lub w ramach grupy

Użyj jednej z następujących opcji, aby przypisać dostęp do użytkowników:

Aby indywidualnie przypisać użytkownikowi dostęp do aplikacji, zobacz Przypisywanie konta użytkownika do aplikacji dla przedsiębiorstw.
Aby przypisać użytkowników, jeśli są członkami przypisanej grupy lub grupy dynamicznej, zobacz Zarządzanie dostępem do aplikacji.

Przyczyna 7: Próbowano użyć przepływu autoryzacji przy użyciu hasła właściciela zasobu dla kont osobistych

Jeśli użytkownik próbuje skorzystać z procesu użycia poświadczeń hasła właściciela zasobu (ROPC) dla kont osobistych, wystąpi błąd AADSTS50020 . Platforma tożsamości Microsoft obsługuje ROPC tylko w ramach dzierżaw Microsoft Entra, a nie kont osobistych.

Rozwiązanie: użyj punktu końcowego, który jest specyficzny dla najemcy lub organizacji

Użyj punktu końcowego specyficznego dla najemcy (https://login.microsoftonline.com/<TenantIDOrName>) lub punktu końcowego organizacji. Konta osobiste, które są zapraszane do dzierżawy usługi Microsoft Entra, nie mogą używać rozwiązania ROPC. Aby uzyskać więcej informacji, zobacz Platforma tożsamości Microsoft i poświadczenia hasła właściciela zasobów OAuth 2.0.

Przyczyna 8. Wcześniej usunięta nazwa użytkownika została ponownie utworzona przez administratora dzierżawy głównej

Błąd AADSTS50020 może wystąpić, jeśli nazwa użytkownika-gościa, który został usunięty w dzierżawie zasobów, zostanie ponownie utworzona przez administratora dzierżawy macierzystej. Aby sprawdzić, czy konto użytkownika-gościa w dzierżawie zasobów nie jest skojarzone z kontem użytkownika w dzierżawie głównej, użyj jednej z następujących opcji:

Weryfikacja: Sprawdź, czy użytkownik-gość dzierżawy zasobów jest starszy niż użytkownik dzierżawy macierzystej

Aby sprawdzić datę utworzenia konta użytkownika-gościa, możesz użyć programu Microsoft Graph, programu Microsoft Entra PowerShell lub zestawu MICROSOFT Graph PowerShell SDK.

Microsoft Graph

Prześlij żądanie do interfejsu API programu MS Graph, aby przejrzeć datę utworzenia użytkownika w następujący sposób:

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

Następnie porównaj datę utworzenia użytkownika-gościa w dzierżawie zasobów z datą utworzenia konta użytkownika w dzierżawie głównej. Scenariusz jest potwierdzony, jeśli użytkownik-gość został utworzony przed utworzeniem konta użytkownika głównego najemcy.

Microsoft Entra PowerShell

Uruchom polecenie cmdlet Get-EntraUser programu PowerShell, aby przejrzeć datę utworzenia użytkownika w następujący sposób:

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

Zestaw SDK programu PowerShell dla Microsoft Graph

Uruchom polecenie cmdlet Get-MgUser programu PowerShell, aby przejrzeć datę utworzenia użytkownika w następujący sposób:

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

Rozwiązanie: Resetowanie stanu odkupienia konta użytkownika-gościa

Zresetuj stan realizacji konta użytkownika-gościa w dzierżawie zasobów. Następnie można zachować obiekt użytkownika-gościa bez konieczności usuwania, a następnie ponownie utworzyć konto gościa. Stan realizacji można zresetować przy użyciu witryny Azure Portal, programu Azure PowerShell lub interfejsu API programu Microsoft Graph. Aby uzyskać instrukcje, zobacz Resetowanie stanu realizacji dla użytkownika-gościa.

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.