Как исправить ошибку AADSTS50020: учетная запись пользователя не найдена в клиенте

By Mirko Peters · 2026-04-21

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

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

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

В этом руководстве подробно разобрано, что на самом деле означает AADSTS50020, где она появляется, как быстро её исправить и как предотвратить её в будущем. Мы рассмотрим первопричины, сложные ситуации и пошаговые решения, поэтому независимо от того, управляете ли вы всей организацией или устраняете неполадки как разработчик, вы точно будете знать, как решить эту проблему с идентификацией.

Готовы разобраться в запутанных сообщениях о клиенте и вернуться к работе? Давайте разберём, что происходит на самом деле, чтобы исправить проблему раз и навсегда и, возможно, не допустить её повторного появления!

Что означает ошибка поставщика удостоверений AADSTS50020

Когда вы сталкиваетесь с ошибкой AADSTS50020, Microsoft фактически сообщает: «Извините, такой учетной записи пользователя нет в этом клиенте». Но за этим сухим предупреждением скрывается более сложная техническая картина. Эта ошибка напрямую связана с проблемами поставщика удостоверений в средах Microsoft Entra ID (Azure AD). Простыми словами: служба пытается сопоставить вашу учетную запись входа с конкретным клиентом (каталогом вашей организации), но ничего не находит.

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

С точки зрения Microsoft каждая попытка входа проходит через «поставщика удостоверений», который проверяет, кто вы и к какому клиенту принадлежите. Если вы приходите с неподходящими ключами или с ключами, которых система никогда не видела, вам отказывают в доступе, а код AADSTS50020 означает примерно следующее: «Доступ запрещен: пользователь здесь не найден».

Понимание того, как и почему возникает эта ошибка, поможет вам её диагностировать. В следующих разделах описаны типичные симптомы и наиболее распространенные технические сбои, которые мешают аутентификации в облачных средах 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, потому что этот центр администрирования принимает только организационные (рабочие или учебные) учётные записи.
Неподдерживаемые типы учётных записей в регистрациях приложений: Допустим, приложение настроено как «single tenant», но вы пытаетесь получить к нему доступ с учётной записью из другой организации или с личной учётной записью Microsoft. Такое несоответствие тоже приведёт к этой ошибке.
Смешение мультиарендных и личных учётных записей: Разработчики иногда настраивают приложения так, чтобы они принимали несколько организационных каталогов, но забывают разрешить личные учётные записи, или наоборот. Из-за таких неверных настроек аутентификация не проходит для пользователей, тип учётной записи которых не разрешён.

Проблемы с конечными точками, выбором клиента и приглашениями гостевых пользователей

Использование неверной конечной точки аутентификации: Входы в Microsoft поддерживают несколько конечных точек, например /common, /organizations, /consumers и конечные точки, привязанные к конкретному клиенту. Если вы пытаетесь войти в приложение, привязанное к конкретному клиенту, через конечную точку /common или /consumers с рабочей учётной записью, Azure AD не может сопоставить вашу учётную запись, и возникает ошибка AADSTS50020.
Вход в неверный клиент: Легко по ошибке оказаться в неправильном организационном каталоге, особенно если вы состоите в нескольких. Если вы проходите аутентификацию в клиенте, где вашей учётной записи нет, вы получите эту ошибку. Это классическая ситуация «вы зашли не в ту дверь».
Приглашение гостевого пользователя не отправлено или не принято должным образом: Организации, которые приглашают внешних участников, иногда забывают отправить приглашение или неправильно его настроить. Если гостевая учётная запись не зарегистрирована или не активирована, пользователь невидим для каталога и получает категорический отказ при попытке доступа к приложениям или файлам.
Приложению требуется назначение пользователя, но у вас нет доступа: Некоторые приложения в Microsoft Entra закрыты для определённых пользователей или групп. Если задано «Назначение пользователя обязательно», а вас нет в списке, доступ будет запрещён, и ошибка может выглядеть как AADSTS50020, даже если ваша учётная запись действительна.
Удалённые и заново созданные пользователи: Если пользователь был удалён, а затем создан заново в домашнем клиенте с тем же адресом электронной почты, Azure AD может не распознать «нового» пользователя как тот же объект, особенно в сценариях с несколькими клиентами. Это вполне может привести к нерешённым проблемам со входом и к печально известному коду ошибки.
Ошибки в настройке доменов и DNS: Если организация использует пользовательские домены (для имён субъектов пользователей или регистраций приложений), а эти домены не подтверждены или неправильно настроены в Azure AD, распознавание пользователя может завершиться ошибкой AADSTS50020. Даже ошибки локального DNS или блокировка конечных точек аутентификации могут сломать вход, поэтому инфраструктура имеет значение!
Сбои синхронизации каталогов (гибридная идентификация): В некоторых гибридных корпоративных средах, где учётные записи синхронизируются из локальной AD с помощью таких инструментов, как Azure AD Connect, отсутствующие или не синхронизированные пользователи в целевом клиенте тоже могут вызывать ошибки «учётная запись не найдена». Проверяйте состояние синхронизации всякий раз, когда используется гибридная идентификация.
Теневое ИТ и неуправляемые приложения: Неутверждённые приложения или согласие на доступ сторонних приложений (классическое теневое ИТ) могут создавать конфликтующие пути доступа пользователей и иногда приводить к упорным ошибкам входа. Чтобы разобраться с рисками теневого ИТ, см. это руководство по управлению теневым ИТ внутри клиента M365.

