Just as most of us were getting ready for Christmas 2016, Microsoft announced to relatively little fanfare a new way to configure authentication in Office 365. From a technical point of view this is perhaps one of the most significant Office 365 developments of the year and one that neatly addresses one of the difficult decisions to be made when implementing Office 365.
First, some background. Since Office 365 was born, one of the first things to consider in any implementation is how identity and authentication are handled.
In the same way that, for example, Exchange needs to use Active Directory to find out about users and other objects, Exchange Online in Office 365 needs to look to a directory. Office 365’s directory service is called Azure Active Directory (AAD) and, for the majority of established businesses with an existing on-premises Active Directory (AD), synchronisation between AD and AAD is one of the first steps in any Office 365 project.
Having established a way of dealing with identity, authentication is next. Sometimes these terms are used interchangeably by IT pros, but simply put:
· Identity… who are you?
· Authentication… now prove it.
The authentication piece has always been one where none of the available options really ticked all the boxes. There was always a compromise. In terms of technology, the choice was to synchronise passwords (or, strictly speaking, cryptographic hashes of passwords) with AAD, or to use a piece of technology called AD FS (Active Directory Federation Services) to make the authentication happen on-premises.
AD FS has been around since long before Office 365 and was designed to allow organisations to federate multiple Active Directories. It was never really a great fit for Office 365.
AD FS enables desirable options such as single sign-on and multi-factor authentication, but at a price and that price is complexity and the introduction of a single point of failure. If your AD FS infrastructure were to be unavailable, users would simply be unable to log in to any Office 365 resources. Making AD FS resilient against loss of a physical site or connectivity was complex and too costly for the majority of organisations.
What Microsoft have introduced with the new option (Pass-through Authentication) is a way to have the advantages of AD FS but without the increased complexity. The feature is currently in technical preview, meaning that it is available for anyone to get comfortable with in a test environment but it should not yet be used in real production environments.
In terms of the network connectivity, AD FS accepts inbound connections from Azure AD. That means there are firewalls, network load balancing, DNS, and a host of other considerations. There is also a typical minimum requirement of four servers, purely for AD FS.
With pass-through authentication, a long-running network connection is established outbound from your network to Office 365, with no extra certificates to purchase, or inbound firewall rules to configure.
The latest directory synchronisation tool (Azure AD Connect) simply has a new tick-box and wizard to enable the feature. Additional lightweight “connectors” can be set up to provide resilience, and there is no need for complexities such as load balancing or proxy servers in a DMZ.
If you are in the fortunate position of having multiple physical sites with AD domain controllers, you can configure additional connectors to provide resilience against a single site or internet link going down.
It’s simple, flexible, and in our testing in the lab, it just works!
To read Part Two of the series, click the button below: