In Part 1, we reviewed my configuration, updated the certificates, and added the “Claims Provider Trusts” within each ADFS Server. In this post, we’ll configure the “Claims” for each trust, ready for testing authentication.

Before, we do this, though we need to configure a “Relying Party Trust.” It is an application that ADFS is protecting, such as SharePoint. For now, we’ll use the Cloud ADFS Testing application provided by Microsoft. The application is called “Claims X-Ray” and is available here:

https://adfshelp.microsoft.com/ClaimsXray/TokenRequest

To configure this, first, navigate to the URL above and then follow the steps. For my environment and testing, I’ll add this to “ADFS 001.“

To create the Claims X-Ray Relying Party, PowerShell is required.

$authzRules = “=>issue(Type = `”http://schemas.microsoft.com/authorization/claims/permit`”, Value = `”true`”); “

$issuanceRules = “@RuleName = `”Issue all claims`”`nx:[]=>issue(claim = x); “

$redirectUrl = “https://adfshelp.microsoft.com/ClaimsXray/TokenResponse”

$samlEndpoint = New-AdfsSamlEndpoint -Binding POST -Protocol SAMLAssertionConsumer -Uri $redirectUrl

Add-ADFSRelyingPartyTrust -Name “ClaimsXray” -Identifier “urn:microsoft:adfs:claimsxray” -IssuanceAuthorizationRules $authzRules -IssuanceTransformRules $issuanceRules -WSFedEndpoint $redirectUrl -SamlEndpoint $samlEndpoint

After execution, clicking into “Relying Party Trusts” displays the “Claims Xray” application.

On the ADFS Server, navigate to the same URL above if you have not yet.

  • Click “Next“
  • Enter the “ADFS URL“
  • Leave all other settings as default
  • Click “Test Connection“
  • When prompted, click “Active Directory.“, do not click any of the “Claims Provider Trusts.“

If successful, you are redirected to https://adfshelp.microsoft.com/ClaimsXray/TokenResponse, which displays the claims sent from the local Active Directory.

If you navigate directly to the IDP Sign on-page, you can either select “Sign in to this site” or “Sign in to one of the following sites,” allowing you to pick “Claims Xray.“

For now, do not repeat this process on any other ADFS Server. We will use this ADFS Farm, as the primary one for the “Relying Party.”

  • Within the primary ADFS Server, within “AD FS Management,” click “Claims Provider Trusts.”
  • Right-click first one added, for me, it is “ADFS 002.“
  • Click “Edit Claim Rules“
  • Click “Add Rule“
  • From the drop-down, select “Pass Through or Filter an Incoming Claim.“
  • Click “Next“
  • Set the “Claim Rule Name” to “Active Directory Pass-through“
  • Set the “Incoming Claim Type” to “E-Mail Address“
  • Select “Pass through all claim values.“

Do not repeat this on each ADFS Farm. For the logic to work, each ADFS Farm needs a “Relying Party Trusts” defined that map to the designated primary ADFS Farm.

  • On each ADFS Farm, except the primary one (ADFS 001), we need to add “Relying Party Trusts.“
  • Launch “AD FS Management“
  • Click “Relying Party Trusts“
  • Either right-click and choose “Add Relying Party Trust” or click the link on the right navigation for the same
  • Select “Claims Aware“
  • Click “Start“
  • Paste in the Federation Metadata XML for the specific ADFS Farm
  • Click “Next“
  • Set the name as before “ADFS XXX.“
  • Click “Next“
  • Set the access policy as required, choose the default value “Permit Everyone.“
  • Click “Next“
  • Click “Next“
  • Uncheck the “Configure claims issuance policy for this application.“
  • Click “Close“

Repeat for all the ADFS Farms, excluding the one being configured. Once completed, three should be listed:

Next, each “Relying Party Trust” required claims mappings to pass-through to the application being accessed.

  • Right-click on the ADFS Farm (“ADFS XXX“)
  • Click “Edit Claim Issuance Policy“
  • Click “Add Rule“
  • From the drop-down, select “Pass Through or Filter an Incoming Claim.“
  • Click “Next“
  • Set the “Claim Rule Name” to “Active Directory Pass-through“
  • Set the “Incoming Claim Type” to “E-Mail Address“
  • Select “Pass through all claim values.“

Repeat this process for each ADFS Farm “Relying Party Trust.“

What you end up with is the following table:

ADFS FARM RELYING PARTY TRUST CLAIMS PROVIDER TRUST
ADFS 001 Claims X-Ray ADFS 002 ADFS 003 ADFS 004
ADFS 002 ADFS 001 ADFS 003 ADFS 004 ADFS 001 ADFS 003 ADFS 004
ADFS 003 ADFS 001 ADFS 002 ADFS 004 ADFS 001 ADFS 002 ADFS 004
ADFS 004 ADFS 001 ADFS 002 ADFS 003 ADFS 001 ADFS 002 ADFS 003

Right now, this design will set “ADFS 001” as the primary ADFS Farm, which contains the application you are trying to access, such as SharePoint. In our case, this is the “Claims X-Ray” application. If all ADFS Farms had applications that every other ADFS Farm needed access to, then you would create other “Relying Party Trusts” that would allow a full mesh type experience for an end-user to access any application in any domain using ADFS easily.

To test access, navigate to the IDP Initiated Sign-on page on the Primary ADFS Farm. For me, it is: https://fs.training001.int/adfs/ls/idpinitiatedsignon.htm

  • Select “Sign in to one of the following sites.“
  • Choose “ClaimsXray“
  • Click “Sign in“
  • Then select one of the other ADFS Farms

The odds are high that you will get an error like this:

It is resolved by modifying the “Claims Provider Trusts” on the Primary ADFS Farm, to include each signing certificate for each of the other ADFS Farms, within their configuration. Sometimes you need to check the full certificate chain and ensure all of it from the root certificate to the main one is trusted, which means copying them back between each ADFS Farm. You may also need to update the “ADFS Encryption” certificate from the self-signed one to one that is trusted on all ADFS servers in the Farms.

It can also be resolved by executing the following PowerShell (My primary ADFS Farm is ADFS 001)

Set-ADFSRelyingPartyTrust -TargetName “ClaimsXray” `

