One of the features that I’m really excited about, announced at Ignite, is Pass-Through Authentication for Azure AD. Many customers feel the need to install AD FS in their environment to provide single-sign-on and consistent authentication for their users, or they have a security (audit, authentication barrier) or HR (enforce logon hours) need to perform authentication via their domain controllers. A good log management system will be able to combine the logs from authentication and other systems, allowing security teams to follow a user’s actions through the network, which is usually quite useful when a breach or other security event has occurred. However, AD FS is a lot of infrastructure to maintain:
- 2 load-balanced AD FS servers
- 2 load-balanced web application proxies
- firewall
- public IP address
- load balancer
If you price this out in Azure, it’s a not-insignificant sum of money to be spending simply for authentication to cloud services.
Pass-through authentication enables companies to continue to have a single-sign-on experience on their domain-joined devices, even those previous to Windows 10, and provides the audit trail quite similar to AD FS’s, without the infrastructure overhead. It uses very similar technology to the Azure AD Application Proxy – a very small application is installed within the network boundary, which maintains an outbound SSL connection. This connection, being stateful, allows responses to be sent back to the application – which is how Azure AD is able to send requests back to it. When a user signs on to Azure AD, the password is encrypted (using a public key stored in Azure) and sent back to the domain controller via the proxy’s connection. The password is decrypted (on-premises) and sent to a domain controller. The recommendation is to actually install the application ON your domain controllers, to ensure that the password is not sent over the LAN.
Authentication flow using Pass-through authentication.
This eliminates the need to have dedicated servers, load balancers, a DMZ, certificate management, and all the associated pain.
One of the huge benefits is that there is absolutely no exposure of your network to the Internet. No endpoints is always more secure than an endpoint, no matter what you stick in front of that IP address. All the sign-on traffic is pointed at Microsoft’s servers, where they have enormous capacity for abuse, and incredible security capabilities that no organization can provide for themselves – it’s simply too large and too expensive to build.
As it is currently in preview, there’s little documentation available (currently). The Ignite session covers most of it: https://myignite.microsoft.com/videos/2836
I’m already finding great use-cases for this technology and I can’t wait until it comes out. It will make adoption of cloud identity significantly easier for many organizations.
Azure Active Directory Demystified | Karim Vaes
[…] Now as I mentioned, these models have been active for quite some time. To make matters a bit more complex, know that “AAD Pass-Through Authentication” is currently in preview… Again, summarizing things a bit unrespectfully, this is a solution that will reside somewhere between Synced & Federated Identity. Look at it like a (lightweight) managed ADFS in the cloud. More info on that, check Nicholas Romyn’s blog on it! […]
Would this respect the source DC’s password lockout policy. For example if you had 3 bad attempts and your lockout policy was 3 would it lock the account at the DC? I know it respects if the account is locked they showed that on the Ignite video.
This is a good question – because the authentication request is being passed through directly to the domain controller, it should increment the bad attempt counter, and block the user.