Share via

SupportMultipleDomain switch, when managing SSO to Office 365

  • Article

Use of SupportMultipleDomain switch, when managing SSO to Office 365 using ADFS

When a SSO is enabled for O365 via ADFS, you should see the Relying Party (RP) trust created for O365.

 

 

Commands that would create the RP trust for O365 are below:

New-MsolFederatedDomain -DomainName``<domain>

OR

Convert-MsolDomainToFederated -DomainName <domain>

OR

Update-MSOLFederatedDomain -DomainName <domain>

**Update-MSOLFederatedDomain as the name suggest if you update an existing federation trust between ADFS and O365, In this process it will update or recreate the RP on ADFS side.

The RP trust created above comes with 2 claims rules

 

'Get-MsolFederationProperty -DomainName <domain>' for the federated domains shows that the “FederationServiceIdentifier” was the same for source ADFS and O365 i.e. the <br>https://STSname/adfs/Services/trust

 

With the ADFS rollup 1 update, we added the following functionality:

 

Support for Multiple Top Level Domains

“Currently, Microsoft Office 365 customers who utilize single sign-on (SSO) through AD FS 2.0 and have multiple top level domains for users' user principal name (UPN) suffixes within their organization (for example, @contoso.com or @fabrikam.com) are required to deploy a separate instance of AD FS 2.0 Federation Service for each suffix. There is now a rollup for AD FS 2.0 ( https://support.microsoft.com/kb/2607496 ) that works in conjunction with the “SupportMultipleDomain” switch to enable the AD FS server to support this scenario without requiring additional AD FS 2.0 servers. ”

Commands that can be used to create the RP trust for O365, to support multiple top level domain:

New-MsolFederatedDomain -DomainName ``<domain>`` -SupportMultiDomain

OR

Update-MSOLFederatedDomain -DomainName <domain> ``-SupportMultipleDomain

OR

Convert-MsolDomainToFederated -DomainName <domain>`` - SupportMultipleDomain

Post using SupportMultipleDomain switch, the following 2 changes take place:

1. 'Get-MsolFederationProperty -DomainName <domain>' on the federated domains now shows that the “FederationServiceIdentifier” is ``different`` for ADFS and O365. Every federated domain will have the “FederationServiceIdentifier” as https:// <domainname>/ adfs/services/trust/ whereas the ADFS configuration still has https://STSname/adfs/Services/trust.

Due to this mismatch in configuration, we need to ensure that when a token is sent to O365 the issuer mentioned in it, is the same as one configured for the Domain in O365. Therefore the SupportMultipleDomain also adds the following 3rd claim rule in the O365 RP, under ADFS. If not you will get the error below:

 

 

So what does this 3rd claim rule added by SupportMultipleDomain to the RP trust for O365, do

Default 3rd rule:

c:[Type
== "https://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)", "https://${domain}/adfs/services/trust/"));

This rule uses the suffix value of user’s UPN and uses that to generate a new claim called Issuerid. For example, for a user User1@contoso.com , the issuerID in his Token will be https://contoso.com/adfs/services/trust/.

Using fiddler, we can trace the token being passed to login.microsoftonline.com/login.srf. After copying the token passed in wresult, paste the content in notepad and save that file as .xml.

Later you can open the token saved as .xml file using IE and see its content.

  

 

 

It’s interesting to note that the though this rule issues 'Issuerid' claim, we don’t see this claim in the response token, in fact we see the “ Issuer ” attribute modified to the newly composed value.

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="https://contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

 

NOTE: If – SupportMultipleDomain is used without the ADFS rollup 1 or 2 installed. You will see that the response token generated by ADFS has BOTH the Issuer=” https://STSname/adfs/Services/trust” and the claim “Issuerid” with the composed value as per the 3rd claim rule.

<saml:Assertion MajorVersion="1" MinorVersion="1"
AssertionID="_2546eb2e-a3a6-4cf3-9006-c9f20560097f" Issuer="https://STS.contoso.com/adfs/services/trust/" IssueInstant="2012-12-23T04:07:30.874Z" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">

…

<saml:Attribute
AttributeName="issuerid" AttributeNamespace="https://schemas.microsoft.com/ws/2008/06/identity/claims"> <saml:AttributeValue> https://contoso.com/adfs/services/trust/</saml:AttributeValue >
</saml:Attribute>

-       This will again lead to error “Your organization could not sign you in to this service”

 

Support for Sub domains

“It is important to note that the “SupportMultipleDomain” switch is not required when you have a single top level domain and multiple sub domains. For example if the domains used for upn suffixes are @sales.contoso.com, @marketing.contoso.com
and @contoso.com and the top level domain (contoso.com in this case) was added first and federated then you don’t need to use the “SupportMultipleDomain” switch. This is because these sub domains are effectively managed within the scope of the parent and a single AD FS server can be utilized to handle this already.”

