Comparing Single Sign-On Options with Azure AD Connect

Azure AD Connect offers customers a number of ways to enable a “Single Sign-On” (or SSO) experience for users. I think it is important to understand the differences in these options, so that when you deploy Azure AD Connect into customer environments, you can pick the right solution to suit the business needs.

But before we go there, I want to distinguish between a couple of things first. It seems that everywhere I turn lately, people incorrectly reference SSO–for example they may say that they have “single sign on” simply because they have password synchronization enabled (sometimes via Azure AD Connect, and other times via the Windows Server Essentials / Azure AD integration features). NOTE: this statement is not accurate, properly speaking.

Single Sign-On is an experience, wherein a single logon event (like logging into your local workstation) will automatically qualify you for login to other, disparate systems (e.g. Office 365)–in other words, you have all the tokens, exchanges and mechanisms in place that are needed just from your primary logon event. From the user’s perspective: after signing into the local Active Directory network on their workstation using a corporate email address, they might then open a web browser, point it at https://mail.office365.com, and automatically be signed into their Office 365 mailbox, without having to provide credentials a second time. This is (so to speak) a “true” SSO experience.

When you are merely synchronizing passwords between the on-premises AD and Azure AD, then you really have “same sign-on,” not “single sign-on.” It just means you can use the same password on-premises as you do in the cloud, to access your corporate resources.

There are three primary methods we can use to achieve “true” SSO:

1. Password Hash Synchronization with Seamless Single Sign-On enabled
2. Pass-Through Authentication with Seamless Single Sign-On enabled
3. Active Directory Federated Services

I am actually going to start with this last option, which was in fact, the original. Many early adopters of the 365 platform ended up with this type of configuration.

Active Directory Federated Services (AD FS)

With AD FS, you need to deploy an on-premises service called Active Directory Federated Services, and it’s best if you make this service highly available. In this configuration, passwords never leave the on-premises Active Directory.  When someone attempts to sign-in to the Azure AD application, there is a configuration bit in the tenant that says “I’m not in charge of authentication, I have to go check in with <insert corporate AD FS web address here>.” This is super cool for security and compliance, because all authentication attempts are still logged against the local Active Directory.

But it is super uncool for many small businesses, because it requires setup and installation of AD FS, which also means that the cloud-based applications are dependent on the local Active Directory. So, if the corporate internet connection is down, so is your email. Wait a minute… why did we move our email to the cloud again? To prevent this scenario, our design would need to include:

1. Properly configured AD FS infrastructure with SSL Certificates
2. At least 2x AD FS web servers on separate links/ISP’s for HA
3. Planned recovery from total loss of this site/infrastructure

Not a popular option for these reasons (complexity + dependency).

Pass-Through Authentication with Seamless SSO

Pass Through Authentication or PTA is the simplified cousin of AD FS. It works both very similarly, AND very differently from the above solution.

Similar to AD FS, it means that all logins rely on the local Active Directory for authentication and sign-in–we still have that same annoying dependency. However, because the cloud authentication takes place via the local Azure AD Connect service, and does not require a complex AD FS server infrastructure or SSL certificates, it might be preferred in some scenarios. You would still want the redundant ISP links, but there are no additional requirements. Therefore, if you are faced with the challenge of keeping passwords and authentication events on-premises, and the customer also wants to keep the complexity down with a lighter on-premises footprint, then PTA is your best option (be sure to also enable SSO in the AAD Connect configuration wizard when choosing this option).

Password Hash Sync with Seamless SSO

This last configuration is the one I recommend for most small businesses that do not have special compliance requirements. In this model, there is no on-premises dependency–you have authentication taking place on-premises, AND in Azure AD. Via password hash synchronization, the local AD passwords are salted, hashed and synchronized to Azure AD. Additionally, you can enable the Seamless Single Sign-On option, and corporate desktop users (Windows 7+) will have the same SSO benefits (there will not be further credential prompts to use Outlook, OWA, other apps, etc.). The best part? If your local on-premises systems or internet connection is down, users can continue working in their cloud apps, without noticing.

If you already have PHS, but haven’t enabled Seamless Single-Sign On, then you will not have the “true” SSO experience. However, it is very easy to get this up and running, see here for how to do this, step-by-step. Oh yeah, you can optionally configure password write-back for self-service password resets.

Other considerations

There are a couple of other considerations that might come into play. Most notably, the only solution here that supports the on-premises Multifactor Authentication Server is (unfortunately) AD FS. It is still possible to enable MFA for cloud-based applications using Azure AD MFA provider with the other options, but you do not have the ability to bring MFA to your network locally, without AD FS. Just something to be aware of.  On the flip side, it is worth noting that Azure Identity Protection (which requires additional licensing, e.g. P2) is not compatible with AD FS (because the authentication attempts must happen against Azure AD for Azure ID Protection reports to work).

Another consideration that applies only to PHS w/ SSO enabled: there may be a delay between, for example, disabling an account on-premises, and having that change updated in the cloud (because AAD Connect only synchronizes every 30 minutes by default). Furthermore, users who have passwords synchronized to Azure AD will technically have their cloud passwords set to never expire, and the password policies that apply on-premises will control when they need to update their password–but it is enforced on-premises only. Therefore it is possible, for example, to sign-in to cloud-based resources, even if the password on-premises has expired, because until the user changes the on-premises password, the old value will not be overwritten in the cloud.

There may be other small differences, but these are the noticeable ones that matter most to small businesses. I have summarized all of these points into this table for ease of reference: