Office 365 allows for different identity management options, each of which has its merits. Let's look at one option -- Active Directory Federation Services -- to get a better understanding of how it works and how to install it.
Unlike cloud identities or regular synchronized identities, these identities authenticate against an on-premises Active Directory through an ADFS server infrastructure instead of Windows Azure Active Directory. This means end users log in to Office 365 with their on-premises credentials.
To understand how ADFS works, let's look at what happens when a federated user tries to log into Office 365 (Figure 1):
- An end user tries to log into Office 365 using his user principal name (UPN).
- The authentication platform verifies the UPN and sees that the end user is a federated identity. It redirects the authentication request to the end user's ADFS server. The platform knows the URL because a trust was set up earlier between the ADFS infrastructure and Office 365.
- The client connects to the ADFS proxy and provides credentials.
- The ADFS proxy or another support proxy appliance/device forwards the authentication request to the ADFS server.
- The ADFS server verifies the credentials with the local Active Directory.
- When the credentials are verified, a domain controller returns a Kerberos token to the ADFS server.
- The ADFS server disregards the Kerberos token and crafts a new ADFS token, which it forwards to the ADFS proxy server.
- The ADFS proxy server forwards the ADFS token to the client.
- The client presents the ADFS token to Office 365 and is authenticated.
A note about Outlook authentication
Outlook authentication is slightly different. Because Outlook doesn't know how to work with ADFS, Exchange Online will connect to the ADFS server infrastructure instead of the Outlook client. This is referred to as an Active authentication flow, while the above process is a Passive authentication flow
The ADFS installment process
The process of installing ADFS consists of three distinct steps:
1. Enable and set up directory synchronization. This ensures that on-premises end-user accounts are synchronized to Office 365 in a consistent state.
2. Ensure your on-premises end-user accounts are configured with an Internet-routable UPN. This means you can't use a UPN that uses .local, .corp or any other internal domain name. The domain name(s) you use must also be configured and verified in your tenant. For example, Joe@mydomain.local would be an invalid UPN, but email@example.com would be valid.
3. Configure a trust relationship through PowerShell between your on-premises ADFS infrastructure and Office 365 -- assuming you already have deployed a server with the ADFS server role.
Caveats and considerations for an ADFS installment
There are some important things to keep in mind when you deploy ADFS:
Prerequisites. Be careful if using an Internet-routable domain name for your user's UPN. Creating new UPNs is relatively simple and usually low-impact, but your company might be using applications with hard-coded reference UPNs. Verify this to make sure ADFS with Office 365 will work.
High availability. Once you configure ADFS, high availability becomes extremely critical. If your ADFS infrastructure is unavailable, end users won't be able to log in to Office 365 services. Make sure your infrastructure is highly available to prevent any problems.
Configuring ADFS to be redundant is simple -- instead of selecting a standalone federation server during setup, choose to run a federation server farm. However, installing an ADFS farm has its own considerations.
Windows Internal Database or SQL? ADFS is installed with a Windows Internal Database by default, which is just fine for most companies. You can also configure an ADFS farm using the default Windows Internal Database. The first server is automatically designated to be the primary ADFS server. Subsequent servers you add to the farm will automatically pull configuration information from the primary server and continue to do so every few minutes.
The downside to this approach is that you only have a maximum of five servers in the farm. And when the primary ADFS server fails, you can't make any ADFS configuration changes until it's back online. Other ADFS servers will continue to service requests, but this might prove challenging, especially when the primary server is beyond repair.
As an alternative to the Windows Internal Database, you can also choose to use a SQL database for ADFS. This requires some additional work during setup, but you can leverage SQL for high availability, and there are no primary or secondary ADFS servers in the farm. Using SQL also means you can have more than five servers in a farm and leverage additional ADFS features such as SAML artifact resolution; this feature isn't used with Office 365, but could be important if you want to use ADFS with other applications.
Topologies. Another important piece to the puzzle is choosing how your ADFS topology will look. You should deploy ADFS across multiple data centers to make sure it's highly available. If you can't, consider de-duping your Internet connection. Given that some organizations might not have a second location, you can use third-party data centers, or even Infrastructure as a Service providers such as Windows Azure, to host some of your ADFS infrastructure.
Load balancing. Choosing the right load-balancing options is also important. Although ADFS can work using DNS round robin, this load-balancing mechanism offers only limited value when one of the ADFS proxy servers fails. In such a case, a manual intervention is required to remove the DNS record for the failed server. Clients either have to wait for the TTL of the record to expire or will have to clear their DNS cache manually. Load balancing with a tool that can do the necessary health checks is better, but it requires you set up redundant virtual devices. This likely will cost more and be more complex to manage.
Click here for part two of this article, which covers the typical operations related to using ADFS and how to troubleshoot it.
About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects podcast.
This was first published in January 2014