Заявка на электронную почту ADFS + OpenID Connect и внешние ADFS

У меня возникают трудности с настройкой ADFS с OpenID Connect на Windows Server 2016.

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

Кроме того, я установил внешний ADFS в доверии поставщика утверждений. Он отображается как опция, однако при входе в систему я получаю сообщение об ошибке:

    MSIS9642: The request cannot be completed because an id token is required but the server was unable to construct an id token for the current user.

У кого-нибудь есть предложения, как это исправить?


openid-connect active-directory adfs windows-server-2016
person LeoTietz    schedule 09.02.2016    source источник

Ответы (2)


arrow_upward
10
arrow_downward

Основная причина MSIS9642 заключается в том, что новые функции группы приложений OpenID Connect в ADFS 2016 должны выдавать токен доступа для вашего приложения. Этот токен должен включать удостоверение пользователя. Чтобы выдать токен, подсистема должна понимать, какое утверждение в входящих утверждениях используется для однозначной идентификации пользователя.

В модель доверия поставщика утверждений добавлено новое свойство AnchorClaimType.

При первой установке ADFS он регистрирует встроенное доверие поставщика утверждений для AD AUTHORITY и устанавливает значение AnchorClaimType на

foo: //schemas.microsoft.com/ws/2008/06/identity/claims/ windowsaccountname

В этом можно убедиться, используя команду PowerShell get-adfsclaimsprovidertrust.

Вот почему OpenID работает при аутентификации в Active Directory.

Когда вы создаете новое доверие поставщика утверждений, система не устанавливает AnchorClaimType. Система OpenID не может выдать токен, потому что она не знает, какое входящее утверждение составляет уникальный идентификатор пользователя. Вот почему OpenID не работает при аутентификации через доверие внешнего поставщика утверждений.

Чтобы решить эту проблему, вам необходимо предпринять несколько действий:

a) Убедитесь, что вы используете Windows Server 2016 RTM. К сожалению, атрибут powershell для установки AnchorClaimType не существует в CTP, и свойство не может быть установлено с помощью пользовательского интерфейса.

б) Выберите утверждение из входящего токена, представляющее личность пользователя, и определите тип утверждения. В нашем случае мы объединялись с Azure Active Directory и выбрали имя, а тип - foo: //schemas.xmlsoap.org/ws/2005/05/identity/claims/ name

c) Установите AnchorTypeClaim для отношения доверия поставщика утверждений к типу, выбранному с помощью PowerShell.

set-adfsclaimsprovidertrust -targetidentifier идентификатор -AnchorClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ имя

(получить идентификатор из PowerShell get-adfsclaimsprovidertrust)

d) Создайте по крайней мере одно входящее правило, которое передает значение для первичного входного утверждения, в нашем случае Name

Надеюсь это поможет

person Chuck Duffy    schedule 14.10.2016
comment
Мне пришлось использовать foo: // вместо http: //, поскольку контент интерпретировался как ссылки ... - person Chuck Duffy; 14.10.2016
comment
Я знаю, что это старый поток, но нужно ли настраивать внешний ADFS? Я пробовал много AnchorClaimType, и все они возвращают одну и ту же ошибку. Однако я могу получить токен (без какой-либо информации о пользователе). Я также создал настраиваемое правило как для группы приложений, так и для доверия поставщика утверждений, которое проходит через все утверждения: c: [] = ›проблема (заявка = c); - person user3643038; 10.08.2020

arrow_upward
0
arrow_downward

Чтобы решить проблему с отсутствующим параметром AnchorClaimType для дополнительных добавленных доверительных отношений поставщика утверждений (CPT), можно использовать обходной путь для Windows Server 2016 TP5 (до окончания поддержки).

Временное решение:

  1. Если CPT уже существует, удалите CPT.
  2. Use the powershell command Add-AdfsClaimsProviderTrust
    • Either parameter wise (see Technet Description)
    • Или используйте URL-адрес метаданных + параметр -AnchorClaimType «yourAnchorClaimValue».
  3. Создайте хотя бы одно входящее правило, которое передает значение для первичного входного утверждения.

В моем случае проблема была решена следующей командой PS:

[String]$ClaimProviderTrustName = "YourCPTName"
[String]$MetaDataURL = "https://..."
[String]$AnchorClaimType = "YourAnchorClaimValue"
Add-AdfsClaimsProviderTrust -Name $ClaimProviderTrustName -MetadataUrl $MetaDataURL -AnchorClaimType $AnchorClaimType
person PatrickW    schedule 23.11.2016