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/&#8221; 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:

  1. 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
  2. Select the third claim rule and select Edit Rule

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

Category:
ADFS, Office 365

Join the conversation! 8 Comments

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

    Reply
  2. 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

    Reply
  3. 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?

    Reply
  4. 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.

    Reply
  5. 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.

    Reply
  6. 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

    Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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