This blog post covers the integration methods for allowing administrators to authenticate their Office 365 users using on-premises Active Directory Domain Services (AD DS), particularly focusing on the method which involves utilizing Active Directory Federation Services (AD FS).

This post is not intended as a step-by-step guide on how to implement integration between Office 365 and the on-premises Active Directory Domain Services!!!  It’s only intended as a high level overview.

By default, Office 365 utilizes Azure Active Directory for user authentication and authorization, and it involves creating a separate cloud identity for each user on Office 365.  This is not ideal for organizations managing on-premises AD DS, as it creates additional management over head for administrators, and poor end-user experience due to the lack of Single Sign-On (SSO) capabilities – users end up with a cloud identity and a on-premises identity.

Luckily Microsoft allows organisations to integrate their on-premises Active Directory Domain Services with Azure AD, by configuring SSO using a tool (provided by Microsoft) called Azure AD Connect.  This tool is deployed in the organisation’s environment and carries out directory synchronization between the on-premises Active Directory server and Azure Active Directory.

Azure AD Connect allows a variety of SSO deployment methods:

• Password Sync – Users are able to sign in to Office 365 using the same password they use in their on-premises network. The user passwords are synchronized to Azure AD (using Azure AD connect) as a password hash and authentication occurs in the cloud.
• Pass-through Authentication – Users are able to sign in to Office 365 using the same password they use in their on-premises network. The user password is passed through to the on-premises Active Directory to be validated. Azure AD Connect is only used to create the user identities on Azure AD, password hashes are not synchronized – however passwords are passed on to the on-premises AD over the internet.
• Federation with AD FS – Users are able to sign in to Office 365 using the same password they use in their on-premises network. The users are redirected to their on-premises AD FS instance to sign in and authentication occurs on-premises. Azure AD Connect is only used to create the user identities on Azure AD, password hashes are not synchronized.

The first two SSO deployment methods can be used if budget is an issue, the last option i.e. Federation with AD FS will incur more Microsoft licensing costs and potentially more compute resource, however it is the most secure, as the user account passwords are kept on the on-premises environment.  This method requires a trusted SSL certificate to be installed on the AD FS server to create the required Federation Trust.  Also note that if the internal domain name of the organisation differs from the external domain name that is used as an email address suffix, the external domain name will need to be added as an alternative UPN suffix in the local Active Directory domain.

1.  An end user tries to log into Office 365 using his / her user principal name (UPN).
2.  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 AD FS server. The platform knows the URL because a trust was set up earlier between the AD FS infrastructure and Office 365.
3. The client connects to the AD FS server and provides credentials.
4. The AD FS server verifies the credentials with the local Active Directory.
5. When the credentials are verified, the domain controller returns a Kerberos token to the AD FS server.
6. The AD FS server disregards the Kerberos token and crafts a new AD FS token, and then forwards the AD FS token to the client.
7. The client presents the AD FS token to Office 365 and is authenticated.

With this integration method, security can be enhanced by placing an AD FS Proxy server in the DMZ which will be configured to proxy all authentication requests to the AD FS server located in the internal network – hence not exposing the AD FS server to the internet.

With larger environments, high availability can be achieved by deploying a cluster of AD FS servers in the internal network and a cluster of AD FS Proxy servers in the DMZ. This approach will also require the deployment of load balancers.