Ошибка AADSTS50020. Учетная запись пользователя от поставщика удостоверений не существует у арендатора.

2025-04-17

Эта статья поможет устранить неполадки с кодом ошибки AADSTS50020, который возвращается, если гостевой пользователь из поставщика удостоверений (IdP) не может войти в арендатор ресурсов в Microsoft Entra ID.

Симптомы

Когда гостевой пользователь пытается получить доступ к приложению или ресурсу в клиенте ресурса, вход завершается ошибкой, и отображается следующее сообщение об ошибке:

AADSTS50020: учетная запись пользователя "user@domain.com" от поставщика удостоверений {IdentityProviderURL} отсутствует у арендатора {ResourceTenantName}.

Когда администратор проверяет журналы входа на домашнем арендаторе, запись с кодом ошибки 90072 указывает на сбой входа. Сообщение об ошибке гласит:

Учетная запись пользователя {email} от поставщика удостоверений {idp} не существует в клиенте {tenant} и не может получить доступ к приложению {appId}({appName}) в этом клиенте. Сначала эту учетную запись необходимо добавить в качестве внешнего пользователя в арендаторе. Выйдите и войдите еще раз с помощью другой учетной записи пользователя Microsoft Entra.

Причина 1: Пользователи входят в центр администрирования Microsoft Entra, используя личные учетные записи Microsoft.

При попытке войти в Центр администрирования Microsoft Entra с помощью личных учетных записей Майкрософт (Outlook, Hotmail или OneDrive) вы подключаетесь к клиенту Служб Майкрософт по умолчанию. В учетной записи по умолчанию нет связанного каталога для выполнения каких-либо действий. Это поведение является ожидаемым.

В предыдущем опыте создается директория (например: UserNamehotmail735.onmicrosoft.com) и связана с личной учетной записью, что позволяет выполнять такие действия, как создание учетных записей пользователей в директории. Теперь поведение изменилось.

Решение. Создание учетной записи Azure с новым клиентом

Если вы хотите иметь каталог, необходимо создать учетную запись Azure и новый тенант.

Перейдите в https://azure.microsoft.com/en-us/free/раздел , а затем нажмите кнопку "Пуск бесплатно ".
Следуйте инструкциям по созданию учетной записи Azure.
Клиент будет создан вместе с учетной записью Azure, и вы автоматически будете назначены глобальным администратором. Это обеспечивает полный доступ ко всем параметрам в этом арендаторе.

Причина 2. Используется неподдерживаемый тип учетной записи (мультитенантные и личная учетная запись)

Если для регистрации приложения установлен тип учетной записи «один клиент», пользователи из других каталогов или поставщиков удостоверений не могут войти в данное приложение.

Чтобы убедиться, что регистрация приложения не является типом учетной записи одного клиента, выполните следующие действия.

На портале Azure найдите и выберите Регистрация приложений.
Выберите имя регистрации приложения.
На боковой панели выберите Манифест.
В коде JSON найдите параметр signInAudience .
Проверьте, содержит ли параметр одно из следующих значений:
- Azure AD и Личная учетная запись Microsoft
- AzureADMultipleOrgs
- ЛичнаяУчетнаяЗаписьMicrosoft
Если параметр signInAudience не содержит одно из этих значений, повторно создайте регистрацию приложения, выбрав правильный тип учетной записи. В настоящее время невозможно изменить signInAudience в манифесте.

Для получения дополнительной информации о том, как зарегистрировать приложения, см. Краткое руководство: Регистрация приложения на платформе удостоверений Microsoft.

Причина 3. Используется неправильная конечная точка (личные и учетные записи организации)

Вызов проверки подлинности должен указывать URL-адрес, соответствующий выбранному выбору, если для поддерживаемого типа учетной записи регистрации приложения задано одно из следующих значений:

Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — Multitenant)
Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — Multitenant) и личных учетных записей Майкрософт (например, Skype, Xbox)
Только личные учетные записи Майкрософт

При использовании https://login.microsoftonline.com/<YourTenantNameOrID>пользователи из других организаций не могут получить доступ к приложению. Необходимо добавить этих пользователей в качестве гостей арендатору, указанному в запросе. В этом случае ожидается, что проверка подлинности выполняется только на вашем арендаторе. Этот сценарий приводит к ошибке входа, если вы ожидаете, что пользователи войдут с помощью федерации с другим клиентом или поставщиком удостоверений.

Используйте соответствующий URL-адрес входа для определенного типа приложения, как показано в следующей таблице:

Тип приложения	URL-адрес входа
Мультитенантные приложения	`https://login.microsoftonline.com/organizations`
Мультитенантные и личные учетные записи	`https://login.microsoftonline.com/common`
Только личные учетные записи	`https://login.microsoftonline.com/consumers`

