Using Selective Authentication per Subdomain in Office 365

Office 365 allows for various authentication mechanisms, which includes federated authentication through Active Directory Federation Services. Federated authentication in Office 365 is configured per domain. However, if you register multiple subdomains in your Office 365 tenant, those subdomains will automatically inherit the authentication settings from the parent domain IF you registered the subdomains in the tenant after the parent domain.

For instance, if you have added child1.domain.com and child2.domain.com after registering domain.com, both subdomains will be converted to use federated authentication if you convert the parent domain.

Sometimes, however, this is not exactly what you are looking for. You might actually want to use a different authentication mechanism for users in the child domains. If you follow the correct order of steps, it is actually very easy to configure. From a high level, this is what the process looks like:

1. Register child domains in the Office 365 tenant.
2. Register parent domains in the Office 365 tenant.
3. Configure authentication per (sub)domain.

To illustrate this scenario, take a look at the output of the Get-MsolDomain cmdlet. You will notice there is a parent domain called "parent.com" and several child domains called "child1.parent.com","child2.parent.com," and "child3.parent.com"

You can determine if a subdomain was added before the parent domain by looking at the "RootDomain" property of the registered domain. If the property contains the value of the parent domain, it means the child domain was registered after the parent domain. In such cases, the child domain will automatically inherit the authentication mechanism that is configured for the parent domain.

The above PowerShell example shows us that child3.parent.com was registered after parent.com, unlike child2.parten.domain.com, which was registered before. If you try changing the authentication mechanism for the third child domain, you will be presented with the following error:

As long as you follow the order of steps outlined below, you should be fine. The more interesting question is: Why would you want to have selective authentication per subdomain? For instance, this would be the case if users in child domains were managed elsewhere. Another reason would be to offload the on-premises AD FS servers. Consider a (large) university, for example. It usually has many more students than staff and faculty. By configuring a different UPN for students (for example, student.domain.com), it can allow students to use a cloud username and password (possibly aided by Password Hash Synchronization). That way, the on-premises AD FS infrastructure does not have to be sized to handle the load of all Office 365 users.

So, is there anything specific you need to do to make the above scenario work? Yes and no. First of all — and I cannot stress this enough — make sure to register your domains in the correct order. If you decide to configure multiple (sub)domains for federated authentication, make sure you use the –SupportMultipleDomain switch when converting a domain from a standard to a federated domain (as illustrated in the PowerShell example above).

In larger, complex, environments you might find that additional work is required. This would definitely be true in an environment with multiple parent and root domains. In the above examples, all (sub)domains belong to the same domain tree "parent.com." During my testing, I found that if you add other top-level domains that use the same AD FS infrastructure, there is no problem, as long as you use the –SupportMultiDomain switch. In fact, you will not be able to convert a domain to a federated domain without it. However, once you add subdomains that belong to another tree, like child.newparent.com, things start to get nasty. You will notice that authentication for users that have a UPN based on that child domain will no longer be able to authenticate:

This is a “known” issue, but the article 'SupportMultipleDomain switch, when managing SSO to Office 365' describes a workaround. Needless to say, there is a fair amount of complexity involved once you go down this path. 

An alternative is to take the same approach for each domain you register. So, in the above scenario, if you were to add new (sub-)domains for a different tree, you should also register the child domains first before you register the parent domain. Doing so will ensure that the problem described in the Microsoft article does not occur and that you can control the authentication per domain, including the sub-domains.

Regardless of what route you take, you have to understand that this adds quite a bit of complexity to your environment. Complexity, in turn, usually leads to more (human) mistakes that might end up affecting the AD FS environment. So, before you decide to enable selective authentication for subdomains, make sure you understand the risks and ensure you absolutely need the granular authentication option.

This being said, there is one more scenario to cover: What should you do if you find out your child domains were registered after the parent domain was registered, but you still want to enable selective authentication? Well, unlike the rest of this article, the answer will be short: You're in for a whole lot of (disruptive) work. It's not the type of scenario I’d like to end up in, and, if I do, I'd rather challenge the need for selective authentication. If there are no other options, let's just say it involves removing the "wrong" child domain (plus all the work to do so) and call in help from O365 support to re-add a domain but with an empty RootDomain flag (see above for more info on this property).

A special thanks goes out to Lou Mandich (MSFT) for his help and feedback while researching/testing these particular scenarios. It's always nice to be able to fall back on knowledgeable people like him!

Disclaimer: All the authentication tests were executed based on a Windows Server 2012 R2 AD FS infrastructure. Although I don't expect there will be any difference, make sure to test this first — especially if you are using a legacy version of AD FS, e.g., Windows Server 2008 R2. When you are using AD FS on Windows Server 2008 R2, you must absolutely install update rollup 1 for AD FS; this ensures that the –SupportMultipleDomain switch is correctly interpreted by AD FS.

Active Directory Monitoring and Reporting

Active Directory is the foundation of your network, and the structure that controls access to the most critical resources in your organization. The ENow Active Directory Monitoring and Reporting tool uncovers cracks in your Active Directory that can cause a security breach or poor end-user experience and enables you to quickly identify and remove users that have inappropriate access to privileged groups (Schema Admins, Domain Administrators). While ENow is not an auditing software, our reports reduce the amount of work required to cover HIPAA, SOX, and other compliance audits.

Access your FREE 14-day trial to accelerate your security awareness and simplify your compliance audits. Includes entire library of reports.