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

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

Symptomy

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" od dostawcy tożsamości {IdentityProviderURL} nie istnieje w dzierżawie {ResourceTenantName}.

Gdy administrator przegląda dzienniki logowania w dzierżawie głównej, 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 dzierżawie {tenant} i nie może uzyskać dostępu do aplikacji {appId}({appName}) w tej dzierżawie. 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 przy użyciu osobistych kont Microsoft

Podczas próby zalogowania się do centrum administracyjnego firmy Microsoft Entra przy użyciu osobistych kont Microsoft (Outlook, Hotmail lub OneDrive) użytkownik jest domyślnie połączony z dzierżawą usług firmy Microsoft. W ramach dzierżawy domyślnej nie ma połączonego katalogu do wykonywania żadnych akcji. 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: tworzenie konta platformy Azure przy użyciu nowej dzierżawy

Jeśli chcesz mieć katalog, musisz utworzyć konto platformy Azure i nową dzierżawę:

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

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

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

Rozwiązanie: zmiana ustawienia odbiorców logowania w manifeście rejestracji aplikacji

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

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Rejestracje aplikacji.

2. Wybierz nazwę rejestracji aplikacji.

3. Na pasku bocznym wybierz pozycję Manifest.

4. W kodzie JSON znajdź ustawienie signInAudience .

5. Sprawdź, czy ustawienie zawiera jedną z następujących wartości:

   • AzureADandPersonalMicrosoftAccount
   • AzureADMultipleOrgs
   • PersonalMicrosoftAccount

   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ć znakuInAudience 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 nieprawidłowego punktu końcowego (kont osobistych i organizacji)

Wywołanie uwierzytelniania musi być adresem URL zgodnym 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 logowania, jeśli oczekujesz, że użytkownicy będą logować się przy użyciu federacji z inną dzierżawą lub dostawcą tożsamości.

Rozwiązanie: Użyj poprawnego adresu URL logowania

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

Typ aplikacji	Adres URL logowania
Aplikacje wielodostępne	https://login.microsoftonline.com/organizations
Wielodostępne 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 Authorityprogramu , zobacz Platforma tożsamości Microsoft opcje konfiguracji aplikacji.

Przyczyna 4. Zalogowanie się do niewłaściwej dzierżawy

Gdy użytkownicy próbują uzyskać dostęp do aplikacji, są one wysyłane bezpośrednio do aplikacji lub próbują uzyskać dostęp za pośrednictwem usługi 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. Lub mają sesję, która używa konta organizacji, chociaż zamierza używać osobistego konta gościa (lub na odwrót).

Aby upewnić się, że ten scenariusz jest problemem, poszukaj User account wartości 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 organizacji w dzierżawie zamiast 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?

Rozwiązanie: wyloguj się, a następnie zaloguj się ponownie z innej przeglądarki lub prywatnej sesji przeglądarki

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

Użytkownik-gość, który próbował się zalogować, nie został zaproszony do dzierżawy.

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:

1. W witrynie Azure Portal wyszukaj i wybierz pozycję Aplikacje dla przedsiębiorstw.

2. Wybierz aplikację dla przedsiębiorstw.

3. Na pasku bocznym wybierz pozycję Właściwości.

4. Sprawdź, czy opcja Wymagane przypisanie ma wartość 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 poświadczeń hasła właściciela zasobu dla kont osobistych

Jeśli użytkownik próbuje użyć przepływu 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 firmy Microsoft, a nie kont osobistych.

Rozwiązanie: użyj punktu końcowego specyficznego dla dzierżawy lub organizacji

