Azure AD Pass Through Authentication and Single Sign-on



In this post, I will be walking through configuring Azure AD pass through authentication and single sign-on for a single AD forest, and confirming the client experience once implemented.


Azure AD pass through authentication is another alternative to password synchronization, similar in functionality to AD FS, that can be enabled in Azure AD Connect. It ensures that password validation for Azure AD services is performed against your on-premises Active Directory. Passwords can be validated without the need for complex network infrastructure (e.g. AD FS) or for the on-premises passwords to exist in the cloud in any form.

With just pass through authentication enabled, a user will still need to enter their password to access cloud services from a machine connected to your on-premise AD domain.

Azure AD single sign-on is another option that can be enabled in Azure Active Directory Connect with either password synchronization or pass-through authentication. When enabled, users only need to type their username and do not need to type their password to sign in to Azure Active Directory (Azure AD) when they are on their corporate machines and connected on the corporate network.

Therefore, with pass through authentication and single sign-on enabled, you can achieve the same authentication requirements for Azure AD and SSO experience for clients, typically gained by implementing AD FS, which obviously simplifies the steps to implement this functionality.

NOTE: At the time of writing (March 2017) these features are still in preview, version 1.1.443.0.


A detailed list of requirements is detailed here. A summary of these relevant to this post are below:

  • Azure AD Connect installed with latest version (1.1.433.0 at time of writing)
  • A domain administrator account for your on-premises AD forest
  • An Azure AD tenant for which you are the global administrator
  • For users, on-premises UPN must match the Azure AD UPN/username
  • There is a recommendation in the above link that the global administrator should be a cloud-only account so that you can manage the configuration of your tenant should your on-premises services fail or be unavailable. I always suggest this to clients when working on AD FS implementations, and would add that the username suffix of the global admin account should be the default * domain for you tenant, and not one of you custom verified domains
  • There are firewall considerations that can be referred to in the above link. For a basic lab set up like I am using, I didn’t worry about these
  • For high availability and load balancing, a second server running Windows Server 2012 R2 or higher on which to run a second pass-through authentication connector can be installed. Instructions for this are included in the above link. I won’t be doing this in this post


Configure Azure AD Connect

Run the Azure AD Connect wizard. Click Configure on the Welcome screen.

Select Change user sign-in on the Additional Tasks page and click Next

Connect to your Azure AD tenant by entering your Username and Password and click Next

The wizard will connect to Microsoft Online. Click on Pass-through authentication and Enable single sign-on as shown below under the User sign-in page

You will need to provide domain administrator credentials for your on-premises AD forest on the Enable single sign-on page. Click Next once the credentials have been verified

Review the settings on the Ready to configure page and then click Configure to apply the settings.

The wizard will go through the steps of installing and configuring pass-through authentication.


Configuring clients

To facilitate single sign-on for clients, the Azure AD URLs need to be added to the Intranet zone of client Internet browsers. This setting makes the browser automatically send the currently logged in user’s credentials in the form of a Kerberos ticket to Azure AD.

Typically, you would use group policy to do this, and this is explained here. However, for this lab, just enter the two required URLs into the Intranet zone of your test machine’s browser manually.

Client experience

Logging on from corporate network on domain joined machine

Now, from you client test machine, browse to any of your services that use Azure AD for authentication. For this test, I’ll logon to

Enter your test username, e.g., and then click in the Password field.

When you click on the password field, the logon page will pass the user’s existing Kerberos token to Azure AD and they will be logged onto the portal automatically, without having to enter their password.

Logging on from external network

When logging onto from an external network, you must also enter the password, which is expected, and then click Sign in

After you click on Sign in you will see your browser Trying to sign you in as shown below. In the background this is authenticating against your on-premises AD via pass-through authentication. This will then take you through to the Office 365 portal as shown above.

So, as you can see above, you can now realise the benefits of single sign-on (for clients connected to your internal corporate network) very easily with just Azure AD Connect, rather than having to implement more complex AD FS infrastructure, which is an great new feature that will obviously be a big win for many.




Andrew Matthews

Andrew Matthews
Andrew Matthews
SENIOR CLOUD CONSULTANT AT CUBESYS Andrew has 14+ years’ experience in senior operational and support roles, solution architecture, design, professional services and project management. Andrew specialises in Office 365 and Azure AD, EM+S, Exchange and Lync/Skype for Business.