4

A company is using Office 365 with ADFS authentication; AD Connect is used for directory synchronization, ADFS is the Windows server 2012 R2 version.

The company has multiple Active Directory domains:

parent1.com
    child1.parent1.com
    child2.parent1.com
    child3.parent1.com
parent2.com
    ...
...

The root domains are configured as federated domains in Office 365 (the public domain names and the AD domain names are identical); this works fine, users can login to Office 365 using their UPN, such as user1@parent1.com, and their AD password.

I need to add support for child domains; thus I added child1.parent1.com to Office 365 by running the following command (after connecting to Office 365 with an admin account using Connect-MsolService):

New-MsolFederatedDomain -DomainName child1.parent1.com -SupportMultipleDomain

(N.B. If I didn't use the SupportMultipleDomain parameter, PowerShell would give an error stating it was required).

Then I proceeded to add all required DNS records, both in the private and public DNS; Office 365 validation of DNS records reported everything was ok.

The child domain was then added to AD Connect, and synchronization was performed; users from the child domain thus appeared in Office 365, with usernames such as user1@child1.parent1.com. I assigned appropriate licenses to them and tried to login to the Office 365 portal.

However, users for the child domain are unable to login; they receive an "invalid request" error, with the following additional details:

Correlation ID: b1e47d45-b21c-42e9-9758-265804db7171 
Timestamp: 2016-08-10 20:27:48Z 
AADSTS50107: Requested federation realm
object 'http://child1.parent1.com/adfs/services/trust/' does not exist.

There's obviously something wrong on the ADFS side, but I'm not an expert on it and I also wasn't the one who set it up; how can I fix this so that users in child domains can successfully login to Office 365?

Massimo
  • 70,200
  • 57
  • 200
  • 323

1 Answers1

3

The issue is very scarcely documented (a Technet blog post and some documentation for Azure AD), but it indeed exists, and it's caused by ADFS not behaving correctly in certain specific situations (multiple top-level federated domains and throwing federated child domains in the mix); the solution involves editing a regular expression in an ADFS claim rule which is used to build the IssuerUri associated with the user's UPN. Quoting from the second article:

So lets say for example that I have bmcontoso.com and then add
corp.bmcontoso.com. This means that the IssuerUri for a user from
corp.bmcontoso.com will need to be http://bmcontoso.com/adfs/services/trust.
However the standard rule implemented above for Azure AD, will generate a
token with an issuer as http://corp.bmcontoso.com/adfs/services/trust
which will not match the domain's required value and authentication will fail.

To solve the issue, the third claim rule in ADFS should be edited, going from

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>.+)","http://${domain}/adfs/services/trust/"));

to

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>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));

However, beware that this might break compatibility with other scenarios, such as an actual third-level federated domain whose parent domain is not federated.

Massimo
  • 70,200
  • 57
  • 200
  • 323