Configuring a multi-tenant federation with AD FS in a multi forest scenario with PowerShell

For weeks we have been working with Microsoft Premier Support and several product teams within Microsoft on a multi-forest to multi-tenant federation solution for Office 365 at two Dutch municipalites. There was some unclarity concerning supportabilty for our desired architecture at Microsoft, but as Microsoft calls it… this architecture qualifies for supportabilty. The fun part is, this scenario doesn’t require the provisioning of AD objects by hand, and allows you to use AADConnect to do this for you!

Now as the topology shows, we have two accounting forests where the AADConnect servers and Active Directory users reside. Each municipality has its own forest (forest B and forest C) and a configured a two-way full trust (forest-wide) to the resource forest (forest A). The Active Directory Federation Services (AD FS) farm resides in the resource forest (forest A).

Now the business requirement is having a single but high available AD FS farm in a resource forest, delivering an easy way of administering Identity Management for the long term. While at the same time delivering single sign-on functionality to all users working with Office 365 for each respected municipality.

Now the hard part here is the second federation to Office 365. The first federation configurated between the Microsoft Federation Gateway and your on-premises AD FS farm is pretty straight forward. And here is how it’s done:

  1. Log in to one of the AD FS Servers with an Domain Administrator account.
  2. You need to install the modules that are required for Office 365,
    1. Microsoft Online Service Sign-in Assistant for IT Professionals RTW
    2. Windows Azure Active Directory Module for Windows PowerShell (64-bit version
  3. Setup a Remote PowerShell connection to your tenant with an account having Global Administrator rights with this script;
    1. Import-Module MSOnline
      $O365Cred = Get-Credential
      $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $O365Cred -Authentication Basic -AllowRedirection
      Import-PSSession $O365Session
      Connect-MsolService –Credential $O365Cred

Once connected to the first tenant in Office 365 on the AD FS server run this cmd-let, be sure to use the -SupportMultipleDomains $true parameter.

Convert-MsolDomainToFederated -DomainName -SupportMultipleDomain $true

The –SupportMultipleDomain parameter is needed since this is required for the multi-tenant configuration to work. This paramater makes sure that the federation is built with the correct IssuerUri set to instead of the Federation Service namespace (generally when not using this parameter. This is a vital requirement later on. To double-check this you can check the Claim Rules in AD FS management, the third rule should containt this claim:

c:[Type == ““] => issue(Type = ““, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

Now this was the first municipality for which is the federated domain. You can download the script at the bottom of this blog.

Wait for a minute -or five- untill the federation kicks in and let’s carry on implementing the second federation…the real fun part!

First of all we need to export the token-signing certificate from the AD FS farm by PowerShell:

$tokenRefs=Get-AdfsCertificate -CertificateType Token-Signing
[System.IO.File]::WriteAllBytes(“c:\temp\tokensigning.cer”, $certBytes)

Next we can establish a new Remote PowerShell session to the second tenant with the script shared in step one of this post. After that we configure the second federation with this PowerShell script.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\temp\tokensigning.cer”)
$certData = [system.convert]::tobase64string($cert.rawdata)
#command to enable SSO
Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -ActiveLogOnUri $ura -PassiveLogOnUri $url -MetadataExchangeUri $metadata -SigningCertificate $certData -IssuerUri $uri -LogOffUri $logouturl -PreferredAuthenticationProtocol WsFed

Now the most beautiful part of this second implementation is that it only configures endpoints on the Microsoft Federation Gateway, and doesn’t touch our on-premises configuration. The magic third claim we talked about earlier is all we need for it to work!

Once configured, the configuration of both tenants can be validated using the ‘Get-MsolDomainFederationSettings’ cmdlet. The only difference when comparing the tenant configuration should be the ‘FederationBrandName’ and the ‘IssuerUri’ values.

Download the PowerShell scripts right here!




6 thoughts on “Configuring a multi-tenant federation with AD FS in a multi forest scenario with PowerShell

  1. There are around 6 AD Forests (no trust) and 6 Office 365 tenants (Manual account creation). There is no AADSync and ADFS. And additionl to this they are using GoogleApps also for classroom. There is no relation between below systems. Users are using multiple password to access below systems (UserA from Forest A use three passwords; system login (1st password) ), O365 (2nd password) and GApps (3rd password) and they want to access file share from Forest-B resources then one more account from Forest B.

    Now, we want to enable two-way trust and give file share access directly to his AD Account (AD Forest – A) but still he will use 3 passwords for AD, O365, GApps.
    Can we have central AADSync and ADFS System so that if we create account in AD Forest -A then sync to O365 Tenant and create account in AD Forest – B then sync to O365 tenant and similar other domains. And can we have Central ADFS System as you described in above article?
    If yes, in which Forest we need to install AADSync and ADFS Systems? or do we need to install seperate AADSync system for each O365 Tenant and single ADFS System? And what can we do with GApps to enable SSO? Can we use the same ADFS?

    AD Forest – A
    AD Forest – B
    AD Forest – C
    AD Forest – D
    AD Forest – E
    AD Forest – F
    O365 Tenant
    O365 Tenant
    O365 Tenant
    O365 Tenant
    O365 Tenant
    O365 Tenant
    GApps –
    GApps –
    GApps –
    GApps –
    GApps –
    GApps –

    1. Hi Armin,

      Depends. In this specific scenario we used an unique namespace for the AD FS service and SSL certificate. So accounting forests (or organizations) should use the namespaces used in the resource forest and AD FS farm.

      Please feel free to get in contact if you have more questions.


      1. Hi Thomas,

        We have a scenario where we have 1 AD forest with multiple OUs, each OU will be a domain suffix so that the users in each OU will have their own domain name (different to the parent domain), and each OU will be sync’ed to its own tenant on Office 365, i just want to find out can the SSL cert used for signing just contain the AD forest domain (parent) name?? or does it require the domain names of the OUs as well??


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s