Як виправити помилку AADSTS50020 «User account not found in tenant»

By Mirko Peters · 2026-04-21

Якщо ви коли-небудь зустрічали помилку «AADSTS50020: User account not found in tenant» під час входу в Microsoft 365, Azure чи будь-який застосунок, що використовує Microsoft Entra ID (раніше Azure AD), ви не самотні. Ця капризна помилка — поширена головна біль для адміністраторів, розробників і звичайних користувачів, які стикаються з проблемами входу або надання доступу.

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

Titelbild: How to Fix AADSTS50020 User Account Not Found in Tenant

Цей посібник розповість, що насправді означає AADSTS50020, де вона з'являється, як швидко її виправити і як запобігти їй у майбутньому. Ми розглянемо основні причини, складні ситуації та покрокові рішення, тож незалежно від того, чи керуєте ви всією організацією, чи усуваєте несправності як розробник, ви точно знатимете, як упоратися з цією проблемою ідентифікації.

Готові розплутати ці заплутані повідомлення про клієнта і повернутися до роботи? Тоді почнімо і розберемо, що насправді відбувається, — щоб ви могли виправити це раз і назавжди, а може, навіть не допустити її повторної появи!

Розуміння помилки постачальника ідентифікації AADSTS50020

Коли ви стикаєтеся з помилкою AADSTS50020, Microsoft фактично каже: «Вибачте, такого облікового запису користувача немає в цьому клієнті». Але за цим сухим попередженням ховається трохи більше технічної драми. Ця помилка безпосередньо пов'язана з проблемами постачальника ідентифікації в середовищах Microsoft Entra ID (Azure AD). Простіше кажучи, служба намагається зіставити ваш обліковий запис для входу з конкретним клієнтом (каталогом вашої організації), але нічого не знаходить.

Таке невідповідність може виникнути з кількох серйозних причин, але завжди означає одне: служба автентифікації не може знайти запис про ваш обліковий запис у каталозі, який вона перевіряє. Можливо, ви використовуєте особистий обліковий запис замість робочого, можливо, ви потрапили не в той клієнт, а можливо, у бекенді виникла технічна несправність у налаштуванні облікових записів або доменів.

З погляду Microsoft, кожна спроба входу проходить через «постачальника ідентифікації», який перевіряє, хто ви є і до якого клієнта належите. Якщо ви прийшли до дверей із неправильними ключами — або з ключами, яких вони ніколи не бачили, — вам відмовлять, а код AADSTS50020 — це версія Microsoft повідомлення «доступ заборонено: такого користувача тут немає».

Розуміння того, як і чому виникає ця помилка, дає вам можливість її діагностувати. Наступні розділи допоможуть визначити точні симптоми та глибше розібратися в найпоширеніших технічних збоях, які заважають автентифікації в хмарних середовищах Microsoft.

Типові симптоми та проблемні сценарії для користувачів

Ви потрапляєте на сторінку входу в Office 365, Azure Portal або застосунок, інтегрований із Microsoft, вводите адресу електронної пошти і бачите спливаюче вікно з помилкою «User account from identity provider does not exist in tenant». Іноді повідомлення містить ваш обліковий запис і назву клієнта, і ви залишаєтеся в розгубленості.
Замість панелі керування компанії чи потрібного застосунку ви отримуєте відмову в доступі або повідомлення, що вашого облікового запису немає в організації, — хоча ви впевнені, що обліковий запис у вас є або нещодавно надійшло запрошення.
Якщо ви намагаєтеся зайти як гість або зовнішній користувач, ви можете просто не мати доступу до потрібних ресурсів, незалежно від того, скільки разів ви входите або яким браузером користуєтеся.
Розробники та адміністратори можуть помітити в журналах і звітах закономірності невдалих спроб входу або збоїв запитів токенів, пов'язаних із конкретними реєстраціями застосунків, кінцевими точками чи типами користувачів.

Основні причини помилок входу AADSTS50020

Помилка AADSTS50020 — це не випадковий збій. Це спосіб Microsoft Entra сказати, що щось пішло не так зі зіставленням облікових записів, вибором клієнта чи налаштуваннями постачальника ідентифікації. По суті, проблема полягає в невідповідності між користувачем, який намагається увійти, і місцем, де Microsoft шукає інформацію про цього користувача.

Це може статися з багатьох причин: від використання особистої адреси електронної пошти замість облікового запису організації до вибору неправильної кінцевої точки входу, прихованих помилок у конфігурації застосунків або проблем із призначенням користувачів. Іноді це просто помилка в кроках, наприклад клацання не за тим запрошенням. Інколи ж корінь проблеми глибше, у «внутрішній кухні» — наприклад, у проблемах синхронізації каталогу на бекенді чи відсутності перевірки домену.

