Jak naprawić błąd AADSTS50020: nie znaleziono konta użytkownika w dzierżawie

By Mirko Peters · 2026-04-21

Jeśli kiedykolwiek błąd „AADSTS50020: User account not found in tenant” uniemożliwił Ci zalogowanie się do usługi Microsoft 365, Azure lub dowolnej aplikacji korzystającej z Microsoft Entra ID, to nie jesteś sam. Ten irytujący błąd to częsty problem administratorów, deweloperów i zwykłych użytkowników, którzy napotykają trudności podczas logowania lub przyznawania dostępu.

Automatically translated with AI from the original post. Read the English original

Jeśli kiedykolwiek błąd „AADSTS50020: User account not found in tenant” uniemożliwił Ci zalogowanie się do usługi Microsoft 365, Azure lub dowolnej aplikacji korzystającej z Microsoft Entra ID (dawniej Azure AD), to nie jesteś sam. Ten irytujący błąd to częsty problem administratorów, deweloperów i zwykłych użytkowników, którzy napotykają trudności podczas logowania lub przyznawania dostępu.

Ten przewodnik wyjaśnia, co tak naprawdę oznacza AADSTS50020, gdzie się pojawia, jak szybko go naprawić i jak mu zapobiegać w przyszłości. Omawiamy przyczyny źródłowe, trudniejsze sytuacje oraz rozwiązania krok po kroku, dzięki czemu niezależnie od tego, czy zarządzasz całą organizacją, czy rozwiązujesz problem jako deweloper, będziesz wiedzieć dokładnie, jak poradzić sobie z tym problemem tożsamości.

Gotowy, by rozplątać te mylące komunikaty dotyczące dzierżawy i wrócić do pracy? Zagłębmy się w to i wyjaśnijmy, co się naprawdę dzieje, abyś mógł rozwiązać problem raz na zawsze, a być może nawet zapobiec jego ponownemu pojawieniu się!

Omówienie błędu dostawcy tożsamości AADSTS50020

Gdy napotkasz błąd AADSTS50020, Microsoft w gruncie rzeczy mówi: „Przepraszamy, to konto użytkownika nie istnieje w tej dzierżawie”. Pod tym suchym ostrzeżeniem kryje się jednak nieco więcej technicznego dramatu. Ten błąd jest bezpośrednio powiązany z problemami dostawcy tożsamości w środowiskach Microsoft Entra ID (Azure AD). Mówiąc wprost: usługa próbuje dopasować Twoje konto logowania do konkretnej dzierżawy (katalogu Twojej organizacji), ale nie znajduje go.

Ta niezgodność może wynikać z kilku poważnych przyczyn, ale zawsze oznacza, że usługa uwierzytelniania nie może znaleźć rekordu Twojego konta w katalogu, który przeszukuje. Być może używasz konta osobistego zamiast służbowego, być może trafiłeś do niewłaściwej dzierżawy, a być może w zapleczu wystąpił błąd techniczny w konfiguracji kont lub domen.

Z perspektywy Microsoftu każda próba logowania trafia do „dostawcy tożsamości”, który sprawdza, kim jesteś i do której dzierżawy należysz. Jeśli zjawisz się w drzwiach z niewłaściwymi kluczami albo z kluczami, których nigdy wcześniej nie widziano, zostaniesz odrzucony, a kod AADSTS50020 to wersja Microsoftu komunikatu „odmowa dostępu: użytkownik nie został tu znaleziony”.

Zrozumienie tego, jak i dlaczego ten błąd występuje, daje Ci możliwość jego zdiagnozowania. Kolejne sekcje pomogą Ci rozpoznać konkretne objawy i przyjrzeć się bliżej najczęstszym błędom technicznym, które zakłócają uwierzytelnianie w chmurze Microsoft.

Typowe objawy i problematyczne doświadczenia użytkowników

