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ść z dostawcy tożsamości (IdP) nie może zalogować się do dzierżawy zasobów w Tożsamość Microsoft Entra.

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" oznacza błąd logowania. Komunikat o błędzie zawiera następujące stany:

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. Najpierw konto musi zostać dodane jako użytkownik zewnętrzny w dzierżawie. Wyloguj się i zaloguj się ponownie przy użyciu innego konta użytkownika Microsoft Entra.

Przyczyna 1. Użytkownicy logują się do centrum administracyjne Microsoft Entra przy użyciu osobistych kont Microsoft

Podczas próby zalogowania się w celu centrum administracyjne Microsoft Entra przy użyciu osobistych kont Microsoft (Outlook, Hotmail lub OneDrive) domyślnie masz połączenie z dzierżawą usług firmy Microsoft. W dzierżawie domyślnej nie ma połączonego katalogu do wykonywania jakichkolwiek akcji. Ta sytuacja jest oczekiwana.

W poprzednim środowisku katalog (na przykład: UserNamehotmail735.onmicrosoft.com) jest tworzony i połączony z kontem osobistym i można wykonywać akcje, takie jak tworzenie kont użytkowników w katalogu. Zachowanie zostało 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 pozycji https://azure.microsoft.com/en-us/free/, 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 zostaniesz automatycznie wyznaczony jako administrator globalny. Daje to pełny dostęp do wszystkich opcji w tej dzierżawie.

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

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ą zalogować się do tej aplikacji.

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

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

1. W 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ć 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 (konta osobiste i konta organizacji)

Wywołanie uwierzytelniania musi być przeznaczone dla adresu URL zgodnego 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 — wielodostępny) i osobiste konta Microsoft (np. Skype, Xbox)

• Tylko osobiste konta Microsoft

Jeśli używasz programu https://login.microsoftonline.com/<YourTenantNameOrID>, użytkownicy z innych organizacji nie mogą uzyskać dostępu do aplikacji. Musisz dodać tych użytkowników jako gości w dzierżawie określonej w żądaniu. W takim przypadku oczekuje się, że uwierzytelnianie będzie uruchamiane 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 wymieniono w poniższej tabeli:

Typ aplikacji	Adres URL logowania
Aplikacje wielodostępne	https://login.microsoftonline.com/organizations
Konta wielodostępne i osobiste	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

Podczas próby uzyskania dostępu do aplikacji użytkownicy otrzymują bezpośredni link do aplikacji lub próbują uzyskać dostęp za pośrednictwem https://myapps.microsoft.comprogramu . W obu przypadkach użytkownicy są przekierowywani w celu zalogowania się do aplikacji. W niektórych przypadkach użytkownik może mieć już aktywną sesję, która używa innego konta osobistego niż to, które ma być używane. Lub mają sesję, która korzysta z konta organizacji, mimo że 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 do dzierżawy, a nie dzierżawy głównej? A może 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 sesji przeglądarki prywatnej

Poproś użytkownika o otwarcie nowej sesji w prywatnej przeglądarce 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. Nie zaproszono użytkownika-gościa

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 wykonaj kroki opisane w temacie Szybki start: Dodawanie użytkowników-gości do katalogu w 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órzy mają przypisany dostęp do aplikacji. Aby sprawdzić, czy aplikacja dla przedsiębiorstw wymaga przypisania użytkownika:

1. W 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 jako część grupy

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

• Aby indywidualnie przypisać użytkownikowi dostęp do aplikacji, zobacz Przypisywanie konta użytkownika do aplikacji dla przedsiębiorstw.

• Aby przypisać użytkowników, którzy 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 spró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 Microsoft Entra dzierżaw, 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 zaproszone do dzierżawy Microsoft Entra nie mogą korzystać z 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 głównej. 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 dzierżawy głównej. Tę weryfikację można tworzyć przy użyciu programu Microsoft Graph lub MSOnline PowerShell.

Microsoft Graph

Wystosuj żądanie do interfejs Graph API MS, 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 potwierdzony, jeśli użytkownik-gość został utworzony przed utworzeniem konta użytkownika dzierżawy głównej.

MSOnline PowerShell

Uwaga

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 potwierdzony, jeśli użytkownik-gość został utworzony przed utworzeniem konta użytkownika dzierżawy głównej.

Uwaga

Moduły programu PowerShell Azure AD i MSOnline są przestarzałe od 30 marca 2024 r. Aby dowiedzieć się więcej, przeczytaj aktualizację wycofania. Po tej dacie obsługa tych modułów jest ograniczona do pomocy w 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 Tożsamość Microsoft Entra (dawniej Azure AD). Aby uzyskać typowe pytania dotyczące migracji, zapoznaj się z często zadawanymi pytaniami dotyczącymi migracji. Uwaga: W wersjach 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 netto użytkownika dzierżawy głównej

Uwaga

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ść zaakceptuje zaproszenie, atrybut użytkownika LiveID (unikatowy identyfikator logowania użytkownika) jest przechowywany AlternativeSecurityIds w 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 ramach AlternativeSecurityIds 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 wewnątrz AlternativeSecurityIds na ciąg zakodowany w formacie base64:

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

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

4. Porównaj wartości z kroków 1 i 3, aby sprawdzić, czy są różne. Konto NetID użytkownika w dzierżawie głównej uległo zmianie 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. Możesz zresetować stan realizacji przy użyciu Azure Portal, Azure PowerShell lub microsoft interfejs Graph API. 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 platformy Azure.