ADFS vs. Azure AD: How Microsoft has changed the authentication game

When Microsoft launched Office 365 in June 2011, one of the early requirements was to provide some form of single sign-on for corporate users who were accessing the platform from within an AD domain.

This involved linking Azure AD to the federation service provided via ADFS and the on-premises AD.

Since then, cloud adoption has had a huge influence on the way modern organizations authenticate users. Any reliance on on-premises functionality has become a hindrance, rather than a help.

As such, more and more organizations are looking for ways to free themselves from the trappings of legacy tech and take advantage of the Cloud without causing unnecessary disruption.

But that’s not to say existing methods don’t have their uses, the ultimate advantage of the Cloud is having the flexibility to select the methods that best meet your needs, so let’s examine how cloud authentication solutions have evolved over the years, and the benefits they bring.

From ADFS to Azure AD Connect – and cloud authentication

The first cloud authentication option (although not our preferred approach) was utilising the “password hash sync” feature of Azure AD Connect, allowing users to authenticate directly in the Cloud. However, if this happened the users would not be able to have single sign-on.

Since the user experience is important to ensure that the services are adopted, providing single sign-on, based on the password hash approach, was a major problem. Therefore, many organisations across the world deployed ADFS to ensure that users could access Office 365 services as easily as possible.

Two years ago, things started to change when Microsoft began to create different methods of single sign-on available alongside newer methods of authentication.

Pass-through Authentication and seamless single sign-on

One of these methods was Pass-through Authentication (PTA). PTA integrates a web sign-on to Office 365 with an authentication request sent to the AD domain controllers.

This means that the user completes the sign-on form in Azure, but the ID and password are still validated by AD after passing through the Azure AD Connect server. When Microsoft developed this, they also came up with a new improved method for providing single sign-on.

This new “seamless single sign-on”, allowed Azure to accept a Kerberos ticket for the authentication. This Kerberos token is linked to the original AD where the user authenticated and can be passed to Azure for validation. This meant that a user who signs in on-premises and then tries to access Office 365 can be authenticated with the Kerberos token, simple and secure.

However, PTA does still require an on-premises component. This is initially installed as an agent on the Azure AD Connect server, but can also be installed on additional servers to provide greater availability – Microsoft recommend at least three authentication agents on three servers for PTA.

It’s this on-premises requirement that could be problematic. Should the Internet pipe fail, then there will be no access to Office 365 until either authentication is switched to cloud only, or the Internet connectivity to the authentication agents is restored.

Best of both – A hybrid solution

To avoid this situation, there is now another option. Utilising password hash sync (PHS) means that a user can always authenticate directly against the Azure AD.

This is the best method of providing consistent access to the Office 365 environment, but would seem to remove the single sign-on facility needed by the users.

In this case though, the PHS can be supplemented by the seamless single sign-on facility. Azure AD can accept the same AD based Kerberos token and doesn’t require the user to enter their ID and password.

On-premises users gain access using seamless single sign-on, while users who are elsewhere would require the correct ID and password combination to access the services.

In this scenario, there is no reliance on any on-premises environment, in the event of an internet failure, any external users will still be able to authenticate. If the internal AD fails, the users will still be able to use their ID and password to access, even though the Kerberos token is not available.

Find what works for you

More recently (February 2019), the NCSC have changed their advice on securing Office 365 to use “cloud-native authentication”. This means implementing PHS and seamless single sign-on. The full document can be found here.

For many organisations, this means moving from an ADFS implementation, to using PHS and seamless single sign-on.

The change in both synchronisation and authentication should be approached with a degree of care to ensure that any downtime is minimised.

Of course, this only removes the Office 365 authentication requirements from the ADFS environment and does not remove any other reliant parties, although most of these should be able to be moved to Azure AD when appropriate.

Moving from ADFS to password hash sync with seamless single sign-on can seem a bit frightening, but Kocho can help accelerate the migration process.

Getting expert advice on the best method of authentication for your specific organisation is important, as ADFS still has its uses and may turn out to be the best option in some circumstances.