В этой статье мы обсудим возможные исправления для решения проблемы. AADTS50020, учетная запись пользователя от поставщика удостоверений не существует в клиенте ошибка. Эта ошибка обычно возникает, когда гостевой пользователь от поставщика удостоверений (IdP) не может войти в клиент ресурса в Azure Active Directory (Azure AD). Вы можете увидеть эту ошибку в разных ситуациях. Каждая ситуация требует своего способа устранения неполадок.
Полное сообщение об ошибке, которое видит гостевой пользователь при попытке доступа к приложению или ресурсу в арендаторе ресурса:
AADTS50020: Учетная запись пользователя ‘ [электронная почта защищена] ’ от поставщика удостоверений {IdentityProviderURL} не существует в клиенте {ResourceTenantName}.
При просмотре журналов домашнего арендатора администратор увидит следующее сообщение об ошибке:
Учетная запись пользователя {email} от поставщика удостоверений {idp} не существует в клиенте {tenant} и не может получить доступ к приложению {appId}({appName}) в этом клиенте. Сначала учетную запись необходимо добавить в качестве внешнего пользователя в клиенте. Выйдите из системы и войдите снова, используя другую учетную запись пользователя Azure Active Directory.
AADTS50020, учетная запись пользователя от поставщика удостоверений не существует в клиенте.
Приведенные ниже решения помогут вам исправить AADTS50020, учетная запись пользователя от поставщика удостоверений не существует в клиенте ошибка.
- Измените настройку аудитории для входа в манифест регистрации приложения.
- Используйте правильный URL-адрес для входа
- Выйдите из системы, а затем снова войдите в систему из другого браузера или приватного сеанса браузера.
- Пригласить гостя
- Назначьте доступ пользователям (если применимо)
- Используйте конечную точку, специфичную для арендатора или организации.
- Сброс статуса активации гостевой учетной записи
Давайте рассмотрим все эти исправления подробно.
1] Измените настройку аудитории для входа в манифест регистрации приложения.
Одной из возможных причин этой ошибки является использование арендатором неподдерживаемого типа учетной записи. Например, если для регистрации вашего приложения установлен тип учетной записи с одним клиентом, пользователь другого идентифицированного поставщика не сможет войти в приложение.
Чтобы исправить ошибку AADTS50020 , измените настройку аудитории входа в манифесте регистрации приложения следующим образом:
- Перейти к Портал Azure .
- Выбирать Регистрация приложений .
- Выберите имя регистрации вашего приложения.
- Выбирать Манифест , с боковой панели.
- в JSON-код , найдите настройку SignInAudience.
- Проверьте настройку по одному из следующих значений:
- AzureADandPersonalMicrosoftAccount
- AzureADMultipleOrgs
- ЛичныйMicrosoftAccount
SignInAudience должен содержать одно из вышеупомянутых значений. Если вы не найдете ни одного из этих значений в настройке SignInAudience, вам придется заново создать регистрацию приложения.
готовые окна 10
2] Используйте правильный URL-адрес для входа.
Другая причина этой ошибки — использование неправильного URL-адреса для входа. Например, если вы используете https://login.Microsoftonline.com/<YourTenantNameOrID> URL-адрес, ожидается, что проверка подлинности будет выполняться только в вашем клиенте. Именно поэтому пользователи в других организациях не могут получить доступ к приложению. Когда другие пользователи попытаются это сделать, они получат сообщение об ошибке входа.
Чтобы решить эту проблему, необходимо добавить этих пользователей в качестве гостей в арендаторе, указанном в запросе. Вы можете использовать соответствующий URL-адрес для входа для определенного типа приложения. Некоторые примеры упомянуты ниже:
Для типа мультитенантных приложений вы можете использовать следующий URL-адрес для входа.
https://login.microsoftonline.com/organizations
Если вы используете мультитенантный и личный тип учетных записей, вы можете использовать следующий URL-адрес для входа.
https://login.microsoftonline.com/common
Используйте этот URL-адрес для входа только для личных учетных записей.
https://login.microsoftonline.com/consumers
3] Выйдите из системы, затем снова войдите в систему из другого браузера или в приватном сеансе браузера.
Иногда эта ошибка возникает, когда пользователь вошел в неправильный клиент. Например, когда у пользователя уже есть активный сеанс в своем веб-браузере, и он/она пытается получить доступ к вашему приложению, щелкнув соответствующую ссылку или введя необходимый URL-адрес в новой вкладке.
В этой ситуации попросите гостевого пользователя выполнить одно из следующих действий:
- Выйдите из учетной записи, уже открытой в его/ее веб-браузере. Это завершит уже активный сеанс. Теперь он/она может войти в систему, используя правильную ссылку и учетные данные.
- Войдите в систему, используя другой веб-браузер.
- Войдите в систему в окне «Частный» или «Инкогнито» в том же веб-браузере.
4] Пригласить гостя.
Эта ошибка также появляется, когда гостевой пользователь не приглашен. Решение этой ситуации простое. Пригласите гостя.
5] Назначьте доступ пользователям (если применимо)
Если ваше приложение является корпоративным приложением, требующим назначения пользователя, и пользователь не находится в списке разрешенных пользователей, которым назначен доступ к приложению, возникнет эта ошибка.
Вы можете проверить, требует ли ваше корпоративное приложение назначения пользователя или нет, выполнив действия, указанные ниже:
- Перейдите на портал Azure.
- Выберите Корпоративные приложения .
- Выберите свое корпоративное приложение.
- Выбирать Характеристики .
- Проверьте, Требуется назначение опция установлена на Да . Если для него установлено значение «Да», то это приложение требует назначения пользователя.
В этой ситуации назначьте доступ пользователям индивидуально или в составе группы.
6] Используйте конечную точку, специфичную для арендатора или организации.
Код ошибки ААДСТС50020 Это также может произойти, когда пользователь пытается использовать поток учетных данных пароля владельца ресурса (ROPC) для своих личных учетных записей. Платформа Microsoft Identity Platform поддерживает ROPC только в клиентах Azure AD, но не в личных учетных записях.
В этой ситуации пользователю необходимо использовать конечную точку, специфичную для арендатора или организации. Обратите внимание, что личные учетные записи не могут использовать ROPC, даже если они приглашены в клиент Azure AD.
7] Сброс статуса активации гостевой учетной записи.
Если администратор удалил имя гостевого пользователя в клиенте ресурса и заново создал его в домашнем клиенте, гостевой пользователь столкнется с этой ошибкой. Администратору также следует убедиться, что учетная запись гостя в арендаторе ресурса не связана с учетной записью гостя в домашнем арендаторе.
Чтобы исправить ошибку в этой ситуации, сбросьте статус погашения гостевой учетной записи пользователя в арендаторе ресурса.
Вот и все. Надеюсь, это поможет.
Какой идентификатор клиента используется в Azure?
Идентификатор клиента в Azure — это уникальный идентификатор клиента Azure Active Directory (Azure AD). Его также называют идентификатором клиента Office 365. Существуют разные способы получить идентификатор клиента Azure.
Кто такой администратор арендатора?
Администратор клиента — это пользователь, имеющий самый высокий уровень разрешений в клиенте Azure Active Directory (Azure AD). Он/она может управлять всеми аспектами клиента, включая пользователей, группы, разрешения и настройки.
Читать дальше : Ошибка AADTS90100. Параметр входа пуст или недействителен. .