If however, you have multiple top level domains (@contoso.com and @fabrikam.com) and these domains also have sub domains (@sales.contoso.com and @sales.fabrikam.com) the “SupportMultipleDomain” switch will not work for the sub domains and these users will not be able to login.

 

Why will this switch not work, in the above scenario?

Answer:

-       For child domain, sharing the same namespace, we don’t federate them separately. The federated root domain covers the child as well, which mean that the federationServiceIdentifier value for the child domain will also be the same as that of parent i.e. https://contoso.com/adfs/services/trust/

 

-       But the 3rd claim rule which ends up picking the UPN suffix for the user to compose the Issuer value ends up with https://Child1.contoso.com/adfs/services/trust/, again causing a mismatch and hence the error “Your organization could not sign you in to this service”

To resolve this, we can modify the 3rd rule such that it ends up generating an Issuer value that matches “FederationServiceIdentifier” for the domain at O365 end. 2 different rules that can work in this scenario are below. This rule just picks up the root domain from the UPN suffix to compose the Issuer value. For a UPN suffix child1.contoso.com, it will still generate an Issuer value of https://contoso.com/adfs/services/trust/ instead of https://Child1.contoso.com/adfs/services/trust/ (with default rule)

 

Customized 3rd rule

     Rule 1:

c:[Type == "https://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "https://${domain}/adfs/services/trust/"));

 

OR

 

Rule 2:

c:[Type
== "https://schemas.xmlsoap.org/claims/UPN"]

=> issue(Type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, “https://${domain}/adfs/services/trust/”));

 

Sample output from the above rule:

[regex]::replace("[email protected]", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.com/adfs/services/trust

[regex]::replace("[email protected]", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.co.in/adfs/services/trust

[regex]::replace("[email protected]", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.co.in/adfs/services/trust

[regex]::replace("[email protected]", “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, 'https://${domain}/adfs/services/trust')
https://contoso.org/adfs/services/trust

 

 Note:

The rules above may not apply to all scenarios, but can be customized to ensure that the Issuerid value matches “ FederationServiceIdentifier” for the domain added/federated at O365 end.

 

The mismatch of federationServiceIdentifier between ADFS and O365 for a domain can also be corrected by modifying the “federationServiceIdentifier” for the domain at O365 end, to match the “federationServiceIdentifier” for ADFS. But the federationServiceIdentifier can only be configured for ONE federated domain and not all.

 

-``        `` Set-MSOLDomainFederationSettings -domainname Contoso.com –issueruri https://STS.contoso.com/adfs/services/trust/

 

 

More information that should help you write your own claim rules.

 

The Role of the Claim Rule Language
https://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx

 

Understanding Claim Rule Language in AD FS 2.0
https://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0.aspx#General_Syntax_of_the_Claim_Rule_Language

 

Regular Expressions
https://technet.microsoft.com/en-us/library/hh440535.aspx

Hope this info helps 

 

Cheers

Abizer

Comments

  • Anonymous
    January 01, 2003
    Hi, We add dimain1.com and sub.domain1.com with the supportmultipledomain switch. MOdified the ruke3 as per option 1 above - login works. We add domain2.com and federate, and  the user gets blocked. What we want is multiple top level domains and one with subdomains to work with SSO. We are considering not adding the top level domain domain1.com and just adding all the subdomains (as toplevel domains) and domain2.com also. Should the supportmultipledomain be used when trying your solution? Should supportmultipledomain be used if we add all the subdomains as proposed? Should the subdomains be added to )365 at all if the top level domain is there?

  • Anonymous
    March 02, 2013
    Good stuff!!! Thanks, saved my Weekend :)

  • Anonymous
    July 08, 2013
    For the source material used in this article, please see: blog.kloud.com.au/.../office-365-ad-fs-2-0-with-multiple-domains-and-subdomains-2 :)

  • Anonymous
    November 03, 2014
    We want to use Directory Synchronisation of two domains. One domain is abc.com, the second domain is ext.abc.com. Both domains aren't in the same forest, they are in two different, non-trusted forests.

    Is it possible to use this scenario, if the ADFS-Servers are two different ones (one in the related forest)? If it's possible, how you must configure it in Office365?

  • Anonymous
    June 01, 2015
    Here I’m assuming that we are using ADFS, for SSO to O365 services:
    Below I have tried to list

  • Anonymous
    September 15, 2015
    Hi there,

    Do you know if the following scenario is possible?

    Local AD domain: domain.com.pt
    SMTP domains: domain.pt, anotherdomain.com

    I am using Alternate Login ID feature and the SupportMultipleDomain switch.

    The idea is to login using the mail attribute (in this case each SMTP domain), without changing every UPN manually.

    Thanks a lot for this article! Technically perfect and objective.

    Cheers,

    Bruno Martins

  • Anonymous
    January 28, 2016
    Bruno! please come back to Feyenoord!!!!!

  • Anonymous
    January 28, 2016
    Bruno! please come back to Feyenoord!!!!!