While working with ADFS you may hit a requirement where you own multiple Active Directories or need to federate with another ADFS implementation to allow access to SharePoint. To achieve this we need to perform some very specific configuration. First off for my environment we need to get the service communication certificate and the certificate being used for the ADFS web site and trust them on each side of the server:

  1. ADFS Server A certificates added to ADFS Server B
  2. ADFS Server B certificates added to ADFS Server A

My certificates are all created using “SelfSSL” but would recommend for real world using an internally deployed Certificate Authority or purchasing proper certificates as needed.

ADFS Server A

ADFS Server B

These certificates needs to be added to the “Trusted Root” container within the certificate store.

Now that we have the certificates running you should be able to browse to:

https://{ADFS Server URL}/Federationmetadata/2007-06/federationmetadata.xml

This should load correctly in the browser and show without any SSL Errors.

To start out configuration we will start with “ADFS Server A” which is the one that contains the SharePoint Relying Party configuration.

We need to select the “Claims Provider Trust” node and choose to add a new claim provider trust.

You will need to get the URL for the External ADFS Federation Metadata XML file and add this into the wizard. This will allow the wizard to get the claim types and configuration automatically from the endpoint/

Set the name as you want it to be displayed in the ADFS Management tool.

The confirmation page should have retrieved all the core settings from the ADFS metadata file, you can check the values by going through the tabs.

When prompted to save, ensure the checkbox for edit claims is checked which will allow you to add the following (this needs to be changed to match your claims):

If we want to add these click the “Add Rule” button. Select “Pass Through or Filter an Incoming Claim“, this is so we simply accept the claims being passed from the external domain directly into the core internal ADFS and through to SharePoint.

We now need to specify claim rule name and choose the incoming claim type. You are then able to specify how you want the claims to be passed through, for this example I have set it to “Pass through all claim values“.

This completes the “ADFS Server A” configuration piece. Now we need to go to “ADFS Server B” and perform the following. Select the “Relying Party Trusts” and select to add a new one.

This time when adding the federation URL, use the internal ADFS URL not the External.

The confirmation page should have retrieved all the core settings from the ADFS metadata file, you can check the values by going through the tabs.

When prompted to save, ensure the checkbox for edit claims is checked which will allow you to add the following (this needs to be changed to match your claims):

We create a single rule with the following claims (once again this is just for the demonstration you may have others).

Once saved we now have an end to end ADFS solution. To test this you can now from “ADFS Server B“, this being the external ADFS server, with the correct DNS entries or host entries should be able to browse to the SharePoint URL, which should redirect to the realm picker to the following:

This page is presented from the internal ADFS, hosted on “ADFS Server A“. If the names do not look as nice as these you can use PowerShell to modify them by using the following commands:

This will list out the core properties for the current ADFS setup. Using the following commands you can update the display name.

This will then be reflected directly within the realm picker. So to test we can now select the external ADFS from the picker. Based on SharePoint not being configured for permission yet you should see the following error:

To resolve this we can now go to the SharePoint Site logged in with credentials on the internal domain and set permissions as normal.