Розуміння кожної з цих першопричин – ключ до того, щоб подолати цю стіну «user not found». Чи маєте ви справу з особистими обліковими записами Microsoft Entra, непідтримуваними типами облікових записів, неправильно обраними кінцевими точками чи проблемами із запрошеннями гостей і призначенням застосунків, далі ми розберемо найпоширеніші сценарії. Так ви будете знати, де шукати, що перевіряти і – найголовніше – як остаточно все виправити.

А якщо ви хочете побачити, як некеровані обліковані записи гостей можуть створювати ще більше проблем, перегляньте цей посібник про приховані небезпеки облікових записів гостей Microsoft 365, які залишилися в системі. У ньому є поради, як підтримувати порядок і безпеку.

Проблеми з особистими обліковими записами Microsoft Entra та непідтримувані типи облікових записів

Входи з особистих облікових записів: Якщо ви намагаєтеся увійти в центр адміністрування Microsoft Entra з особистого облікового запису Microsoft (наприклад, @outlook.com або @hotmail.com), зазвичай виникає помилка AADSTS50020, адже цей центр адміністрування приймає лише облікові записи організації (робочі або навчальні).
Непідтримувані типи облікових записів у реєстраціях застосунків: Припустимо, застосунок налаштовано як «одного клієнта», але ви намагаєтеся отримати до нього доступ з обліковим записом іншої організації або особистим обліковим записом Microsoft. Таке невідповідність теж призведе до цієї помилки.
Змішування багатоклієнтських і особистих облікових записів: Розробники іноді налаштовують застосунки так, щоб вони приймали кілька каталогів організацій, але забувають дозволити особисті облікові записи – або навпаки. Такі помилки конфігурації призводять до збоїв автентифікації для користувачів, які не належать до дозволеного типу.

Проблеми з кінцевими точками, вибором клієнта та запрошеннями гостьових користувачів

Використання неправильної кінцевої точки автентифікації: Входи Microsoft підтримують кілька кінцевих точок – зокрема /common, /organizations, /consumers та specific для клієнта. Якщо ви намагаєтеся увійти в застосунок, прив'язаний до клієнта, через кінцеву точку /common або /consumers із робочим обліковим записом, Azure AD не може зіставити ваш обліковий запис, і виникає помилка AADSTS50020.
Вхід у неправильний клієнт: Напрочуд легко опинитися не в тому каталозі організації – особливо якщо ви належите до кількох. Якщо ви проходите автентифікацію в клієнті, де вашого облікового запису немає, ви отримаєте цю помилку. Це класична ситуація «ви стукаєте не в ті двері».
Запрошення гостьового користувача не надіслано або не активовано належним чином: Організації, що запрошують зовнішніх співробітників, іноді забувають надіслати запрошення гостей або правильно їх налаштувати. Якщо обліковий запис гостя не зареєстровано чи не активовано належним чином, користувач не видно в каталозі, і він отримує категоричну відмову під час спроби доступу до застосунків або файлів.
Застосунку потрібне призначення користувача, але у вас немає доступу: Деякі застосунки в Microsoft Entra обмежені для конкретних користувачів або груп. Якщо ввімкнено параметр «потрібне призначення користувача», а вас немає у списку, доступ буде заборонено, і помилка може виглядати як AADSTS50020, навіть коли ваш обліковий запис дійсний.
Видалені та повторно створені користувачі: Якщо користувача видалили, а потім повторно створили в домашньому клієнті з тією самою електронною адресою, Azure AD може не розпізнати «нового» користувача як той самий об'єкт, особливо між кількома клієнтами. Це цілком може спричинити невирішені входи та ту сумнозвісну помилку.
Помилки конфігурації домену та DNS: Якщо ваша організація використовує власні домени (для імен користувачів «UPN» або реєстрацій застосунків), а ці домени не перевірено або їх неправильно налаштовано в Azure AD, розпізнавання користувача може не вдатися з помилкою AADSTS50020. Навіть локальні помилки DNS або блокування кінцевих точок автентифікації можуть порушити вхід, тож інфраструктура має значення!
Збої синхронізації каталогів (гібридна ідентичність): У деяких гібридних корпоративних середовищах, де облікові записи синхронізуються з локальним AD за допомогою інструментів на кшталт Azure AD Connect, відсутні або несинхронізовані користувачі в цільовому клієнті також можуть спричиняти помилки «обліковий запис не знайдено». Перевіряйте стан синхронізації щоразу, коли використовується гібридна ідентичність.
Shadow IT і некеровані застосунки: Незатверджені застосунки або надання згоди сторонніх застосунків (класичний Shadow IT) можуть створювати конфліктні шляхи доступу користувачів і іноді сприяти стійким помилкам входу. Щоб розібратися з ризиками Shadow IT, перегляньте цей посібник із керування Shadow IT у вашому клієнті M365.

