Three years ago and even earlier, when the first waves of medium to large organizations decided to migrate data off one or more of their Microsoft on-premises infrastructure solutions to their respective counterpart workload in Office 365, some of the most important requirements were that end users were provided with a single sign-on (SSO) experience when accessing these workloads and on top of this, that the solution was as secure as possible. Said in another way, the end users should be able to access their data in Office 365 using their existing Active Directory credentials while the organization at the same time should be able to configure complex and often granular policies to provide the most optimal security for end users and devices. The only Microsoft-based method to accomplish both goals was for the organizations to deploy a highly available federation solution based on Active Directory Federation Services (ADFS). The solution needed to be highly available as it was a critical component in the overall hybrid identity solution. If ADFS was unavailable, end users would not be able to access their data in Office 365.
For an ADFS solution to be highly available, you would need to deploy a minimum of two ADFS servers on the internal network and a minimum of two Web Application Proxy (WAP) servers in the perimeter network. If the organization wanted a solution that was both datacenter-resilient and highly available within the datacenters, they would need a minimum of four ADFS servers and four WAP servers.
Even though one of the most important reasons why organizations deployed an ADFS-based federation solution was to provide end users with the best seamless SSO authentication experience and at the time best security, there were still workloads that did not offer a true SSO experience even with ADFS in use. The most notable was without question that an Outlook desktop client connecting to Exchange Online only supported basic authentication. It also used something called proxy authentication, which meant Exchange Online did the authentication with ADFS on behalf of the client. For this reason, end users were prompted for credentials after their mailbox was migrated to Exchange Online and they had to store these credentials in Windows Credentials Manager in order to not be prompted every time the Outlook desktop client was launched. In addition, end users would be prompted every time their password was changed. As an independent consultant as well as Microsoft FTE, I had a lot of negative feedback around this limitation. And I totally understood the frustration. This was not a good story at all!
Flashback to 2015
If you want to take a walk down memory lane, back in 2015, I covered the different identity models we had back when the majority of Enterprise organizations decided to start their Office 365 journey.
As you may be aware, at the time, the alternatives to ADFS were cloud identities or password hash synchronization (PHS). Cloud identities were, of course, a huge “no-go” as they did not provide SSO but instead introduced an additional set of credentials. PHS did allow users to authenticate using the same set of credentials, but this was more seen as a “same sign-on” rather than a “single sign-on” solution. In practice, this meant end users would be prompted for credentials the first time they accessed a workload on each workday or when the respective tokens expired. Most organizations also viewed PHS as an insecure solution even though it really was not the password itself but a hash of the hash of the password, which was synchronized to Office 365. Later, PHS was enabled by default when organizations installed Azure Active Directory Connect (AAD Connect) so that it could be used as a failover solution in case ADFS was unavailable for a longer period of time.
Over the last couple of years, organizations have realized that ADFS usually is overkill when it comes to providing an SSO solution to their end users. I still see some organizations using ADFS to fulfill very specific requirements stated in the IT security policy. However, nowadays there is rarely a reason to use it when it comes to authenticating with Office 365 and other SaaS services.
Over the years, Microsoft has also done an excellent job to have organizations reconsider whether ADFS is the right solution. The first big thing was the introduction of ADAL support in Office 2013 and later, which among other things removed the Outlook desktop client credential challenges by having the client act the same way as a browser-based client when authenticating. ADAL uses the OAuth2 protocol and Microsoft also enabled OAuth2 support in all other Microsoft clients such as the hugely popular Outlook mobile client.
PTA: A new hybrid identity authentication model
In addition, Microsoft introduced a brand-new hybrid identity authentication model known as pass-thru authentication (PTA) and a new AAD Connect feature referred to as Seamless Single Sign-On.
Pass-thru authentication is based on an agent, that is automatically installed on your AAD Connect server when the option is selected during installation or later on. For high availability, you can install the PTA agent on an additional domain member server in your on-premises Active Directory domain. PTA is an alternative to PHS and suited for organizations that want to enforce their on-premises Active Directory security and password policies without using ADFS. PTA has several benefits over ADFS, such as no servers required in the perimeter network and no URL or port publishing to the Internet since all traffic occurs over outbound sessions from the PTA agents. The authentication flow for PTA is depicted below.
Making SSO ‘seamless’
Seamless Single Sign-On (SSSO) is as the name indicates a feature that automatically signs users in when they user their corporate devices from the corporate network. When enabled, the end users do not need to type in their passwords to sign in to Azure AD. SSSO is not a standalone feature as such. It is a feature you enable so that it can work in conjunction with either PHS or PTA. Bear in mind, it does not work with ADFS.
SSSO can be used together with PHS, and this means your users no longer are repeatedly prompted for credentials during a workday. When accessing Office 365 or other Azure AD SaaS services, I personally recommend using PHS over PTA unless you have specific requirements that only can be fulfilled using PTA.
If you miss a nice comparison chart of the identity scenarios with pros and cons of each, I highly recommend you check out this blog post by one of the program managers from the Identity Services team at Microsoft.
Lastly, Microsoft put a lot of effort into evangelizing their own field technical consultants/specialists as well as Microsoft partners via blog posts, training, conference sessions, and partner material to ensure that they recommend the best authentication model for the customer scenario at hand. In the past, everyone (including Microsoft folks) praised ADFS over anything else.
Okay, so I understand what you are saying: “My organization is currently using ADFS, how do I switch to PTA or PHS with SSSO?”
I will not go into the specifics on how you convert from ADFS to PHS or PTA in this article. Instead, I recommended you read these two comprehensive and excellent white papers over on GitHub, which were written by and are kept up to date by folks from Identity Services team at Microsoft.
This article is the first of several I intend to publish over the upcoming months. Now that we have covered the on-premises hybrid identity side of things or more specifically how it can be simplified without end user noise and/or reduced security, we will move on and concentrate on the Azure Active Directory security features that can be used to implement optimal identity-related security for your organization.
Featured image: Shutterstock