Just before Christmas, Microsoft announced the preview availability of Azure Active Directory Pass-through Authentication. Whilst on the surface this does not sound like a ground-breaking product release, it has the potential to massively reduce the complexity involved in deploying authentication mechanisms between on-premise Active Directory and Azure / Office 365 services.
Let's roll things back a bit. One of the first steps we take when on-boarding our customers to Office 365 is discuss their authentication requirements. When an organisation first signs up for the service they will be provided with an onmicrosoft.com domain. This means that their users will sign in with an account such as:
Not very user friendly - if only because this doesn't match their preferred email address - expect lots of calls to the helpdesk with forgotten credentials. So the first thing we do is register the company domain name with Office 365. We can then give users a sign on name such as:
Much better, however this then brings up two further challenges:
Both these problems are conveniently resolved through the same solution. The Azure Active Directory Connect tool can be installed on a server in your environment and will quietly synchronise on-premise AD accounts up to Office 365 or Azure Active Directory. This will auto provision an account in the cloud for each user in scope - ready for IT to assign them a licence. It can also solve the password issue by sending a hashed copy of the local password to the cloud so that users can sign in both locally and to Office 365 with the same username and password.
For many organisations this is a suitable solution - straightforward to implement and simple to maintain, however, there are some customers who require that authentication always occurs against their own domain controllers. This may be for governance reasons that prohibits passwords being sent to a third party because they have security concerns caused by potential delays in locally locked or disabled users synchronising their status to the cloud.
The solution to this has been Active Directory Federation Services (ADFS). This is a role in Windows Server that ensures users authenticate against a local domain controller which then issues a token to allow access to external services such as Office 365. It's a great solution, but does come at a cost, most notably the four servers that are required for a best practice implementation along with certificate and networking complexity.
Which brings be back to the point of this post. The latest preview release of the Azure AD Connect tool now has an option to allow Pass-through Authentication (PTA). This ensures that authentication with Office 365 occurs against your local domain controllers across a secure HTTPS channel. No additional infrastructure required, just a tick box.
There will be a place in the Enterprise for ADFS, such as enabling access restrictions to certain resources or federating with other providers beyond Microsoft and approved partners. But this new Pass-through Authentication will certainly hit the spot for many organisations that have these internal requirements but don't want the hassle of additional infrastructure or technology to manage.
Share this page: