As far we know until today, the best solution form the Microsoft point of view is, to use ADFS to authenticate on-premises users for cloud services such as Azure or Office 365. This is working very well and there are many articles about how to configure the clams etc. can be found in internet and also on my Blog.

However, if a company don’t want to use ADFS for authentication, there is another way Microsoft supports, but it is not so common like the ADFS solution. In this article I want to present an alternative way using AAD with Pass-through.

 

How does that works?

To show the whole authentication progress, we are going to use the picture below. The progress is divided in 11 steps:

When a user tries to sign into an application secured by Azure AD, and if Pass-through Authentication is enabled on the tenant, the following steps occurs:

 

  1. The user tries to access an application, for example, Outlook Web App.
  2. If the user is not already signed in, the user is redirected to the Azure AD User Sign-in page.
  3. The user enters their username and password into the Azure AD sign in page, and then selects the Sign in button.
  4. Azure AD, on receiving the request to sign in, places the username and password (encrypted by using a public key) in a queue.
  5. An on-premises Authentication Agent retrieves the username and encrypted password from the queue. Note that the Agent doesn’t frequently poll for requests from the queue but retrieves requests over pre-established persistent connection.
  6. The agent decrypts the password by using its private key.
  7. The agent validates the username and password against Active Directory by using standard Windows APIs, which is a similar mechanism to what Active Directory Federation Services (AD FS) uses. The username can be either the on-premises default username, usually userPrincipalName, or another attribute configured in Azure AD Connect (known as Alternate ID).
  8. The on-premises Active Directory domain controller (DC) evaluates the request and returns the appropriate response (success, failure, password expired, or user locked out) to the agent.
  9. The Authentication Agent, in turn, returns this response back to Azure AD.
  10. Azure AD evaluates the response and responds to the user as appropriate. For example, Azure AD either signs the user in immediately or requests for Azure Multi-Factor Authentication.
  11. If the user sign-in is successful, the user can access the application.

 

On-premises user sign-in to Azure AD

Let us have a closer look to the sign-in progress from on-premises user to Azure AD.

As we can see in the picture, the on-premises user credentials are “sent” to the on-premises agent, these credentials will be validated against the local Active Directory. If the username and password are correct, the user will be able to login.

Note: this is only working, if the user account is synchronized to the Azure Active Directory. In our case by using the Azure AD connect.

 

Pass-through authentication

The pass-through authentication agent (AuthN agent) only requires outbound firewall ports. The necessary Ports for that are the Port 80 and the Port 443.

Good to know for this solution is that multiple agents can be deployed for the performance and as well for fault tolerance. The communication between the sites works with https only and as default.

 

Pass-through authentication installation – What is going on

Till this chapter we know how the pass-through authentication works and about what we need to think. However, let us have a short look about how the installation has to be done.

By the installation we chose our Azure AD connect server and here we deploy the AuthN agent. The AuthN agent will create then a pair of key (private key and public key) and sends a certificate request to the Azure AD. This is possible because we already have installed and configured our Azure AD connect. Now the Azure Active Directory creates the certificate and stores it together with the public key by itself. The created certificate will be returned to the AuthN and the received certificate will be associated with the private key.

 

Pass-through authentication installation – Steps

For PTA to be enabled on the Azure AD Connect server the following requirements apply:

  • Azure AD Connect version 1.1.557.0 or later must be running on Windows 2012 R2.
  • Port 80/443 outbound need to be opened

Note: You can download the latest version of Azure AD Connect here: https://www.microsoft.com/en-us/download/details.aspx?id=47594. When writing the blogpost the latest version of Azure AD Connect was 1.1.647.0

 

In this step by step setup, we already had Azure AD Connect up and running (with password hash synchronization), so it’s just a matter of changing the configuration.

We start our Azure AD Connect and we choose configure and select here change user sign-in.

Now we continue with clicking Next and here we enter our tenant administrator credentials. They are needed to be able to logon to Azure Active Directory and to enable PTA in AAD and to create the certificate.

For the next step we have to click on Next and we will get on the User sign-in page. Here we have in total four options we can set:

  • Password Synchronization (wrong name, should be Password Hash Synchronization).
  • Pass-through authentication (this blog’s topic).
  • Federation with AD FS (future blog).
  • Do not configure (when using a third party federation solution)

If we want to enable single sign-on (SSO) we also need to mark the checkbox.

For our case we need to select Pass-through authentication and then we continue clicking Next.

Note: the recommendation at the bottom of the page. This makes sense. We have to remember that setting PTA is a tenant wide setting, so ALL accounts in our tenant are forced to use PTA. If something goes wrong in our network and none of the AuthN agents are available, nobody can logon anymore. Therefore we need a cloud only admin account with a @<tenant>.onmicrosoft.com username to have a “backdoor” for troubleshooting.

If we now continue by clicking Next, the Azure AD Connect wizard will check our environment about installed components and if all went (as expected) well, we can start the configuration process.

By clicking on Configure, the configuration will start straight away. From my point of view the most common configuration path form now is to change from Password Synchronization to Pass-through. That’s why we continue from here with this solution way.

After the configuration is finished, we can click Exit, and the wizard will be closed.

If we now open our web browser and logon to our Azure portal, we select Azure Active Directory and browse to Azure AD Connect, here we see that Pass-through authentication is now enabled:

Note: Pictures and some of the information in this chapter are taken from Jaap Wesselius.

 

Conclusion

If you are looking for an alternative for authentication without ADFS, Pass-through can be a good one. In the Microsoft world for Azure and Office 365 it will work well. Today in a ADFS environment we don’t have to setup the AAD in a redundant state. Important is that we have made a back up the config, which we can restore if needed. By using AAD for Pass-through the agents can be installed on each server which has a connection to the Active Directory and to the Microsoft cloud..

If you need to setup a low cost authentication for Microsoft cloud services in the project, this can be a serious solution.

 

Photo by Štefan Štefančík on Unsplash

 

 

 

Post Views: 13,575