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:

  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

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

Liam Cleary

Liam began his career as a Trainer of all things computer-related. He quickly realized that programming, breaking, and hacking was a lot more fun. He spent the next few years working within core infrastructure and security services until he found SharePoint. He is the founder and owner of SharePlicity, a consulting company that focuses on all areas of Technology. His role within SharePlicity is to help organizations implement technology that will enhance internal and external collaboration, document and records management, automate business processes, and of course security controls and protection. Liam also serves as the Principal Technology Advisor at Rencore, where he is helping to develop offerings that help organizations further understand and mitigate security and compliance risks, within SharePoint and Office 365 customization's. His core focus will is to identify, control, and protect whether they are full-fledged customization's or out-of-the-box Office 365 functionality. He is also a thirteen-time Microsoft MVP focusing on Architecture but also crosses the boundary into Development. He is also a Microsoft Certified Trainer (MCT). His specialty over the past few years has been security in SharePoint and its surrounding platforms. He can often be found at user groups or conferences speaking, offering advice, spending time in the community, teaching his kids how to code, raspberry PI programming, hacking the planet or building Lego robots.

You may also like...