Ошибка 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) и связан с личная учетная запись, а также можно выполнять такие действия, как создание учетных записей пользователей в каталоге. Теперь поведение изменилось.

Решение. Создание учетной записи 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 — Multitenant)

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

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

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

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

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

В коде приложения примените это значение 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 MS Graph для проверки даты создания пользователя следующим образом:

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

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

MSOnline PowerShell

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

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

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

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

Когда гостевой пользователь принимает приглашение, атрибут пользователя 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 или API Microsoft Graph. Инструкции см. в разделе "Сброс состояния активации" для гостевого пользователя.

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

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