Azure AD Pass-through vs. ADFS: Which do we use for authentication?

In my own blog, I am frequently writing articles about Microsoft Exchange, Exchange Online, PowerShell, and Office 365. One question I am continually asked by my readers and my customers in my work life concerns authentication and Office 365. Should they use the classical federation between on-premises and Office 365 with ADFS or is it perhaps better to look further into Microsoft’s Azure AD Pass-through?

Well, to be honest, this question cannot generally be answered! Why? Because it always depends on the company’s set up and what your goal is.

In this article, I will write about both ways you can go with. Perhaps it will help you to find the right solution in your case or how you want to work in the future. Best of all, if you are working as an IT consultant, you will be able to choose the right solution for your projects.

Authenticate with ADFS

In another article in my blog, I have described how ADFS has to be configured and how it can be personalized.

First, let us have a look at the functionality of ADFS for authentication of Office 365 services:

Employees can use their company workstation or any private device. If they are using a company workstation, they will have to log in with the company domain credentials to the workstation. If they use a private computer and want to access the company environment, they will have to first authenticate with the company environment (through the ADFS) and after that, they will be able to use all features.

The on-premises and the cloud site have configured a federation between each other that depends on the identity model. There are different ways to deal with them. However, from my point of view, one of the best ways is to use directory sync with federated identity. (This is shown in the image above.) A user of the company has an on-premises Active Directory account, which is synced to the Office 365 tenant by AAD. If the user now tries to connect to the cloud services outside of the company, he goes to the Office 365 portal and enters his company credentials. They will be controlled (authentication) from the local Active Directory through the ADFS. If all is correct, the user will be able to log in.

This principle works not just for authentication between our on-premises environment and Office 365 or Azure, it also works for many third-party cloud services such as AWS, G Suite, and Salesforce.

One of the things we have to think about with this solution is that it is highly recommended that we build the ADFS environment on-premises and that we do it redundantly. That means at least two ADFS servers and two web application proxies (WAP).

From my experience, I would say this is still the most common configuration in the field.

Authenticate with Azure AD Pass-through

In addition to my articles on ADFS, I have written an article on how Azure AD Pass-through has to be configured. Let us first have a look at how the authentication by using Azure AD pass-through works:

The user tries to access an application, for example, Outlook Web App (OWA). If the user is not signed in, he will be redirected to the Azure AD sign-in page where he will need to enter his username and password. The on-premises Authentication Agent retrieves the username and encrypted password from the queue. The agent decrypts the password using its private key and validates the information with Active Directory. If all the information is correct, Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs the user in immediately or issues a request for Azure Multi-Factor Authentication. If the user sign-in is successful, the user can access the application.

Authentication with Azure AD Pass-through is constantly being improved by Microsoft and receives regular feature updates. But I can recommend it only for use with Microsoft cloud services authentication.

The configuration of pass-through has to be made by Azure AD connect (AAD). After the configuration is made, we can connect to our Azure Active Directory and after browsing to Azure AD Connect, we see, that pass-through is enabled.

The agents for the authentication service can be installed on each server that has access to the Active Directory and its catalog and is available from the cloud side. However, if we compare it to an ADFS environment, which needs at least five servers (two ADFS, two WAP, and one AAD) and as well a load-balancer, we can save four of them with pass-through — and save the load-balancer as well.

So, Azure AD Pass-through or ADFS?

Both solutions are good. That is why I cannot make the recommendation on which of the two options you should use. However, this was never the goal of this article. It shows two ways how authentication can be handled using Microsoft tools. At the moment, I recommend to my customers that if they are using only Microsoft services, authentication with AD Pass-through is a good solution. For other companies that use cloud services such as AWS, G Suite, and Salesforce, ADFS makes more sense.

One thing to note: If you are using ADFS in your organization, the switch to pass-through is easy to do and it won’t take you much time. Going in the other direction from pass-through to ADFS is also possible, but it takes more time.

If you decide to use Azure AD Pass-through, you have to remember that setting PTA is a tenant-wide setting, so all accounts in your tenant are forced to use PTA. If something goes wrong in the network and none of the AuthN agents are available, nobody can log in anymore. Therefore, you need a cloud-only admin account with a @<tenant>.onmicrosoft.com username to have a “backdoor” for troubleshooting.

If you need to set up a low-cost authentication for Microsoft cloud services in your project, this can be a solution to what might be a serious problem.

Featured image: Shutterstock