5

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?

LeoTietz
  • 329
  • 4
  • 13

3 Answers3

14

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

Chuck Duffy
  • 279
  • 3
  • 6
  • I had to use foo:// instead of http:// as content was being interpreted as links... – Chuck Duffy Oct 14 '16 at 16:30
  • I know this is an old thread, but is it necessary to make any configuration in the external ADFS? I tried many AnchorClaimType and all return the same error. However, Im able to get a token (without any user info). I also created a custom rule for both the application group and for the Claims Provider Trust that Passes through all claims: c:[] => issue(claim = c); – user3643038 Aug 10 '20 at 01:02
0

To solve the problem with the missing AnchorClaimType parameter for additional added Claim Provider Trusts (CPT) a workaround for Windows Server 2016 TP5 (until end of support) can be used.

Workaround:

  1. If CPT is already existing, delete the CPT.
  2. Use the powershell command Add-AdfsClaimsProviderTrust
    • Either parameter wise (see Technet Description)
    • Or using a Metadata URL + the Parameter -AnchorClaimType "yourAnchorClaimValue".
  3. Create at least one inbound rule that passes through the value for the primary input claim

In my case the following PS command solved the problem:

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

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 resolved the problem.

v-michall@microsoft.com

Michael Hall
  • 21
  • 2