Share via

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

  • Статья

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

Симптомы

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

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

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

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

Причина 1. Пользователи входят в Центр администрирования Microsoft Entra с помощью личных учетных записей Майкрософт

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

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

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

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

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

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

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

Решение. Изменение параметра аудитории входа в манифесте регистрации приложения

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

  1. В портал Azure найдите и выберите Регистрация приложений.

  2. Выберите имя регистрации приложения.

  3. На боковой панели выберите Манифест.

  4. В коде JSON найдите параметр signInAudience .

  5. Проверьте, содержит ли параметр одно из следующих значений:

    • AzureADandPersonalMicrosoftAccount
    • AzureADMultipleOrgs
    • PersonalMicrosoftAccount

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

Дополнительные сведения о регистрации приложений см. в разделе Краткое руководство. Регистрация приложения с помощью платформа удостоверений Майкрософт.

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

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

  • Учетные записи в любом каталоге организации (любой каталог Microsoft Entra — мультитенантный)

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

  • Только личные учетные записи Майкрософт

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

Решение. Используйте правильный URL-адрес для входа.

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

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

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

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

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

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

Решение. Выйдите, а затем снова войдите из другого браузера или сеанса частного браузера.

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

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

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

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

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

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

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

  1. В портал Azure найдите и выберите Корпоративные приложения.

  2. Выберите корпоративное приложение.

  3. На боковой панели выберите Свойства.

  4. Проверьте, задано ли для параметра Обязательное назначение значение Да.

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

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

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

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

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

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

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

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

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

Первый вариант проверки включает сравнение возраста гостевого пользователя клиента ресурса с учетной записью пользователя домашнего клиента. Эту проверку можно выполнить с помощью Microsoft Graph или MSOnline PowerShell.

Microsoft Graph

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

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

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

MSOnline PowerShell

Примечание.

Модуль PowerShell MSOnline настроен как нерекомендуемый. Так как она также несовместима с PowerShell Core, убедитесь, что вы используете совместимую версию PowerShell, чтобы можно было выполнить следующие команды.

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

Get-MsolUser -SearchString user@contoso.com | Format-List whenCreated

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

Примечание.

модули PowerShell Azure AD и MSOnline устарели с 30 марта 2024 г. Дополнительные сведения см. в статье Обновление для прекращения поддержки. После этой даты поддержка этих модулей ограничивается поддержкой миграции пакета SDK Для Microsoft Graph PowerShell и исправлениями безопасности. Устаревшие модули будут работать до 30 марта 2025 г.

Мы рекомендуем выполнить миграцию в Microsoft Graph PowerShell для взаимодействия с Microsoft Entra ID (ранее Azure AD). Распространенные вопросы о миграции см. в разделе Вопросы и ответы о миграции. Примечание: В версиях 1.0.x MSOnline может возникнуть сбой после 30 июня 2024 г.

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

Примечание.

Модуль PowerShell MSOnline настроен как нерекомендуемый. Так как она также несовместима с PowerShell Core, убедитесь, что вы используете совместимую версию PowerShell, чтобы можно было выполнить следующие команды.

Когда гостевой пользователь принимает приглашение, атрибут пользователя LiveID (уникальный идентификатор входа пользователя) сохраняется в AlternativeSecurityIds атрибуте key . Так как учетная запись пользователя была удалена и создана в домашнем NetID клиенте, значение учетной записи изменится для пользователя в домашнем клиенте. NetID Сравните значение учетной записи пользователя в домашнем клиенте со значением ключа, которое хранится в AlternativeSecurityIds гостевой учетной записи в клиенте ресурса, следующим образом:

  1. В домашнем клиенте получите значение атрибута LiveID с помощью командлета Get-MsolUser PowerShell:

    Get-MsolUser -SearchString tuser1 | Select-Object -ExpandProperty LiveID

  2. В клиенте ресурса преобразуйте значение атрибута key в AlternativeSecurityIds строку в кодировке Base64:

    [convert]::ToBase64String((Get-MsolUser -ObjectId 01234567-89ab-cdef-0123-456789abcdef
       ).AlternativeSecurityIds.key)

  3. Преобразуйте строку в кодировке base64 в шестнадцатеричное значение с помощью интерактивного преобразователя (например , base64.guru).

  4. Сравните значения из шагов 1 и 3, чтобы убедиться, что они отличаются. Учетная NetID запись пользователя в домашнем клиенте изменилась при удалении и повторном создании учетной записи.

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

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

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

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