AD FS 2.0 Update Rollup 1 allows a single ADFS farm to support multiple top level domains for Office 365 federated authentication. Unfortunately, the default claim rules generated with RU1 do not support multiple top levels domains with subdomains.
“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.” – Office 365 wiki
The good news is that this limitation can be removed by updating the regular expression for the third Office 365 claim rule. Before we explain the “how”, let’s look at the “why”.
Using fiddler, we can trace the token being passed to login.microsoftonline.com/login.srf. When inspecting packets with the default claim rules in use, we can see that the full domain is being passed as an “issuer ID” value:
<t:RequestSecurityTokenResponse xmlns:t=”http://schemas.xmlsoap.org/ws/2005/02/trust”><t:Lifetime><wsu:Created xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>2012-08-17T00:47:11.032Z</wsu:Created><wsu:Expires xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>2012-08-17T01:47:11.032Z</wsu:Expires></t:Lifetime><wsp:AppliesTo xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy”><wsa:EndpointReference xmlns:wsa=”http://www.w3.org/2005/08/addressing”><wsa:Address>urn:federation:MicrosoftOnline</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><t:RequestedSecurityToken><saml:Assertion MajorVersion=”1″ MinorVersion=”1″ AssertionID=”_054402c0-2255-419f-ac6c-aa40b0769a71″ Issuer=”http://sub.domain.com.au/adfs/services/trust/” IssueInstant=”2012-08-17T00:47:11.033Z” xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion”>…
This is fine if you’re logging in with the parent domain. If however, you are logging in with a federated sub domain, you will see the following message and the Office 365 services will be inaccessible:
So, why is this happening? Federated sub-domains are managed within the scope of the parent domain. Office 365 is expecting an issuer ID containing the parent domain. At this point, if you’re federating production domains you have two options; you could convert the federated domain back to standard (which means you will need to distribute a new password to all users), or update the claim rule. Distributing a new password to an entire user population without access to e-mail sounds like a drag, so let’s do the latter.
Updating the claim rule:
- Open the AD FS 2.0 Management Console on the primary farm server and locate the Relying Party Trusts node. Select the Microsoft Office 365 Identity Platform trust and select Edit Claim Rules
- Select the third claim rule and select Edit Rule
- Replace the default claim rule with the following value and then select Ok
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*.(aero|asia|biz|cat|co|com|coop|edu|gov|health|info|int|jobs|mil|mobi|museum|name|net|org|post|pro|tel|travel)(.\w\w)?)$", "http://${domain}/adfs/services/trust/"));
That’s it. Authentication for the sub-domain will now work. If we repeat our traces with fiddler, we can now see the issuer ID contains the parent domain.
<t:RequestSecurityTokenResponse xmlns:t=”http://schemas.xmlsoap.org/ws/2005/02/trust”><t:Lifetime><wsu:Created xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>2012-08-17T00:50:36.026Z</wsu:Created><wsu:Expires xmlns:wsu=”http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd”>2012-08-17T01:50:36.026Z</wsu:Expires></t:Lifetime><wsp:AppliesTo xmlns:wsp=”http://schemas.xmlsoap.org/ws/2004/09/policy”><wsa:EndpointReference xmlns:wsa=”http://www.w3.org/2005/08/addressing”><wsa:Address>urn:federation:MicrosoftOnline</wsa:Address></wsa:EndpointReference></wsp:AppliesTo><t:RequestedSecurityToken><saml:Assertion MajorVersion=”1″ MinorVersion=”1″ AssertionID=”_4b07fc86-ba2c-4933-ac1d-c255b8e2a111″ Issuer=”http://domain.com.au/adfs/services/trust/” IssueInstant=”2012-08-17T00:50:36.035Z” xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion”>…
Special thanks to Microsoft Premier Support for providing the regular expression that was used in the revised claim rule.
Hi,
Just to clarify, so you tested that ADFS configured to forest domain.com can be used also with separate forest Domain.net or only new root domain in the same forest.??
Thanks.
This blog refers to multiple Office 365 domains and sub domains, not Active Directory forests/domains. According to the Microsoft Office 365 SSO whitepaper, multiple Active Directory forests are not currently supported.
Hi Ross,
I’ve tried the fix you propose in your article and it’s working just fine for me so, first off, thank you for sharing it. Now I’ve opened a service request with the O365 Technical Support, but it seems they’re not aware the issue described in their wiki has found its solution: could you please post the Microsoft Premium Support case # (they sent you the revised claim rule, if I’m not mistaken) so I can get a certified answer from them?
Thanks
Glad to hear the fix is working. As this is a custom claim rule it is unlikely to be certified by Microsoft.
Thanks for this Article David.
I am trying to get this rule to work with ADFS2.0 and Rollup 3 and it doesn’t appear to like the regex.
Is it possible there is an issue with the regex?
Thanks, David. Was able to use this claim rule adjustment on a project. Note to others, be careful when copying and pasting the code. Some of the characters might need to be adjusted.
Thanks for the feedback. I’ve updated the claim rule to include some additional top level domains & corrected the formatting so copy/paste should now work.
Hi David,
This helped a bunch for me. I had to add our own domain (.dk) to the regex, and that fixed it for us. I took the liberty of referencing your blog here http://community.office365.com/en-us/forums/613/p/208055/632389.aspx#632389
Hi,
Will one ADFS farm support to have a setup with 1 top level domain with multiple child domains?
contoso.com
child1.contoso.com
child2.contoso.com
Yes – that will work fine.
We had a situation where we needed to end up with four parts to the domain and include subdomains – eg the domain is example.qld.edu.au and there are possible subdomains students.example.qld.edu.au or staff.example.gld.edu.au
This we manage to achieve using the following:
c:[Type == “http://schemas.xmlsoap.org/claims/UPN”]=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid”, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?(\w+\.\w+\.\w+\.\w{2,3}$)?)$”, “http://${domain}/adfs/services/trust/”));