Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

ADFS + OpenID Connect email claim and external ADFS

I'm having difficulties setting up ADFS with OpenID Connect on Windows Server 2016.

I've setup AD for testing and I can successfully authenticate, however the email claim is not in the id token.

Additionally I've setup an external ADFS in the Claims Provider trust. It is displayed as an option, however upon logging in I get the error:

    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.

Anybody have suggestions on how to fix this?

like image 763
LeoTietz Avatar asked Dec 15 '22 08:12

LeoTietz


1 Answers

The root cause of MSIS9642 is that the new OpenID Connect Application Group features in ADFS 2016 need to issue an access token to your application. This token must include the users identity. In order to issue the token the subsystem must understand which claim in the inbound claims is used to uniquely identify the user.

A new property called AnchorClaimType has been added to the Claim Provider Trust model.

When ADFS is first installed it registers a built in Claim Provider Trust for AD AUTHORITY and sets the value for AnchorClaimType to

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

You can see this by using the powershell command get-adfsclaimsprovidertrust.

This is why OpenID works for when authenticating against Active Directory.

When you create a new Claim Provider Trust the system does not set an AnchorClaimType. The OpenID system can't issue a token because it does not know which inbound claim constitutes the unique user identity. This is why OpenID does not work when authenticating against an external Claim Provider trust.

In order to resolve this problem you need to take a few actions:

a) Verify that you are running Windows Server 2016 RTM Unfortunately the powershell attribute to set AnchorClaimType does not exist in the CTP, and the property cannot be set using the UI.

b) Choose a claim from the inbound token that represents the users identity and identify the claim type. In our case we were federating with an Azure Active Directory and chose name, and the type is foo://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

c) Set the AnchorTypeClaim for the Claim Provider Trust to the type selected by using powershell

set-adfsclaimsprovidertrust -targetidentifier identifier -AnchorClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

(get identifier from powershell get-adfsclaimsprovidertrust)

d) Create at least one inbound rule that passes through the value for the primary input claim, in our case Name

Hope this helps

like image 117
Chuck Duffy Avatar answered Feb 13 '23 07:02

Chuck Duffy