В коде приложения примените это значение URL-адреса в параметре Authority . Для получения дополнительной информации о Authorityсм. раздел параметры конфигурации приложений платформы идентификации Microsoft.

Причина 4. Вход в неправильного арендатора

Когда пользователи пытаются получить доступ к вашему приложению, либо они переходят по прямой ссылке на приложение, либо пытаются получить доступ через https://myapps.microsoft.com. В любой ситуации пользователи перенаправляются для входа в приложение. В некоторых случаях у пользователя может уже быть активный сеанс, использующий другой личная учетная запись, отличный от используемого. Или у них есть сеанс, использующий учетную запись их организации, хотя они хотели использовать личную гостевую учетную запись, или наоборот.

Чтобы убедиться, что этот сценарий является проблемой, найдите User account и Identity provider значения в сообщении об ошибке. Совпадают ли эти значения с ожидаемым сочетанием или нет? Например, пользователь выполнил вход с помощью учетной записи организации для вашего клиента вместо своего домашнего клиента? Или пользователь вошёл в live.com поставщика удостоверений, используя другую личную учетную запись, чем та, которая уже была приглашена?

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

Причина 5. Гостевой пользователь не был приглашен

Гостевой пользователь, который пытался войти в систему, не был приглашен к арендатору.

Решение. Приглашение гостевого пользователя

Убедитесь, что вы выполните действия, описанные в «Краткое руководство: добавление гостевых пользователей в каталог на портале Azure», чтобы пригласить гостевых пользователей.

Причина 6. Приложению требуется назначение пользователя

Если приложение является корпоративным приложением, требующим назначения пользователей, возникает ошибка AADSTS50020 , если пользователь не входит в список разрешенных пользователей, которым назначен доступ к приложению. Чтобы проверить, требуется ли вашему корпоративному приложению назначение пользователей:

В портал Azure найдите и выберите корпоративные приложения.
Выберите корпоративное приложение.
На боковой панели выберите "Свойства".
Убедитесь, что для параметра "Назначение" задано значение "Да".

Решение. Назначение доступа пользователям по отдельности или в составе группы

Используйте один из следующих параметров для назначения доступа пользователям:

Чтобы отдельно назначить пользователю доступ к приложению, см. статью "Назначение учетной записи пользователя корпоративному приложению".
Чтобы назначить пользователей, если они член назначенной группы или динамической группы, см. статью "Управление доступом к приложению".

Причина 7. Попытка использовать поток передачи учетных данных владельца ресурсов для личных учетных записей

Если пользователь пытается использовать процесс учетных данных владельца ресурса (ROPC) для личных учетных записей, возникает ошибка AADSTS50020. Платформа удостоверений Microsoft поддерживает ROPC только в арендаторах Microsoft Entra, а не в личных учетных записях.

Решение: Использование конечной точки, относящейся к арендатору или организации

Используйте конечную точку для конкретного клиента (https://login.microsoftonline.com/<TenantIDOrName>) или конечную точку организации. Личные учетные записи, приглашенные в клиент Microsoft Entra, не могут использовать функциональность ROPC. Для получения дополнительной информации см. платформа удостоверений Microsoft и учетные данные владельца ресурса OAuth 2.0.

Причина 8. Ранее удаленное имя пользователя было повторно создано администратором домашнего клиента

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

Проверка. Проверьте, старше ли гостевой пользователь клиента ресурса, чем учетная запись пользователя домашнего клиента.

Чтобы проверить дату создания учетной записи пользователя-гостя, можно использовать Microsoft Graph, Microsoft Entra PowerShell или Microsoft Graph PowerShell SDK.

Microsoft Graph

Выполните запрос к API MS Graph для проверки даты создания пользователя следующим образом:

GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime

Затем проверьте дату создания гостевого пользователя в клиенте ресурсов в отношении даты создания учетной записи пользователя в домашнем клиенте. Сценарий подтверждается, если гостевой пользователь был создан до создания учетной записи пользователя основного клиента.

Microsoft Entra PowerShell

Выполните командлет PowerShell Get-EntraUser, чтобы просмотреть дату создания пользователя, как показано ниже:

Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime

Microsoft Graph PowerShell SDK

Выполните командлет Get-MgUser PowerShell, чтобы просмотреть дату создания пользователя следующим образом:

$p = @('Id', 'UserPrincipalName', 'CreatedDateTime')
Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p

Решение. Сброс состояния активации учетной записи гостевого пользователя

Сброс состояния активации гостевой учетной записи пользователя в клиенте ресурса. Затем можно сохранить гостевой объект пользователя, не удаляя и снова создав гостевую учетную запись. Вы можете сбросить состояние активации с помощью портала Azure, Azure PowerShell или Microsoft Graph API. Инструкции см. в разделе "Сброс состояния активации" для гостевого пользователя.

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.