Microsoft published two new features for AAD Connect, “passthrough authentication” and “single sign-on” for cloud workloads. With Azure AD pass-through authentication you can achieve SSO experience and authentication against on-premises environment without implementing ADFS instance, how cool is that!
With SSO, as component name defines end-user can achieve single-sign on for Azure AD and other cloud services without typing username+password combination. This is achieved by acquiring kerberos ticket from domain controller and offering it to Azure AD.
Azure AD Pass-through Authentication
Azure AD pass-through Authentication
Azure AD pass-through authentication provides a simple solution for these customers ensuring that password validation for Azure AD services is performed against their on-premises Active Directory, without the need for complex network infrastructure or for the on-premises passwords to exist in the cloud in any form.
Supported clients
- Web browser based clients and Office clients that support modern authentication
- Clients that are not support such as legacy Office clients, Exchange active sync (i.e. native email clients on mobile devices), customers are encouraged to use the modern authentication equivalent which provide support conditional access mechanism also
- Using Windows 10 joined to Azure AD, pass-through authentication is not currently supported.
Single Sign-On
Single sign on is an option that can be enabled in Azure Active Directory Connect with either Password hash synchronization or Pass-through authentication. When enabled, users need not type their password to sign in to Azure Active Directory (Azure AD) or other cloud services when they are on their corporate machines and connected on the corporate network. +
By enabling single sign-on, when your users access resources connected to Azure Active Directory services (such as Office 365, Microsoft Intune, CRM Online, and SaaS services), user don’t need to type their password but instead use a Kerberos ticket acquired automatically from your on-premises Active Directory.
When SSO is enabled from AAD Connect
- Computer account named “AZUREADSSOACCT” is created at on-premises environment
- Kerberos decryption key is shared securely with Azure AD
- Two Service Principal Names (SPN) are created at on-premises AD (represent the cloud URLs that are used during authentication between the client and Azure AD)
- Rest is IWA (Integrated Windows Authentication) and explanation below from docs.microsoft.com
- The Azure AD resource challenges the client, via a 401 Unauthorized response, to provide a Kerberos ticket.
- The client requests a ticket from Active Directory for the Azure AD resource
- Active Directory locates the machine account associated with the Azure AD resource and returns a Kerberos ticket to the client, encrypted with the machine account’s secret. The ticket includes the identity of the user currently signed in to the computer
- The client sends the Kerberos ticket it acquired from Active Directory to the Azure AD
- Azure AD decrypts the Kerberos ticket using the previously shared key, and then either returns a token to the user or asks the user to provide additional proofs such as multi-factor authentication as required by the resource
If SSO for some reason fails the fallback is normal username & password login.
Sam's Corner 