• Trafiasz na ekran logowania do Office 365, Azure Portal lub aplikacji zintegrowanej z Microsoftem, wpisujesz adres e-mail i pojawia się wyskakujący komunikat o błędzie: „User account from identity provider does not exist in tenant”. Czasem komunikat odwołuje się do Twojego konta i nazwy dzierżawy, przez co zostajesz z pytaniem bez odpowiedzi.
• Zamiast zobaczyć pulpit firmy lub aplikację, zostajesz odrzucony albo informowany, że Twoje konto nie istnieje w organizacji, mimo że jesteś pewien, iż masz konto lub niedawno otrzymałeś zaproszenie.
• Jeśli próbujesz uzyskać dostęp jako gość lub użytkownik zewnętrzny, możesz odkryć, że po prostu nie możesz dotrzeć do potrzebnych zasobów, niezależnie od tego, ile razy się zalogujesz lub z jakiej przeglądarki korzystasz.
• Deweloperzy i administratorzy mogą zauważyć w dziennikach i raportach wzorce nieudanych logowań lub nieudanych żądań tokenów związanych z konkretnymi rejestracjami aplikacji, punktami końcowymi lub typami użytkowników.

Przyczyny źródłowe awarii logowania AADSTS50020

Błąd AADSTS50020 nie jest przypadkową usterką. To sposób, w jaki Microsoft Entra informuje, że coś poszło nie tak z dopasowaniem kont, wyborem dzierżawy lub ustawieniami dostawcy tożsamości. W istocie problem polega na niezgodności między użytkownikiem, który próbuje się zalogować, a miejscem, w którym Microsoft szuka informacji o tym użytkowniku.

Może to mieć wiele przyczyn: od użycia prywatnego adresu e-mail zamiast konta służbowego, przez wybór niewłaściwego punktu końcowego logowania, podstępne konfiguracje aplikacji, aż po przypisania użytkowników, które wymknęły się spod kontroli. Czasem to zwykły błąd, na przykład kliknięcie niewłaściwego linku z zaproszeniem. Innym razem przyczyna tkwi głębiej, w „instalacji” usługi, na przykład w problemach z synchronizacją katalogów po stronie zaplecza lub brakującej weryfikacji domen.

Zrozumienie każdej z tych przyczyn źródłowych jest kluczem do przebicia się przez ścianę „user not found”. Niezależnie od tego, czy masz do czynienia z osobistymi kontami Microsoft Entra, nieobsługiwanymi typami kont, błędnym wyborem punktu końcowego czy problemami związanymi z zaproszeniami gości i przypisaniami aplikacji, poniżej omówimy najczęstsze scenariusze. Dzięki temu będziesz wiedzieć, gdzie szukać, o co pytać i – co najważniejsze – jak raz na zawsze rozwiązać problem.

A jeśli chcesz zobaczyć, jak nieusuwane konta gości w usłudze Microsoft 365 potrafią narobić dodatkowych komplikacji, zajrzyj do tego przewodnika o ukrytych zagrożeniach związanych z pozostawionymi kontami gości w Microsoft 365, znajdziesz tam wskazówki, jak utrzymać porządek i bezpieczeństwo.

Problemy z osobistymi kontami Microsoft Entra i nieobsługiwane typy kont

• Logowanie na konto osobiste: Próba zalogowania się do centrum administracyjnego Microsoft Entra za pomocą osobistego konta Microsoft (np. @outlook.com lub @hotmail.com) zwykle kończy się błędem AADSTS50020, ponieważ to centrum administracyjne akceptuje wyłącznie konta organizacyjne (służbowe lub szkolne).
• Nieobsługiwane typy kont w rejestracjach aplikacji: Załóżmy, że aplikacja jest skonfigurowana jako „jednodzierżawcza” (single tenant), ale próbujesz uzyskać do niej dostęp za pomocą konta z innej organizacji lub osobistego konta Microsoft. Taka niezgodność również spowoduje ten błąd.
• Mieszanie konfiguracji wielodzierżawczych i kont osobistych: Deweloperzy czasem konfigurują aplikacje tak, by akceptowały wiele katalogów organizacyjnych, ale zapominają dopuścić konta osobiste – lub odwrotnie. Takie błędne konfiguracje prowadzą do nieudanego uwierzytelniania użytkowników spoza dozwolonego typu konta.

Problemy z punktami końcowymi, wyborem dzierżawy i zaproszeniami dla użytkowników gości

