AADSTS50020, konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie

AADSTS50020, konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie

W tym artykule omówimy możliwe rozwiązania problemu AADSTS50020, Konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie . Ten błąd zwykle występuje, gdy użytkownik-gość od dostawcy tożsamości (dostawcy tożsamości) nie może zalogować się do dzierżawy zasobów w Azure Active Directory (Azure AD). Ten błąd może pojawić się w różnych sytuacjach. Każda sytuacja wymaga innego sposobu rozwiązania problemu.

AADSTS50020, konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie

Pełny komunikat o błędzie wyświetlany przez użytkownika-gościa podczas próby uzyskania dostępu do aplikacji lub zasobu w dzierżawie zasobu to:

AADSTS50020: Konto użytkownika „ [chronione pocztą elektroniczną] ” od dostawcy tożsamości {IdentityProviderURL} nie istnieje w dzierżawie {ResourceTenantName}.

Przeglądając dzienniki najemcy głównego, administrator zobaczy następujący komunikat o błędzie:

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 należy dodać konto jako użytkownika zewnętrznego w dzierżawie. Wyloguj się i zaloguj ponownie przy użyciu innego konta użytkownika Azure Active Directory.

AADSTS50020, konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie

Poniższe rozwiązania pomogą Ci naprawić błąd AADSTS50020, Konto użytkownika od dostawcy tożsamości nie istnieje w dzierżawie.

  1. Zmień ustawienie odbiorców logowania w manifeście rejestracji aplikacji
  2. Użyj prawidłowego adresu URL logowania
  3. Wyloguj się, a następnie zaloguj ponownie z innej przeglądarki lub sesji przeglądarki prywatnej
  4. Zaproś gościa
  5. Przypisz dostęp użytkownikom (jeśli dotyczy)
  6. Użyj punktu końcowego specyficznego dla dzierżawy lub organizacji
  7. Zresetuj status wykorzystania konta użytkownika-gościa

Przyjrzyjmy się szczegółowo wszystkim tym poprawkom.

1] Zmień ustawienie odbiorców logowania w manifeście rejestracji aplikacji

Jedną z możliwych przyczyn tego błędu jest użycie przez dzierżawcę nieobsługiwanego typu konta. Na przykład jeśli dla rejestracji aplikacji ustawiono typ konta z jedną dzierżawą, użytkownik innego zidentyfikowanego dostawcy nie może zalogować się do aplikacji.

Aby naprawić błąd AADSTS50020, zmień ustawienie odbiorców logowania w manifeście rejestracji aplikacji w następujący sposób:

  1. Przejdź do Azure Portal .
  2. Wybierz Rejestracje aplikacji .
  3. Wybierz nazwę rejestracji aplikacji.
  4. Wybierz Manifest na pasku bocznym.
  5. W kodzie JSON znajdź ustawieniesignInAudience.
  6. Sprawdź ustawienie na podstawie jednej z następujących wartości:
  • AzureAD i PersonalMicrosoftAccount
  • AzureADMultipleOrgs
  • Konto osobisteMicrosoft

SignInAudience powinien zawierać jedną z wyżej wymienionych wartości. Jeśli nie znajdziesz żadnej z tych wartości w ustawieniu SignInAudience, musisz ponownie utworzyć rejestrację aplikacji.

2] Użyj prawidłowego adresu URL logowania

Inną przyczyną tego błędu jest użycie nieprawidłowego adresu URL logowania. Na przykład jeśli używasz adresu URL https://login.Microsoftonline.com/<YourTenantNameOrID> , oczekuje się, że uwierzytelnianie będzie uruchamiane tylko w dzierżawie. Dlatego użytkownicy w innych organizacjach nie mogą uzyskać dostępu do aplikacji. Gdy inni użytkownicy spróbują to zrobić, wyświetli się komunikat o błędzie logowania.

Aby rozwiązać ten problem, należy dodać tych użytkowników jako gości w dzierżawie określonej w żądaniu. Możesz użyć odpowiedniego adresu URL logowania dla określonego typu aplikacji. Poniżej wymieniono kilka przykładów:

W przypadku aplikacji typu Multitenant można użyć następującego adresu URL logowania.

https://login.microsoftonline.com/organizations

Jeśli korzystasz z kont wielodostępnych i osobistych, możesz użyć następującego adresu URL logowania.

