So, you are looking to federate the Office 365 default domain for one reason or another, and - surprise... it's giving you some issues. It's to be expected; many major application or service providers will impose their own restrictions on how they support things like Single Sign-On and federation. The very same is true when it comes to federating the Office 365 Default Domain.
Office 365 Federation can be a real pain to implement for any organization. Microsoft’s own TechNet website refers to the process as “[seeming] like more trouble than it’s worth”. Office 365 integration becomes even more difficult to manage when multiple domain federation is required. Historically, Microsoft requires that each domain be federated using specific ‘issuer’ values. With regards to true Single Sign-On, this is far from an ideal solution.
Fortunately, all hope is not lost!
As you may already know, federated authentication allows end users to maintain a single set of security credentials for each of the protected web apps that they access. For organizations utilizing services like Google, Blackboard, SharePoint and Office 365, federated authentication is a major draw from both a usability and security perspective. Only needing to use and remember a single username and password is just one of many benefits to federated authentication. For example, once a session has been established with the Identity Provider (IdP), the user can navigate to additional web apps that are also federated with the same IdP, without the hindrance of prompting for credentials again – this is known as Single Sign-on or SSO.
Why Use Multiple Office 365 Domains?
Firstly, this is a valid question. Most people don’t even realize that multiple domains might be a necessary consideration for Office 365 federation. However, when this scenario rears its head, the necessity can lead to high levels of frustration and sacrifices to usability for the sake of functionality. All of these result in a marked decrease in productivity and user adoption for any environment.
The most obvious scenario where Office 365 federation to multiple domains would be useful is for higher education institutions. Office 365 domains are most often differentiated based on individual user groups. For example: students have a single Office 365 domain while faculty, staff, and administrators have another. The multiple domain problem arises when an institution wants to provide access to these domains from a single point.
Natively, Microsoft does not provide the functionality for multiple domain federation in Office 365. As a result, it is not uncommon to see a website with a unique login portal for each individual domain. While functional, this solution is by no means ideal.
Benefits of Office 365 Federation for Multiple Domains
The primary benefit for solving the Office 365 federation issue with multiple domains is through usability and consistency. End-users become far less frustrated when the process of logging in to Office 365 is streamlined and not particularly annoying to manage.
Additionally, using Office 365 federation for multiple domains provides additional opportunities to streamline things on the IT administration side. Typical solutions to this problem will involve a dedicated Identity Provider (IdP), which improves and simplifies control over various web applications – Office 365 included.
Not only do administrators reap the benefits of improved productivity and a happier user-base, but they are also able to redirect their time and efforts to more necessary and pertinent issues. The use of a properly configured Single Sign-On IdP takes the stress of problems such as Office 365 federation and simplified authentication and replaces it with freedom and peace of mind.
Enough about Federation. What IS Office 365 Default Domain?
Now that we've got the basics covered, here is the root of the problem: the Office 365 default domain itself.
The login to Office 365 is performed with an email address which consists of a username before and a domain name following the ‘@’ sign – username@domain.com. Office 365 uses the domain name part of the login name to determine how to authenticate the user. If the domain is federated, Office 365 will redirect the user to the registered IdP for authentication.
After federating an Office 365 domain, the only way to authenticate a user in that domain is through the Federation Identity Provider. Should there be a problem with authentication through the IdP, even the administrator of the default domain would not be able to gain access to make any adjustments. For this reason, the Office 365 default domain cannot be federated. In fact, attempts to federate the Office 365 default domain will result in an error. This guarantees that the administrator from the default domain will always be able to login to Office 365.
Businesses with only a production Office 365 default domain have been getting hung up trying to test Office 365 federation.
Solving the Problem and Looking Ahead
Recently, Microsoft adjusted the protocols for Office 365 federation. Office 365 now checks the ‘issuer value’ presented in SAML responses for federated SSO. While this change further interrupted many SSO solutions for multiple domains in Office 365, IdP’s such as PortalGuard are now configurable to optionally override the ‘issuer value’ for each SSO Relying Party. With such a configuration in place, organizations from any vertical can integrate multiple domains with Office 365 federation – all without sacrificing the usability inherent in true SSO.
So, when considering bringing your Office 365 into the SSO world, make sure to plan for at least one domain other than the default domain provided with your Office 365 service plan. You will need it for federation for Office 365, as federating the Office 365 default domain is expressly forbidden.
The ideal solution is a product that can create a single or federated authentication process to handle multiple local and cloud applications, while providing a centralized point of secure access. Implementing a SAML (Security Assertion Markup Language) SSO option with PortalGuard as the Identity Provider achieves the goal of eliminating password issues while providing more:
- Reduce the number of passwords users are required to remember and manage.
- Implement and enforce configurable password policies.
- Reduce password-related Help Desk calls related to password and access issues, and many more.
Read more about the benefits of an SAML SSO option in our eBook here.