• Użycie niewłaściwego punktu końcowego uwierzytelniania: Logowania Microsoft obsługują wiele punktów końcowych, takich jak /common, /organizations, /consumers oraz punkty specyficzne dla dzierżawy. Jeśli próbujesz zalogować się do aplikacji przypisanej do konkretnej dzierżawy, używając punktu końcowego /common lub /consumers z kontem służbowym, Azure AD nie może dopasować Twojego konta, co powoduje błąd AADSTS50020.
• Logowanie do niewłaściwej dzierżawy: Dość łatwo trafić do niewłaściwego katalogu organizacyjnego, zwłaszcza jeśli należysz do kilku z nich. Jeśli uwierzytelnisz się w dzierżawie, w której Twoje konto nie istnieje, otrzymasz ten błąd. To klasyczny problem „pukania do niewłaściwych drzwi”.
• Zaproszenie gościa nie zostało wysłane lub poprawnie zrealizowane: Organizacje zapraszające zewnętrznych współpracowników czasem zapominają wysłać zaproszenia lub poprawnie je skonfigurować. Jeśli konto gościa nie zostało prawidłowo zarejestrowane lub aktywowane, użytkownik jest niewidoczny w katalogu i przy próbie dostępu do aplikacji lub plików otrzymuje stanowczą odmowę.
• Aplikacja wymaga przypisania użytkownika, a Ty nie masz dostępu: Niektóre aplikacje w Microsoft Entra są zablokowane dla określonych użytkowników lub grup. Jeśli ustawiono opcję „wymagane przypisanie użytkownika”, a Ciebie nie ma na liście, dostęp zostanie odmówiony – a komunikat może wyglądać jak AADSTS50020, nawet jeśli Twoje konto jest poprawne.
• Usunięci i ponownie utworzeni użytkownicy: Jeśli użytkownik został usunięty, a następnie ponownie utworzony w dzierżawie macierzystej z tym samym adresem e-mail, Azure AD może nie rozpoznać „nowego” użytkownika jako tego samego obiektu, zwłaszcza w środowiskach wielu dzierżaw. Może to prowadzić do nierozwiązanych logowań i wspomnianego już, notorycznego kodu błędu.
• Błędne konfiguracje domen i DNS: Jeśli organizacja używa domen niestandardowych (w nazwach UPN lub rejestracjach aplikacji), a domeny te nie są zweryfikowane lub są źle skonfigurowane w Azure AD, rozpoznawanie użytkowników może zakończyć się błędem AADSTS50020. Nawet lokalne błędy DNS lub blokady punktów końcowych uwierzytelniania mogą uniemożliwić logowanie, więc infrastruktura ma znaczenie!
• Problemy z synchronizacją katalogów (tożsamość hybrydowa): W niektórych hybrydowych środowiskach korporacyjnych, gdzie konta są synchronizowane z lokalnym AD za pomocą narzędzi takich jak Azure AD Connect, brakujący lub niezsynchronizowani użytkownicy w dzierżawie docelowej mogą również powodować błędy typu „konto nie znalezione”. Sprawdzaj stan synchronizacji zawsze, gdy w grę wchodzi tożsamość hybrydowa.
• Shadow IT i niezarządzane aplikacje: Nieautoryzowane aplikacje lub zgody na aplikacje innych firm (klasyczny Shadow IT) mogą tworzyć konfliktowe ścieżki dostępu użytkowników, a czasem przyczyniać się do uporczywych błędów logowania. Aby opanować ryzyka związane z Shadow IT, zapoznaj się z tym przewodnikiem o zarządzaniu Shadow IT w dzierżawie Microsoft 365.

Skuteczne rozwiązania błędu AADSTS50020 „Nie znaleziono konta”

Naprawę błędu AADSTS50020 zawsze zaczynamy od ustalenia, gdzie dokładnie leży niezgodność: w typie konta, katalogu, punkcie końcowym czy uprawnieniach dostępu. Gdy znasz przyczynę źródłową, możesz zastosować konkretne rozwiązanie dla danego scenariusza i sprawić, że błąd nie pojawi się ponownie.

Jeśli problem dotyczy konta osobistego lub służbowego, użyj odpowiedniego typu logowania. Jeśli problem leży w rejestracji aplikacji, sprawdź ustawienia odbiorców logowania (sign-in audience) i zaktualizuj je tak, aby obsługiwały konta, których potrzebujesz: jednodzierżawcze (single tenant), wielodzierżawcze (multitenant) lub nawet osobiste konta Microsoft, jeśli zachodzi taka potrzeba. W przypadku użytkowników gości upewnij się, że zaproszenia zostały poprawnie wysłane i zrealizowane. Czasem wystarczy wysłać nowe zaproszenie, by rozwiązać cały problem.

