Addled by ADFS? Puzzled by password hash sync? Perplexed by pass through authentication? Let’s explore how Azure AD is leaving on-premises authentication behind.
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.
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.
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.
Don't be a slave to ADFS and on-premises authentication processes. Watch this short video now to:
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.
At this point, it may be worth looking at the relative pros and cons of the three authentication methods.
These functions would seem to indicate that ADFS is still a good choice when authentication is required to be only on-premises (and not entered into a cloud-based web page), or when determining whether a user’s device is internal or external.
For all other cases the use of PTA or PHS would be preferable. Since PHS provides better availability and has no reliance on on-premises elements, it is generally the recommended method for authentication.
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 ThirdSpace 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.
Be sure to watch our short video to get more detail on why many are making the jump to cloud-based authentication.
Submit your business email to join our mailing list and we'll send you 'A buyer’s guide to Microsoft Enterprise Security'.
As ThirdSpace’s Solution Architect and Technology Evangelist (yes, he knows it’s a long title), Dave has a background in IT that goes back to installing a piece of kit called a Microsoft Softcard in...
READ AUTHOR'S FULL BIO
Understand best practice approaches for migrating your authentication.Watch now
Send us your questions or feedback.
Friendly folks are standing by!
Eight-time winner of the Microsoft Partner of the Year Award for Identity Management, Enterprise Mobility, and Security and Compliance.
You are seeing this because you are using a browser that is not supported. The ThirdSpace website is built using modern technology and standards. We recommend upgrading your browser with one of the following to properly view our website:Windows
Please note that this is not an exhaustive list of browsers. We also do not intend to recommend a particular manufacturer's browser over another's; only to suggest upgrading to a browser version that is compliant with current standards to give you the best and most secure browsing experience.