ADFS + OpenID Connect по электронной почте претензии и внешние ADFS

Question

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

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

Кроме того, я настроил внешнюю 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. 

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

Answer 1

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

Новое свойство под названием AnchorClaimType было добавлено в модель доверия провайдера.

Когда ADFS сначала установлен, он регистрирует встроенный в претензии поставщика траста AD ВЛАСТИ и устанавливает значение для AnchorClaimType в

Foo: //schemas.microsoft.com/ws/2008/06/identity/претензии/windowsaccountname

Вы можете увидеть это с помощью команды Powershell получить-adfsclaimsprovidertrust.

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

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

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

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

b) Выберите заявку от входящего токена, который представляет идентификатор пользователя и идентифицирует тип претензии. В нашем случае мы объединились с Azure Active Directory и выбрали имя, а тип - foo: //schemas.xmlsoap.орг/WS/2005/05/идентичность/претензии/имя

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

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

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

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

Надеется, что это помогает

Answer 2

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

Обход:

1. Если CPT уже существует, удалите CPT.
2. Используйте команду PowerShell Add-AdfsClaimsProviderTrust
   • Либо параметр мудрое (см Technet Description)
   • Или, используя URL-адрес метаданных + параметр -AnchorClaimType "yourAnchorClaimValue".
3. Создать по крайней мере одно правило входящего трафика, который проходит через значение для утверждения первичного ввода

В моем случае следующая команда PS решить эту проблему:

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