Ефективні рішення для помилки AADSTS50020 «Account Not Found»

Щоб виправити помилку AADSTS50020, спершу треба точно визначити, де саме виникає невідповідність: тип облікового запису, каталог, кінцева точка чи дозволи на доступ. Коли ви знайдете першопричину, можна застосувати конкретні заходи для кожного сценарію, і помилка більше не з'являтиметься.

Якщо проблема в тому, що ви використовуєте особистий обліковий запис замість робочого (або навпаки), виберіть правильний тип входу. Якщо проблема в реєстрації застосунку, перегляньте параметри аудиторії входу та оновіть їх так, щоб вони підтримували потрібні облікові записи: один клієнт, кілька клієнтів або, за потреби, особисті облікові записи Microsoft. Для гостьових користувачів переконайтеся, що запрошення надіслано та прийнято належним чином. Іноді достатньо надіслати нове запрошення, і все працює.

Не забувайте про призначення користувачів! Якщо застосунок цього вимагає, призначте потрібних людей або групи в Microsoft Entra, щоб усунути перешкоду. Якщо проблема не зникає через кешування браузера або «липкі» сеанси, спробуйте вийти з облікового запису та знову відкрити сторінку входу в приватному вікні. Іноді доведеться створити новий каталог або призначити доступ на вищому рівні, особливо під час розгортання нових клієнтів або міграції користувачів.

Повноцінні рішення для великих організацій також передбачають належне управління. Дізнайтеся, як дрейф політик і призначень може призвести до хаосу у великих середовищах, і чому регулярні перевірки та RBAC є критично важливими, у посібнику зі стратегії корпоративного управління в Azure. Поєднавши правильне технічне рішення з проактивним плануванням, ви не дасте AADSTS50020 знову зіпсувати сторінки входу.

Перевірені найкращі практики для запобігання помилкам AADSTS50020 у майбутньому

Виберіть правильну кінцеву точку входу: завжди узгоджуйте аудиторію входу застосунку (один клієнт, кілька клієнтів або особисті облікові записи) з відповідною кінцевою точкою входу. Невідповідність кінцевих точок і аудиторії є найпоширенішим джерелом плутанини.
Уважно керуйте гостьовими користувачами: не просто запрошуйте гостей і забувайте про них. Тримайте життєвий цикл гостьових користувачів під контролем: регулярні перевірки, доступ з обмеженим терміном і чітке відключення, що зменшить вашу поверхню атаки. Поради з цієї теми дивіться в посібнику з управління гостьовими обліковими записами Microsoft 365.
Забезпечте структурований доступ і призначення: переконайтеся, що застосунки, які потребують призначення користувачів, налаштовано з чіткими й актуальними списками того, хто і до чого має доступ. Не залишайте призначення без змін: регулярно переглядайте й оновлюйте їх.
Перевіряйте й контролюйте дозволи застосунків: стримуйте надмірне надання згод і «тіньове ІT» шляхом перегляду реєстрацій застосунків і зовнішнього спільного доступу. Для глибшої безпеки ідентифікації та зниження ризиків скористайтеся висновками з цього епізоду про цикл безпеки умовного доступу Entra ID і підтримуйте політики умовного доступу зрозумілими та такими, що виконуються.
Перевіряйте домени та стежте за DNS: завжди двічі перевіряйте підтвердження власних доменів в Azure AD і зважайте на локальні правила DNS або брандмауера, які можуть блокувати кінцеві точки входу Microsoft.
Стежте за синхронізацією гібридної ідентифікації: якщо ви синхронізуєте дані з локальним AD, відстежуйте проблеми з Azure AD Connect і переконайтеся, що об'єкти користувачів синхронізуються з усіма потрібними клієнтами.

Підсумок: причини, симптоми та рішення для AADSTS50020

Типові симптоми: відмова в доступі, спливаючі вікна з повідомленням про те, що користувача не знайдено в клієнті, або невдалі спроби входу в застосунки Microsoft 365 та Azure.
Основні причини: невідповідність типу облікового запису (особистий чи робочий), неправильний клієнт або кінцева точка, неповні гостьові запрошення, користувачі без призначення, помилки доменів або DNS чи збої синхронізації каталогу.
Рішення: використовуйте правильний тип входу для свого облікового запису, виберіть потрібну кінцеву точку та клієнта, повторно надішліть гостьові запрошення, призначте користувачів до застосунків, перевірте свої домени, усуньте збої синхронізації та очищуйте кеш браузера.
Поради щодо запобігання: впроваджуйте перевірки доступу, контролюйте життєвий цикл гостьових і звичайних користувачів та підтримуйте надійне управління застосунками й кінцевими точками.