One of the first conversation and decision areas I have when talking about adopting Azure AD (AAD) based services with customers is how are users going to authenticate to it.

Historically, we’ve had 3 options:
1) Cloud Only – Accounts that only exist in AAD and are authenticated by Microsoft services
2) Password Synchronisation – Account information and passwords are synchronised from local Active Directory to AAD, Microsoft services then perform authentication against these details
3) Federated – Account information is synchronised from local Active Directory but AAD services redirect users back for authentication

Since most organisations have a well-established Active Directory environment already populated with users and processes in place for managing the lifecycle of the account discussions would naturally focus on the two synchronisation based options.

The main sticking points would then usually be around where the authentication takes place and the resiliency required to provide it. Using the password synchronisation option, once it had been copied to AAD there would be no further dependencies on the customers environment for users to authenticate against AAD until the user changed the password.

The problem with Password Synchronisation is that it doesn’t provide Single Sign On but rather Same Sign On, both confusingly shortened to SSO at times. Recent improvements with the AAD authentication service have seen prompts for re-authentication reduced but users are still required at some point to enter their password.

Enter Active Directory Federation Service (AD FS or ADFS) Microsoft’s Claims-based authentication service capable of providing the federated and Single Sign On experience with AAD (and other applications). With AD FS a customer controlled solution would authenticate users without the need to copy passwords to a 3rd party (AAD) along with providing integration with 3rd party Multi-factor Authentication (MFA) solutions.

AD FS has to be made accessible from every network location a user will be connecting from and whilst most organisations use a form of VPN connectivity for remote access from laptops most mobile devices will be connecting over public networks, requiring the federation service to be exposed to the internet which then introduces concerns around security.

Federation has been the approach favoured by most UK public sector organisations I’ve worked with as they would often quote the CESG (now part of the National Cyber Security Centre) guidelines on Office 365 which recommended the federated approach to keep authentication directly against AD.

The downside to federation is that it requires, a minimum of six servers to provide a redundant service, two Azure AD Connect servers (Active/Warm standby), two AD FS servers and then two AD FS Proxies (WAP) servers to make it externally accessible. Adding in load balancing and Public IP addressing this approach starts to get complicated.

Enter Azure Active Directory Pass-through Authentication, using AAD Pass-through Authentication the password is entered on an AAD sign-in page and is then encrypted ready for retrieval in a private queue. An agent on the AAD Connect server will connect outbound to the internet (no inbound connection is required) to check for waiting authentication requests and will then validate them against the local AD before passing the result back to AAD. Using Pass-through reduces the footprint required as you’d need just a minimum of two servers to provide high availability and with no incoming internet access required it should please the network security team.
To support Pass-through Modern Authentication is required so desktop clients should be running Office 2013 or above (after all Office 2010 ended mainstream support in 2015) and any Skype deployments should be configured for Modern Auth.

AAD Pass-through Authentication on its own provides Same Sign-On but without any copying of passwords, to get true Single Sign-On we also need to use Azure AD Connect’s Seamless Sign-on feature. Seamless Sign-On allows a domain joined machine connected to the internal network to request a Kerberos ticket and authenticate to AAD without the user having to re-enter their password (entry of usernames depends on how the service is accessed) and mimics the SSO experience provided by AD FS.

The result of using AAD Pass-through Authentication and Seamless Sign-On is that we can reduce the footprint needed for AAD authentication to two servers for high availability (more agents can be deployed if required) and we no longer need to expose our authentication environment to the internet.

Does this mean you can just replace AD FS for AAD authentication and make the network security team happy by closing down incoming traffic? Well for the most part yes, Microsoft has worked to resolve most of the initial unsupported scenarios and now the only true blockers to the new approach would be if Office 2010 is still used, or if 2013 doesn’t have Modern Authentication enabled. You would also need to keep AD FS if still running Lync 2013 Server or Skype for Business Server without Modern Authentication enabled but hopefully you’d be looking at upgrading or migrating fully online.

Other reasons to currently keep using AD FS for AAD authentication include if you are still using 3rd party MFA solutions since as at the time of writing these are only supported when using AD FS, in which case you should evaluate a move to Azure MFA. AD FS can still provide authentication to SaaS/SAML applications however since AAD can provide this functionality to a constantly growing number of applications it should be the first port of call when looking to introduce a new application.

As someone who as deployed a fair few AD FS solutions over the years I’m a little sad to see the need for it reduce but the benefits of the new approach means a faster adoption of AAD services and a reduced number of servers to maintain.

About the author