-SigningCertificateRevocationCheck “None”

Set-AdfsClaimsProviderTrust -TargetName “ADFS 002” `

-SigningCertificateRevocationCheck “None”

Set-AdfsClaimsProviderTrust -TargetName “ADFS 003” `

-SigningCertificateRevocationCheck “None”

Set-AdfsClaimsProviderTrust -TargetName “ADFS 004” `

-SigningCertificateRevocationCheck “None”

Set-ADFSProperties -IgnoreTokenBinding $true

You are then able to browse to the IDP Initiated Sign-in page and click on the “Claims Provider Trust” and authenticate back through the primary ADFS to the “Claims X-Ray” application.

The final adjustment is to modify the “Relying Party Trusts” on the primary ADFS Farm to pass the required claims, that are being sent from the other ADFS Farms.

Lastly, each “Relying Party Trust” on the other ADFS Farms, need a similar configuration.

All “Relying Party Trusts” on each ADFS Farm, except the primary, should be configured this way.

Once completed, navigate to the IDP Initiated Sign-in page, will then allow you to click one of the “Claims Provider Trusts,” which will then redirect to the “Claims X-Ray” application and display the sent claims for that domain.

As you can see, this setup has lots of steps and configuration requirements. Still, it supports the ability for users from all four domains (in my example) to access the single resource, which for me, is the “Claims X-Ray” application. We can expand on this and add both “Relying Party” and “Claims Provider” trusts too all ADFS Farms, with their list of applications and users from any domain can then access any application.

In Part 3, we will add SharePoint On-premises into the mix, on the Primary domain, and see how users from all domains can access the SharePoint sites. We will also look at how to handle user profiles within SharePoint.