Розуміння помилки AADSTS90002 «Tenant Not Found»

By Mirko Peters · 2026-04-20

Якщо ви бачите помилку AADSTS90002, це, по суті, спосіб Microsoft сказати: «Гей, я не можу знайти ваш клієнт!» Вона з’являється переважно в середовищах Microsoft 365, Azure Active Directory або Entra ID, коли ви намагаєтеся увійти в систему або підключити сервіс, але ваш клієнт не можна знайти. Простими словами: система не бачить жодного клієнта, який відповідає даним, які ви вказали.

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

Якщо ви бачите помилку AADSTS90002, це, по суті, спосіб Microsoft сказати: «Гей, я не можу знайти ваш клієнт!» Вона з’являється переважно в середовищах Microsoft 365, Azure Active Directory або Entra ID, коли ви намагаєтеся увійти в систему або підключити сервіс, але ваш клієнт не можна знайти. Простими словами: система не бачить жодного клієнта, який відповідає даним, які ви вказали.

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

Це може статися з багатьох причин. Можливо, хтось ввів неправильну URL-адресу для входу. Або клієнт було видалено чи призупинено, іноді випадково! Іноді все простіше: термін дії підписки для цього клієнта закінчився або щось пішло не так під час реєстрації чи налаштування застосунку. Розробники час від часу стикаються з цією помилкою, якщо їхній застосунок вказує на неправильний клієнт або неправильне середовище Azure AD під час входу.

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

Як виправити помилку AADSTS90002 покроково

Готові розібратися з помилкою AADSTS90002? Гарна новина: більшість виправлень вам під силу, навіть якщо на перший погляд це виглядає технічно складно. Насамперед завжди перевірте, що ви входите з правильним ідентифікатором клієнта та використовуєте правильну URL-адресу для входу. Помилки друку, значення, скопійовані зі старої документації, або плутанина між тестовим і робочим середовищами — відомі причини такого збою.

Далі переконайтеся, що клієнт справді існує та активний. Іноді клієнти видаляють, призупиняють або пов’язана підписка втрачає чинність. Перейдіть до центру адміністрування Microsoft або попросіть це зробити вашого ІТ-адміністратора, перевірте статус клієнта, активні підписки та чи дійсна ще ваша ліцензія. Зазвичай саме тут хтось розуміє: «Ага, той клієнт вивели з експлуатації минулого кварталу!»

Якщо все одно щось не так, перевірте конфігурацію застосунку. Чи використовуєте ви багатоклієнтські застосунки? Чи зареєстрували ви їх в правильному екземплярі Azure AD? Іноді розробники жорстко прописують ідентифікатор клієнта в коді або конфігураційному файлі та випадково передають неправильне значення в робоче середовище, особливо в хмарних розгортаннях із кількома середовищами.

Автоматизації, субʼєкти-служби та конвеєри CI/CD теж можуть видавати цю помилку. Якщо ваші скрипти або застосунки раптово перестають працювати, переконайтеся, що облікові дані субʼєкта-служби не минули і не були відкликані. У неінтерактивних процесах часто трапляється так, що забуте поновлення або видалена реєстрація призводить до збоїв пошуку клієнта.

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

Якщо ви хочете глибше розібратися в безпеці ідентифікації та поширених помилках, які можуть ускладнити роботу з Azure AD, ознайомтеся з цим обговоренням на тему how to manage conditional access and identity debt. Ці матеріали допоможуть підтримувати рівень ідентифікації у доброму стані та діяти на випередження, щоб подібні помилки не заскакували вас зненацька.

Почніть з основ, будьте методичні, і ви зазвичай упораєтеся з помилкою «Tenant Not Found» ще до обіду. А якщо ви зайшли в глухий кут, найкращий наступний крок — залучити адміністратора підписки або службу підтримки.

Поширені запитання та відповіді щодо проблем «Tenant Not Found»

Якщо ви коли-небудь ламали голову над помилкою AADSTS90002, ви не самотні. У людей завжди виникають питання, особливо коли їхній клієнт «мав би» існувати, а Microsoft постійно каже протилежне. Розберімо найпоширеніші запитання та побоювання щодо цієї сумнозвісної помилки.

Насамперед: «Чому я бачу „Tenant Not Found“, хоча знаю, що мій клієнт існує?» Зазвичай причина в дрібних деталях: застарілій або з помилкою написаній доменній назві, невідповідності регіону чи кешованих налаштуваннях у браузері або застосунку. Іноді DNS потребує часу, щоб оновитися після змін у клієнті. Завжди перевірте дані для входу та спробуйте очистити кеш або DNS, перш ніж хвилюватися через серйозніші проблеми.

Ще одне важливе питання: «Чи можна відновити доступ, якщо я не адміністратор?» Зазвичай права користувачів без адмін-ролі обмежені. Якщо клієнт було видалено або підписка закінчилася, повернути його до роботи може лише адміністратор із відповідними правами. Втім, якщо доступ заблоковано через дрібні проблеми, наприклад неправильні URL-адреси або застарілі субʼєкти служби, ви можете звернутися до адміністратора або виправити конфігурацію, не чекаючи втручання на найвищому рівні.

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

Для тих, хто автоматизує процеси або працює з CI/CD, типовими причинами є прострочені клієнтські секрети або відкликані права субʼєктів служби. Зробіть звичкою регулярний аудит субʼєктів служби, оновлення облікових даних до їх закінчення терміну дії та зберігання журналів, щоб швидко виявляти збої під час визначення клієнта.

Не забувайте про мережеві проблеми. Збої DNS і проксі-серверів або суворі правила брандмауера, що блокують кінцеві точки ідентифікації Microsoft, можуть імітувати помилку «tenant not found». Якщо ця помилка раптово з’являється, обов’язково уточніть у ІT-відділу, чи не було нещодавних змін у мережі.