Multiple Domain Forests, Multiple ADFS Servers, and SharePoint – Part 1

As part of the work I often get involved with, it tends to involve Federated Authentication either with On-Premises or Cloud Services. In the past, I have used Active Directory Federated Services (ADFS) as the middleman between all kinds of applications and configurations. Most recently, I have been working with multiple third-party federated platforms, that pass-through ADFS onto some applications such as SharePoint of Office 365.

A common question I often get asked either through twitter, blog comments, or even email is about multiple Active Directory Forest, Multiple Active Directory Federated Services configuration, and other applications. As such, I thought a blog post would explain this and walk-through a sample setup.

Let’s review the basic setup and configuration.

SERVER NAME	SERVER DETAILS
ADFS 001	DOMAIN: TRAINING001.INT ADFS URL: fs.training001.int IP SUBNET: 10.0.2.0/24 IP ADDRESS: 10.0.2.12 CERTIFICATES: *.training001.int, fs.training001.int
ADFS 002	DOMAIN: TRAINING002.INT ADFS URL: fs.training002.int IP SUBNET: 10.0.3.0/24 IP ADDRESS: 10.0.3.12 CERTIFICATES: *.training002.int, fs.training002.int
ADFS 003	DOMAIN: TRAINING003.INT ADFS URL: fs.training003.int IP SUBNET: 10.0.4.0/24 IP ADDRESS: 10.0.4.12 CERTIFICATES: *.training003.int, fs.training003.int
ADFS 004	DOMAIN: TRAINING004.INT ADFS URL: fs.training004.int IP SUBNET: 10.0.5.0/24 IP ADDRESS: 10.0.5.12 CERTIFICATES: *.training004.int, fs.training004.int

Each server can resolve the required URLs for each domain using DNS. The core goal is to connect each ADFS Implementation allowing users to authenticate between each other no matter the ADFS and Domain they originate. To achieve this, it requires the use of Claims Provider Trusts.

Primarily a Claims Provider Trust is used when an ADFS configuration needs to federate with a Partner Organization or other Federation Platform. Within each ADFS Implementation, there are three Claims Provider Trusts, one for each other ADFS Implementation.

Each ADFS Imp0lementatio uses the “fs.trainingXXX.int” Certificate for the service connection URL. The automatically created self-signed signing certificate still exists but is not the primary Certificate; this has been replaced by the “*.trainingXXX.int” Certificate for each respective domain.

To achieve this, and make it easier, we first need to complete the following tasks:

Export the ADFS certificate and Wildcard from each ADFS Server
Copy the Exported ADFS Certificate and Wildcard Certificate to each ADFS Server
Import the copied ADFS Certificate and Wildcard Certificate into the local Certificate Store on each ADFS Server

The only reason I am exporting the Service Communication Certificate is so that when I test from each server and add the ADFS URLs into each ADFS Server, that I don’t get SSL certificate issues. It is due to me using separate Certificate Authorities within each Domain Forest.

Export the ADFS certificate and Wildcard from each ADFS Server

Launch “AD FS Management“
Expand “ADFS,” then “Service.“
Click on “Certificates“
Right-click the “Service Communications” Certificate
Choose “View Certificate“
Click the “Details” Tab
Click “Copy to File…”
Ensure the “Yes, export the private key” option is selected
Leave the defaults

Click “Next“
Check the “Password” option, then type a secure password
Click “Next“

Do not use the “Group or usernames” as you are crossing to different domains and potentially different accounts that won’t work.
Set the location and name for the exported Certificate
Click “Next“
Click “Finish,” then “OK.“
Close the Certificate, and repeat for the “Wildcard Signing” certificate

Repeat for all ADFS Servers

Import the copied ADFS Certificate and Wildcard Certificate into the local Certificate Store on each ADFS Server

Ensure that both PFX files from each ADFS server get copied to each other ADFS server

To import the certificates. Start a run command, then type “MMC.“
Click “File“, then “Add/Remove Snap-in“
Click “Certificates,” then “Add.“
Select “Computer Account” and choose “Local Computer.“
Click “OK“
Expand “Certificates” then “Personal.“
Click “Certificates“
Right-click and choose “All Tasks,” then “Import.“
Navigate to the certificate location
Change the dropdown for file types to “All Files.“
Select the required Certificate, then click “Next.“
Type the password for the Certificate, then ensure “Mark this as exportable” is checked
Click “Next“
Leave the location as the default
Click “Next“
Repeat for each Certificate
Repeat on each ADFS Server
The Certificate snap-in should now display all the certificates for each environment within each ADFS Server.

Now we have the required certificates installed on each server; we can navigate to the IDP Initiated Sign on Page if you have enabled it for each ADFS Server, from each ADFS Server, and there should be no certificate errors. My URLs are:

Remember, if you utilize this for testing, that once you go to production, disable this page.

The next step is to add each ADFS implementation as a Claims Provider Trust to each ADFS server.

Launch “AD FS Management“
Click “Claims Provider Trusts“
Right-click and choose “Add Claims Provider Trust.“
Click “Start“

As we have functioning ADFS Servers for other domains and each ADFS Server can navigate to each other, we can use the federation metadata XML approach. My URLs are:

You can test this by viewing this URL within the Browser of each ADFS Server. If the main ADFS URL is not in the Intranet Zone, then it won’t display as native XML, but as Text. If the URLs are in the Intranet Zone, they render as XML.

Now that the URLs work, we copy that URL into the “Federation Metadata Address” field in the Data Source screen.

Click “Next,” this may take some time as it needs to read the XML and make sure it works as expected.

If you get this error, then you’ll have to revisit the certificates on each server. You may need to export the Root Certificate Authority Certificate(s) too to ensure the correct SLL/TLS channel works.

Ensure the Root Certificates gets added to the “Trusted Root Certification Authorities” and sometimes the “Enterprise Trust” locations in the certificate store.

Once that is completed, and you can navigate to each federation metadata XML URL with no SSL / TLS errors. You can then enter the URL into the “Claims Provider Trust” wizard.

Once it is validated, you need to set the “Display Name,” this defaults to the “fs.trainingXXX.int“, however, change it to something that makes sense, such as “ADFS XXX.”

Click “Next“
Click “Next“
Uncheck the “Open the Edit Claim Rules dialog for this claims provider trust when the wizard closes.“
Click “Close“
Repeat this process for each ADFS Implement, except the one you are on

Each ADFS Implementation should then display in the “Claims Provider Trust” window.

Open your internet browser and now navigate to the ADFS IDP Sign on-page for the server you are on.

Example: https://fs.training001.int/adfs/ls/idpinitiatedsignon.htm

Click “Sign in“

You should now see the three other “Claims Provider Trusts.“

Clicking any of the trusts redirects you to that ADFS implementation for authentication.

The authentication won’t work, as we have not set up any of the claim attributes etc. but you can see the URL redirects are working as expected.

In Part 2, we’ll configure the claim attributes for each “Claims Provider Trust.” In Part 3, we’ll look at the authentication flow itself and how to test the claims.