At Ignite 2017 it was announced that Pass Through Authentication (PTA) has reached General Availability (GA) so it is a fully supported scenario now.

But what is PTA? If Office 365 there are Cloud Identities, Synced Identities and Federated Identities. The first two are authenticated in Azure Active Directory, the last one is authenticated against on-premises Domain Controllers. For this to happen you need an ADFS infrastructure, consisting of multiple internal ADFS servers and multiple WAP (Windows Application Proxy) servers in the DMZ acting as ADFS proxies. Oh, and all servers need to be load balanced as well to provide redundancy and scalability.

PTA on the other hand is built on top of Azure AD Connect, and as such an interesting extension of the Synced Identities. PTA installs an agent on the Azure AD Connect server (AuthN agent) which accepts authentication requests from Azure AD and sends these to on-premises Domain Controllers. The advantage of authentication against on-premises Domain Controllers is that no passwords (or password hashes to be more precise) are stored in Azure Active Directory.

My first thought was how an authentication mechanism based on an asynchronous replication tool (Azure AD Connect synchronizes accounts every 30 minutes, and passwords within 2 minutes) ever be a reliable and safe solution. The last thing you want to happen is that you cannot authenticate to any service in the Microsoft cloud, because your Azure AD Connect server is busy doing other stuff (like automatically updating its engine for example ).

My second thought was how secure this could be. There’s no inbound connection to the Azure AD Connect server, there’s only an outbound connection on ports 80 (only used for SSL certificate revocation lists) and 443. And the communication itself should be secured as well, so…. But now that PTA is generally available more information becomes available, and things become clearer.

Authentication flow

For authentication to happen PTA uses a ‘service bus’ in Azure. The service bus is a standard Azure solution where application can store system messages in the service bus and where other applications can use these system messages. Using a service bus, you can create an asynchronous but reliable communication mechanism.

When logging to an Office 365 service the credentials are requested by Azure Active Directory, nothing new here. The credentials are encrypted and stored in the service bus. The AuthN agent on the Azure AD Connect server has a persistent connection to Azure AD and to the service bus, and retrieves the encrypted credentials from the service bus, decrypts them and presents them to the on-premises Domain Controller. The Domain Controller response (success, failure, password expired or user locked out) is returned to the AuthN agent and stored it on the service bus. Azure AD picks up this response and the user can continue working (or not of course, depending on the Domain Controller response).

So, how does the encryption work? During installation the Azure AD Connect server generates a key pair. The Public Key is sent to Azure AD and a certificate is created. This certificate is returned to the Azure AD Connect server and combined with the private key. The public key is used to encrypt the user’s credentials, and the Azure AD Connect server is the only one having the private key to decipher the key pair. Voila

Configuring Pass-through authentication

You enable PTA using Azure AD Connect. In the past the synchronization tool was what its name implied, but with Azure AD Connect it’s more like a management tool where you manage all kinds of identity options.

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 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 my environment I already had Azure AD Connect up and running (with password hash synchronization), so it’s just a matter of changing the configuration.

Start Azure AD Connect, choose configure and select change user sign-in.

Click Next and enter the tenant admin credentials. These credentials are needed to logon to Azure Active Directory, enable PTA in Azure AD and create the certificate.

Click Next to get on the User sign-in page. Here you have four options:

• 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 like Okta).

The checkbox can be used to enable single sign-on.

Select Pass-through authentication and click Next to continue. Note the recommendation at the bottom of the page. This makes sense. 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 your network and none of the AuthN agents are available, nobody can logon anymore. Therefore you need a cloud only admin account with a @<tenant>.onmicrosoft.com username.

When you click Next the Azure AD Connect wizard will check for installed components and if all went well you can start the configuration process.

Click Configure to start the configuration. In my case I am changing from Password Synchronization to Pass-through authentication so no need to change any changes to the synchronization. Otherwise deselect the start the synchronization process when configuraton completes checkbox to make changes to the synchronization before it happens. After a few moments the changes should be complete.

Click Exit to finish the wizard.

When you logon to the Azure Portal, select Azure Active Directory and click the Azure AD Connect tile you’ll see that Pass-through authentication is now enabled:

So, what do you see when you logon to for example Outlook Web App in Exchange Online? Nothing special, you see the standard Azure AD logon page (via https://login.microsoftonline.com) and after entering your credentials you can access your Exchange Online mailbox.

If you open the Security Event Log on the Azure AD Connect server you can look for Event 4624, this will show you that the user account was actually authenticated against an on-premises Domain Controller:

This is one of few places (I know of) where you can actually check PTA authenticating accounts.

Azure AD Connect agent not available

What happens when the Azure AD Connect agent is not available? The users are no longer able to logon. To simulate that you can stop the Microsoft Azure AD Connect Authentication agent in the services MMC snap-in.

If you try to logon to OWA for example, you enter the credentials in the Microsoft Online login portal and after a few second you’ll see an non descriptive error message:

Redundancy in Pass-through authentication

To overcome this issue, you can install the AuthN agent on multiple machines. Personally, I don’t recommend installing this on Domain Controllers, just a regular Windows 2012 R2 server or higher should do.

When logged on to the server open the Azure portal (https://portal.azure.com), select Azure Active Directory, click the Azure AD Connect tile and click on Pass-through authentication.

Click Accept terms & download to start the download. After downloading just install the agent, enter the tenant admin credentials when requested and after less than a minute the agent is installed.

How many instances do you need? If you have a larger environment three instances is recommended. Two can be sufficient, but if one is in the process of automatically updating and it fails, one remaining might not be sufficient when dealing with a large number of authentication requests.

Supported clients

When it comes to clients and supported scenarios the following is supported:

• Sign-in with all web-browser based applications.
• Office 2013 and Office 2016 that supports modern authentication.
• Windows 10 Azure AD joined devices.
• Exchange ActiveSync.

The following clients and scenarios are not supported:

• Legacy Office client applications (2010/2013 without modern authentication).
• Skype for Business client applications (includes SfB 2016 client!).
• PowerShell 1.0.
• Azure AD Domain Services.
• App passwords for MFA.
• Detection of users with leaked credentials.

This list is not surprising though, with the exception of the Skype for Business clients. List is as of October 2017.

Summary

Pass-through authentication is generally available as of Ignite 2017. It is an authentication mechanism where no password hashes are stored in Azure AD. It is also much lighter than ADFS, less complex and easier to manage.

Will it replace ADFS? Not on the short term. At this moment it supports modern Microsoft applications that can use the Azure service bus and related solutions. Other 3^rd applications (thousands of them) that are available in the App store still rely on ADFS and will continue to do so for some time.

More information can be found on https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-quick-start