This is for Server 2016 (ADFS 4.0).
The full error is:
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.
You only get this error if you are using OpenID Connect with ADAL configured via Application Groups.
Our setup is:
User --> application --> external ADFS A --> internal ADFS B via HRD
We had used this model no problem with OWIN OIDC applications authenticating on both the internal and external ADFS.
However, on the applications that used ADAL, external authentication worked fine but trying the internal one threw the above error.
ADFS A is set up as a CP to ADFS B.
There's a good write-up here.
"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."
Note that this property is not available on a RP trust.
The PowerShell needs to be run on the CP server i.e. ADFS A.
(Get-AdfsClaimsProviderTrust -Name "CP name").anchorclaimtype
This will be blank the first time. You can use any attribute that makes sense to uniquely identify the user. Typically, this would be sAMAccountName or UPN.
In our case, we had a custom claim so the command was:
Set-AdfsClaimsProviderTrust -TargetName "CP Trust" -AnchorClaimType "http://company/claims
/sAMAccountname"
and you can check this is correct by running the above Get-AdfsClaimsProviderTrust command again.
Remember that you need to pass-through this claim in the CP claims rules and the RP claims rules.
Enjoy!
1 comment:
I work at Microsoft. My customer had this same error. This is how we fixed it. We used Claims x-ray. We had them do a login with an identity from Active Directory and then do a login with an identity that uses an external claims provider trust.
When we compared the Claims X-Ray output, the value for anchorclaimtype didn't look right on the claims provider trust test login. We made a change in the claims provider to issue http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress as the anchor claim type and it resolve the problem.
v-michall@microsoft.com
Post a Comment