Разбираем ошибку 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, понимание того, что эта ошибка почти always означает «Microsoft не может найти нужное место», уже половина успеха. Не паникуйте: обычно проблема в отсутствующем или неверном идентификаторе клиента, удалённом клиенте или сбое в конфигурации. Как только вы поймёте, как работает поиск клиента, вы быстро найдёте место проблемы и исправите её.

Как пошагово исправить ошибку AADSTS90002

Готовы разобраться с ошибкой AADSTS90002? Хорошая новость: большинство решений вам по силам, даже если на первый взгляд всё выглядит сложно. Прежде всего дважды проверьте, что вы входите с правильным идентификатором клиента и используете верный URL для входа. Опечатки, значения, скопированные из старой документации, или путаница между тестовой и рабочей средами — классические причины этой неразберихи.

Далее убедитесь, что клиент действительно существует и активен. Иногда клиенты удаляют, приостанавливают, или подключённая подписка устаревает. Зайдите в центр администрирования Microsoft или попросите это сделать вашего ИT-администратора, проверьте статус клиента, активные подписки и то, действительна ли ваша лицензия. Часто именно здесь и выясняется: «Ах, этот клиент был выведен из эксплуатации в прошлом квартале!»

Если всё равно что-то не так, проверьте конфигурацию приложения. Используете ли вы многоклиентские приложения? Зарегистрировали ли вы их в нужном экземпляре Azure AD? Иногда разработчики жёстко прописывают идентификатор клиента в коде или конфигурационном файле и по ошибке отправляют неверное значение в рабочую среду, особенно в облачных развёртываниях с несколькими средами.

Автоматизации, служебные субъекты и конвейеры CI/CD тоже могут выдавать эту ошибку. Если ваши скрипты или приложения внезапно перестают работать, убедитесь, что учётные данные служебного субъекта не истекли и не были отозваны. Нередко забытое продление или удалённая регистрация приводят к сбоям поиска клиента в неинтерактивных сценариях.

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

Если хотите глубже разобраться в безопасности удостоверений и типичных ошибках, которые осложняют работу с Azure AD, посмотрите это обсуждение: как управлять условным доступом и идентификационным долгом. Эти материалы помогут поддерживать уровень удостоверений в хорошем состоянии и заранее предотвращать такие ошибки, чтобы они не застали вас врасплох.

Начните с основ, действуйте последовательно, и вы обычно справитесь с «Tenant Not Found» ещё до обеда. А если упрётесь в стену, следующий лучший шаг — подключить администратора подписки или службу поддержки.

Часто задаваемые вопросы о проблемах Tenant Not Found и ответы на них

Если вы когда-либо ломали голову над ошибкой AADSTS90002, вы не одиноки. У людей всегда возникают вопросы, особенно когда их клиент «должен» существовать, а Microsoft упорно утверждает обратное. Давайте разберём главные вопросы и опасения, которые связаны с этой печально известной ошибкой.

Первый вопрос: «Почему я вижу „Tenant Not Found“, хотя я точно знаю, что мой клиент существует?» Обычно причина в мелочах: использование устаревшего или написанного с ошибкой доменного имени, несоответствие региона или кэшированные настройки в браузере или приложении. Иногда DNS требуется время, чтобы обновиться после изменений в клиенте. Прежде чем переживать из-за серьёзных проблем, всегда перепроверьте данные для входа и попробуйте очистить кэш или сбросить DNS.

Ещё один распространённый вопрос: «Могу ли я восстановить доступ, если я не администратор?» Как правило, у пользователей без прав администратора возможности ограничены. Если клиент был удалён или подписка истекла, вернуть его к жизни может только администратор с соответствующими правами. Тем не менее, если вы заблокированы из-за мелких проблем, например неверных URL или устаревших служебных объектов-участников (service principal), вы можете попросить администратора или исправить конфигурацию, не дожидаясь помощи на верхнем уровне.

Администраторы часто хотят знать, можно ли предотвратить такие ошибки. Безусловно, можно: правильная проверка идентификатора клиента (tenant ID), тщательное документирование настроек приложений и тестирование входа в изолированных средах существенно помогают. Разработчикам стоит учитывать передовые практики, например использовать переменные окружения для конфигурации и проверять ссылки на клиент при развёртывании, а не только в продуктивной среде.

Для тех, кто автоматизирует процессы или работает с CI/CD, распространёнными причинами являются истёкшие клиентские секреты или отозванные права служебных объектов-участников. Выработайте привычку регулярно проверять service principal, продлевать учётные данные до истечения срока и вести журналы, чтобы быстро обнаруживать сбои при определении клиента.

Не забывайте и о сетевых проблемах. Сбои DNS и прокси, а также жёсткие правила брандмауэра, блокирующие конечные точки идентификации Microsoft, могут имитировать ошибку «tenant not found». Если эта ошибка внезапно начала появляться, обязательно уточните у ИT-отдела, не было ли недавних изменений в сети.