Site icon Liam Cleary [MVP Alumni and MCT]

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

helloitsliam

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:

  1. Export the ADFS certificate and Wildcard from each ADFS Server
  2. Copy the Exported ADFS Certificate and Wildcard Certificate to each ADFS Server
  3. 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

Import the copied ADFS Certificate and Wildcard Certificate into the local Certificate Store on 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.

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.

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.”

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

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.

Exit mobile version