Nie zapominaj o przypisaniu użytkowników! Jeśli aplikacja tego wymaga, przypisz odpowiednie osoby lub grupy w usłudze Microsoft Entra, aby usunąć przeszkodę. Jeśli zamieszanie utrzymuje się z powodu pamięci podręcznej przeglądarki lub przylepnych sesji, spróbuj się wylogować i ponownie otworzyć stronę logowania w oknie prywatnym lub incognito. Czasem trzeba utworzyć nowy katalog lub przypisać dostęp na wyższym poziomie, szczególnie podczas budowy nowych dzierżaw lub migracji użytkowników.

Pełne rozwiązania dla przedsiębiorstw wymagają także wdrożenia odpowiedniego ładu (governance). Dowiedz się, jak dryf zasad i przypisań może wprowadzić chaos w dużych środowiskach i dlaczego regularne przeglądy oraz RBAC są krytyczne, w tym przewodniku po strategii ładu dla przedsiębiorstw w Azure. Dzięki właściwemu rozwiązaniu technicznemu i proaktywnemu planowaniu możesz sprawić, że AADSTS50020 nie będzie straszyć na Twoich stronach logowania.

Sprawdzone najlepsze praktyki, które zapobiegają przyszłym błędom AADSTS50020

• Wybierz właściwy punkt końcowy logowania: Zawsze dopasuj odbiorców logowania swojej aplikacji (jednodzierżawcze, wielodzierżawcze lub osobiste) do odpowiedniego punktu końcowego logowania. Niedopasowane punkty końcowe i odbiorcy to najczęstsze źródło zamieszania.
• Zarządzaj użytkownikami gośćmi z rozwagą: Nie wystarczy zaprosić gości i o nich zapomnieć. Utrzymuj ścisły cykl życia kont gości – regularne przeglądy, dostęp ograniczony czasowo i jasno określone procedury offboardingu – a zmniejszysz powierzchnię ataku. Więcej porad na ten temat znajdziesz w przewodniku po zarządzaniu kontami gości w Microsoft 365.
• Wymuszaj uporządkowany dostęp i przypisania: Upewnij się, że aplikacje wymagające przypisania użytkowników mają jasne, aktualne listy osób i zakresów dostępu. Nie pozwalaj przypisaniom się zdezaktualizować – regularnie je przeglądaj i aktualizuj.
• Audytuj i nadzoruj uprawnienia aplikacji: Kontroluj rozrost zgód (consent sprawl) i shadow IT, przeglądając rejestracje aplikacji oraz udostępnianie zewnętrzne. Aby lepiej zabezpieczyć tożsamość i ograniczyć ryzyko, skorzystaj z wniosków zawartych w tym odcinku o pętli bezpieczeństwa dostępu warunkowego w Entra ID i dbaj o to, by zasady dostępu warunkowego były przejrzyste i egzekwowalne.
• Weryfikuj domeny i monitoruj DNS: Zawsze dwukrotnie sprawdzaj weryfikację domen niestandardowych w Azure AD i zwracaj uwagę na lokalne reguły DNS lub zapory sieciowe, które mogą blokować punkty końcowe logowania Microsoft.
• Dbaj o synchronizację tożsamości hybrydowej: Jeśli synchronizujesz dane z lokalnego AD, obserwuj problemy z Azure AD Connect i upewnij się, że obiekty użytkowników są synchronizowane do wszystkich właściwych dzierżaw.

Podsumowanie przyczyn, objawów i rozwiązań błędu AADSTS50020

• Typowe objawy: Odmowa dostępu, komunikaty o błędach informujące, że użytkownik nie został znaleziony w dzierżawie, lub nieudane próby logowania do aplikacji Microsoft 365 i Azure.
• Główne przyczyny: niezgodność typu konta (osobiste kontra służbowe), błędna dzierżawa lub punkt końcowy, niekompletne zaproszenia gości, nieprzypisani użytkownicy, błędy domen lub DNS albo nieudana synchronizacja katalogu.
• Rozwiązania: użyj właściwego logowania dla typu konta, wybierz poprawny punkt końcowy i dzierżawę, ponownie wyślij zaproszenia gości, przypisz użytkowników do aplikacji, zweryfikuj domeny, napraw problemy z synchronizacją i zadbaj o to, by pamięć podręczna przeglądarki nie powodowała problemów.
• Wskazówki zapobiegawcze: wdrażaj przeglądy dostępu, kontroluj cykl życia gości i użytkowników oraz utrzymuj silny ład nad aplikacjami i punktami końcowymi.