Użyj punktu końcowego specyficznego dla dzierżawy (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 zasobu 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:

Opcja weryfikacji 1: Sprawdź, czy użytkownik-gość dzierżawy zasobów jest starszy niż konto użytkownika dzierżawy głównej

Pierwsza opcja weryfikacji obejmuje porównanie wieku użytkownika-gościa dzierżawy zasobów z kontem użytkownika użytkownika dzierżawy głównej. Tę weryfikację można przeprowadzić przy użyciu programu Microsoft Graph lub programu MSOnline PowerShell.

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 sprawdź datę utworzenia użytkownika-gościa w dzierżawie zasobów pod kątem daty utworzenia konta użytkownika w dzierżawie głównej. Scenariusz jest potwierdzany, czy użytkownik-gość został utworzony przed utworzeniem konta użytkownika dzierżawy głównej.

MSOnline PowerShell

Uwaga 16.

Moduł MSOnline programu PowerShell jest ustawiony na przestarzały. Ponieważ jest on również niezgodny z programem PowerShell Core, upewnij się, że używasz zgodnej wersji programu PowerShell, aby można było uruchomić następujące polecenia.

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

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

Następnie sprawdź datę utworzenia użytkownika-gościa w dzierżawie zasobów pod kątem daty utworzenia konta użytkownika w dzierżawie głównej. Scenariusz jest potwierdzany, czy użytkownik-gość został utworzony przed utworzeniem konta użytkownika dzierżawy głównej.

Uwaga 16.

Moduły usług Azure AD i MSOnline programu PowerShell są przestarzałe od 30 marca 2024 r. Aby dowiedzieć się więcej, przeczytaj aktualizację o wycofaniu. Po tej dacie obsługa tych modułów jest ograniczona do pomocy dotyczącej migracji do zestawu MICROSOFT Graph PowerShell SDK i poprawek zabezpieczeń. Przestarzałe moduły będą nadal działać do 30 marca 2025 r.

Zalecamy migrację do programu Microsoft Graph PowerShell w celu interakcji z identyfikatorem Entra firmy Microsoft (dawniej Azure AD). W przypadku typowych pytań dotyczących migracji zapoznaj się z często zadawanymi pytaniami dotyczącymi migracji. Uwaga: wersje 1.0.x usługi MSOnline mogą wystąpić zakłócenia po 30 czerwca 2024 r.

Opcja weryfikacji 2: Sprawdź, czy alternatywny identyfikator zabezpieczeń gościa dzierżawy zasobu różni się od identyfikatora sieci użytkownika dzierżawy głównej

Uwaga 16.

Moduł MSOnline programu PowerShell jest ustawiony na przestarzały. Ponieważ jest on również niezgodny z programem PowerShell Core, upewnij się, że używasz zgodnej wersji programu PowerShell, aby można było uruchomić następujące polecenia.

Gdy użytkownik-gość akceptuje zaproszenie, atrybut użytkownika LiveID (unikatowy identyfikator logowania użytkownika) jest przechowywany w AlternativeSecurityIds atrybucie key . Ponieważ konto użytkownika zostało usunięte i utworzone w dzierżawie głównej, NetID wartość konta zostanie zmieniona dla użytkownika w dzierżawie głównej. NetID Porównaj wartość konta użytkownika w dzierżawie głównej z wartością klucza przechowywaną w AlternativeSecurityIds ramach konta gościa w dzierżawie zasobów w następujący sposób:

1. W dzierżawie głównej pobierz wartość atrybutu LiveID przy użyciu Get-MsolUser polecenia cmdlet programu PowerShell:

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

2. W dzierżawie zasobów przekonwertuj wartość atrybutu key w pliku AlternativeSecurityIds na ciąg zakodowany w formacie base64:

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

3. Przekonwertuj ciąg zakodowany w formacie base64 na wartość szesnastkową przy użyciu konwertera online (takiego jak base64.guru).

4. Porównaj wartości z kroku 1 i kroku 3, aby sprawdzić, czy są różne. Konto NetID użytkownika w dzierżawie głównej zmieniło się po usunięciu i ponownym utworzeniu konta.

Rozwiązanie: Resetowanie stanu realizacji 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.