Эффективные решения для ошибок AADSTS50020 «Учётная запись не найдена»

Исправление ошибки AADSTS50020 всегда начинается с точного определения того, где возникает несоответствие: в типе учётной записи, каталоге, конечной точке или разрешениях доступа. Определив первопричину, вы сможете применить конкретное решение для каждого сценария и не допустить повторного появления этой ошибки.

Если проблема связана с личной и рабочей учётной записью, используйте правильный тип входа. Если дело в регистрации приложения, проверьте настройки аудитории входа и измените их так, чтобы поддерживались нужные вам учётные записи (один клиент, несколько клиентов или, при необходимости, личные учётные записи Microsoft). Для гостевых пользователей убедитесь, что приглашения отправлены и приняты: иногда решает всё повторная отправка приглашения.

Не забывайте про назначение пользователей! Если приложение этого требует, назначьте нужных пользователей или группы в Microsoft Entra, чтобы устранить препятствие. Если путаница сохраняется из-за кэша браузера или «липких» сеансов, попробуйте выйти из учётной записи и снова открыть страницу входа в приватном окне или режиме инкогнито. Иногда нужно создать новый каталог или назначить доступ на более высоком уровне, особенно при развёртывании новых клиентов или миграции пользователей.

Полноценные корпоративные решения также предполагают правильно выстроенное управление. Узнайте, как дрейф политик и назначений может создать хаос в крупных средах, и почему регулярные проверки и RBAC так важны, в этом руководстве по стратегии корпоративного управления Azure. Сочетание правильного технического решения и продуманного планирования поможет не допустить появления AADSTS50020 на страницах входа.

Проверенные лучшие практики предотвращения ошибок AADSTS50020

Выберите правильную конечную точку входа: всегда сопоставляйте аудиторию входа приложения (один клиент, несколько клиентов или личные учётные записи) с нужной конечной точкой входа. Несоответствие конечных точек и аудиторий — самый частый источник путаницы.
Внимательно управляйте гостевыми пользователями: не ограничивайтесь приглашением гостей и не забывайте о них. Держите жизненный цикл гостевых пользователей под контролем: регулярные проверки, доступ с ограниченным сроком, чёткое отключение — и так вы сократите поверхность атаки. Рекомендации по этой теме есть в руководстве по управлению гостевыми учётными записями Microsoft 365.
Обеспечьте структурированный доступ и назначения: убедитесь, что приложения, требующие назначения пользователей, настроены с чёткими и актуальными списками того, кто к чему имеет доступ. Не оставляйте назначения без изменений: регулярно пересматривайте и обновляйте их.
Проверяйте и контролируйте разрешения приложений: ограничивайте распространение согласий и теневые ИТ, проверяя регистрации приложений и внешний общий доступ. Для более глубокой защиты идентификации и снижения рисков используйте выводы из этого выпуска о петле условного доступа Entra ID и поддерживайте политики условного доступа понятными и применимыми.
Проверяйте домены и следите за DNS: всегда дважды проверяйте подтверждение пользовательских доменов в Azure AD и следите за локальными правилами DNS или брандмауэра, которые могут блокировать конечные точки входа Microsoft.
Следите за синхронизацией гибридной идентификации: если вы синхронизируете данные из локального AD, следите за проблемами Azure AD Connect и убедитесь, что объекты пользователей синхронизируются со всеми нужными клиентами.

Сводка: причины, симптомы и решения для AADSTS50020

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