AAD Pass-Through Authentication – SSO without ADFS

There are multiple options for authenticating users against Azure AD. But until now, full support for SSO based logins was only possible using two options. Azure AD joined devices, or a local ADFS service to your on-premises Active Directory. The latter being the most used option it also had its problems, first of all you had to implement a fully redundant ADFS service, a reverse proxy solution (WAP) and open up ports on your network to allow your users to find the ADFS service remotely.

Luckily Microsoft heard their customers and has released the Azure AD Pass-through authentication (PTA) in preview now. While initially they did not support SSO, they added it in preview today! This means that your local AD joined devices can use PTA so achieve SSO for most of the Office 365 applications and your on-premises published services (through Azure AD Proxy). In this post, we will look at the implementation of this service and see how it will work together with Azure AD published applications.

First thing to know is that there are still only 2 domain types available in Azure AD; Federated and Managed. While Federated stays the same in terms of functionality (you always need to have an IdP provider such as ADFS, Ping Federate or other), the Managed one is the one for which your passwords are in the cloud (password synchronization) or still on-premises using Pass-through authentication. When we switch to PTA mode all domains are switched to Managed / PTA! Luckily the system knows which accounts are created locally and which ones are synchronized to Azure AD. That means that your manually created accounts in Azure AD (and not AD) will still be able to sign-in and use the services. But be aware that switching the service, actually switches all federated domains to Managed.

How Pass-through authentication works

So let’s see how this all works. In short, the Azure AD Connect application will install local agents on the server it is installed on. One agent is enough, but you’d need two for failover and even if you have a very large user base, three would be sufficient according to Microsoft. These agents will connect outbound to an Azure AD queue. When a user types the username and password in an Azure AD login field, the details are sent to a queue in an encrypted format. The agents that are locally installed will review the queue and retrieve the information. The username / password combination is decrypted locally and the installed agent will request a Kerberos ticket on behalf of the user. During this sequence, you will see a message on the sign-in page:

On the server hosting the agent (its executable ApplicationProxyConnectorService.exe), you will see a logon session for the user that has just signed-in on-line. While this is not an SSO session, the actual sign-in is not for any of the “online” service URL’s which we will see in our next chapter. It’s just a local login on the ProxyConnector server and if that succeeds, the online login succeeds as well.

Now in the backend, the more technical architecture for this seems to be that the proxyConnectorService actually connects to servicebus.windows.net to retrieve the queue

The next part in the network trace is the actual Kerberos Login (to the local server)

but as soon as the login succeeded (or failed), the response is actually given to another URL: msappproxy.net

As you can see, there is no actual login to the service from the client itself, and the username and password values are just “validated” by the ProxyConnector. Given I cannot look into the traffic, I’m only assuming that an OK or NOTOK is passed back to the service.

Single Sign On – with PTA

But the next step is obviously to enable SSO for your domain joined devices. Now the trick here is that there are two websites that are accessed which will ask for a Kerberos Login. The URL’s for these websites are: https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net (the first is actually referring to the second domain name with a DNS CNAME record).

In order for your client to provide a Kerberos ticket, they need to be added to your intranet zone. Similar to what we used to do with the ADFS URL. You can manually add these two URL’s to the intranet zone on every client, or use group policy to add them to the zone list.

While the initial connection to the service is to the autologon URL, the service hosted there will actually request a Kerberos ticket for the second URL; as can be seen in the following WireShark network trace:

When you look in on the domain controller handling the case, the ticket is actually requested for a computer account:

Now if you where to look in your AD Users and Computers default Computers container, you would indeed see a new computer object called AZUREADSSOACC$ which was created by the AAD Connect wizard when we enabled SSO. This computer object has the ServicePrincipalNames as follows:

With the SSO option, your agents actually don’t do anything. While I did not work on this project, my only guess would be that it works according to the following: The computer object created in AD has a shared secret with your Azure AD tenant, similar to a member server or client. When SSO happens, your client basically requests a service ticket (which has two secret keys, one for the user logging in, one for the service you are accessing. Both however have the same session key they can extract from their side of the ticket), the AAD can decrypt its part of it (using the shared secret used for AzureAADSSOACC [SK:1]) to read the session key. Your client can also retrieve that session key using it’s shared secret with the on-premises AD [SK:2]. Since both now can read that session key, authentication (SSO) can happen based on this shared key. But as indicated, this is my guess on how it works..

And there you have it. Agentless SSO for web services, based on Kerberos sign-ins!

Now there are also some downsides to this PTA-SSO architecture. That is, that any agent you now have installed on your ADFS to provide MFA or tracking of logins will not work anymore. MFA can only be achieved if you combine it with Azure MFA and if you had any other SSO capabilities enabled for your clients through the use of reverse proxy services in front of your ADFS (like F5, Barracuda, etc) you’d lose that capability too. But when your clients are mostly AD integrated this is an excellent feature to explore!