Sean Wallbridge
Office 365 and Azure both offer the ability to fully integrate (federate) your on-premise domain with the Microsoft Cloud (O365 and Azure). This is a great benefit to many organizations but there are some caveats that come along with federation. I’m not going to go into those caveats in this post but I do want to call out something that you need to think about if you are considering federation and you will be setting up subdomains under a primary domain in Office 365.
Let’s consider this scenario: I have my primary domain — beagledom.ca — already set up in Office 365. If I add a subdomain such as test.beagledom.ca and perform all of the necessary activation steps within Office 365 for the subdomain, the subdomain will be created within the namespace already created for the primary domain and it will take on the “characteristics” of the primary domain. This means that if my primary domain is federated then the sub-domain I just added will also be federated as it is part of my primary domain namespace in Office 365.
There is no issue with this IF I want my subdomain to also be federated. However, if I don’t want it to be federated, if I want to use standard authentication with the subdomain, then I have a problem.
There is no way to set up the subdomain for standard federation as there is no way for me to separate out the subdomain from the primary domain’s namespace and, therefore, from the primary domain’s federation. The only option open to me is to break my federation on the primary domain (revert to standard), remove all objects from the primary domain then delete the primary domain! This removes the namespace for the primary domain and I can then add in one or more subdomains as each subdomain will be created with its own namespace. I can then go back and recreate the primary domain and reset my federation.
As you might imagine, this could be terribly disruptive, even catastrophic to users in the primary domain! Therefore, you need to give careful consideration to the order in which you plan to bring domains onto your tenancy. If you have a primary domain and a number of subs then you should consider bringing the subs on first then bring on the primary. You might also consider your overall strategy for federation — do you really need different authentication strategies across your various domains?
When in doubt your best course of action is to engage with Office 365 support before you make the jump! It is much easier to plan and execute rather than to fix, backfill and fix again if you have not planned.
A consultant once told me that I shouldn’t rely on the independence of the domains if I was to setup a subdomain before the primary–meaning the subdomain could take on the inheritance of the primary domain as this is the design and intent of O365. Any truth to this? Should I worry?
John:
I will admit up front to not having a lot of experience in this area other than the basics I have outlined in this article. I *believe* that if you add the sub-domains first (they each end up with their own namespace) then add the top level-domain that there will be no inheritance transferal, everything will be separate. BUT, I would run this past O365 support first to be 100% sure. You are better off to run it past them and, if necessary, pay a support fee rather than go ahead and do it then have to untangle the mess. One thing I do know for sure, there are things that become irreversible in O365 that can mean needing to kill the tenancy and start fresh. So, like a carpenter, measure twice and cut once … run it past support!
Is it possible to use different ADFS for the subdomain ? for example, If i am using “ADFS1” for contoso.com then can i use “ADFS2” for jobs.contoso.com ?
Thanks,
Hi, Himal:
Oh my, I honestly don’t know. Your best bet is to contact O365 support on this one. I suspect that there may be a way to do it but I also suspect there will be many hoops to jump through to get there.
Robert