https://login.microsoftonline.com/common

Tylko w przypadku kont osobistych użyj tego adresu URL logowania.

https://login.microsoftonline.com/consumers

3] Wyloguj się, a następnie zaloguj ponownie z innej przeglądarki lub sesji prywatnej przeglądarki

Czasami ten błąd występuje, gdy użytkownik zalogował się do niewłaściwej dzierżawy. Na przykład, gdy użytkownik ma już aktywną sesję w swojej przeglądarce internetowej i próbuje uzyskać dostęp do Twojej aplikacji, klikając odpowiedni link lub wpisując wymagany adres URL w nowej karcie.

W tej sytuacji poproś gościa o wykonanie jednej z następujących czynności:

  • Wyloguj się z konta już otwartego w przeglądarce internetowej. Spowoduje to zakończenie już aktywnej sesji. Teraz może zalogować się przy użyciu prawidłowego łącza i danych uwierzytelniających.
  • Zaloguj się przy użyciu innej przeglądarki internetowej.
  • Zaloguj się w oknie Prywatnym lub Incognito w tej samej przeglądarce internetowej.

4] Zaproś gościa

Ten błąd pojawia się również, gdy użytkownik-gość nie jest zaproszony. Rozwiązanie tej sytuacji jest proste. Zaproś gościa.

5] Przypisz dostęp użytkownikom (jeśli dotyczy)

Jeśli Twoja aplikacja jest aplikacją korporacyjną wymagającą przypisania użytkownika, a użytkownik nie znajduje się na liście dozwolonych użytkowników, którym przypisano dostęp do aplikacji, wystąpi ten błąd.

Możesz sprawdzić, czy Twoja aplikacja korporacyjna wymaga przypisania użytkownika, czy nie, wykonując poniższe kroki:

  1. Przejdź do Azure Portal.
  2. Wybierz aplikacje korporacyjne .
  3. Wybierz aplikację korporacyjną.
  4. Wybierz Właściwości .
  5. Sprawdź, czy opcja Wymagane przypisanie jest ustawiona na Tak . Jeśli jest ustawiona na Tak, aplikacja wymaga przypisania użytkownika.

W takiej sytuacji Przypisz dostęp użytkownikom indywidualnie lub w ramach grupy.

6] Użyj punktu końcowego specyficznego dla dzierżawcy lub organizacji

Kod błędu AADSTS50020 może również wystąpić, gdy użytkownik próbuje użyć przepływu poświadczeń hasła właściciela zasobu (ROPC) dla swoich kont osobistych. Platforma Microsoft Identity Platform obsługuje ROPC tylko w ramach dzierżawców usługi Azure AD, a nie kont osobistych.

W tej sytuacji użytkownik musi użyć punktu końcowego specyficznego dla dzierżawcy lub organizacji. Należy pamiętać, że konta osobiste nie mogą korzystać z ROPC, nawet jeśli zostaną zaproszone do dzierżawy usługi Azure AD.

7] Zresetuj status realizacji konta użytkownika-gościa

Jeśli administrator usunął nazwę użytkownika-gościa w dzierżawie zasobów i utworzył ją ponownie w dzierżawie głównej, użytkownik-gość napotka ten błąd. Administrator powinien również sprawdzić, czy konto użytkownika-gościa w dzierżawie zasobu nie jest skojarzone z kontem użytkownika-gościa w dzierżawie głównej.

Aby naprawić błąd występujący w tej sytuacji, zresetuj stan wykorzystania konta użytkownika-gościa w dzierżawie zasobu.

Otóż ​​to. Mam nadzieję, że to pomoże.

Jaki identyfikator dzierżawy jest używany na platformie Azure?

Identyfikator dzierżawy na platformie Azure to unikatowy identyfikator dzierżawy Azure Active Directory (Azure AD). Nazywa się go również identyfikatorem dzierżawcy usługi Office 365. Istnieją różne sposoby uzyskania identyfikatora dzierżawy platformy Azure.

Kto jest administratorem dzierżawy?

Administrator dzierżawy to użytkownik, który ma najwyższy poziom uprawnień w dzierżawie Azure Active Directory (Azure AD). Może zarządzać wszystkimi aspektami najemcy, w tym użytkownikami, grupami, uprawnieniami i ustawieniami.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *