Field Notes: Azure Active Directory Connect – Custom Installation with Pass-Through Authentication & a remote SQL Server

Integrating your on-premises directories with Azure Active Directory makes your users more productive by providing a common identity for accessing both cloud and on-premises resources.  Azure Active Directory Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals.  It provides features such as password hash synchronization, pass-through authentication, federation integration, and health monitoring.

I covered the express installation option in my previous post (Field Notes: Azure Active Directory Connect – Express Installation).  In this follow-up post, I cover the custom installation option.

Custom Installation

Why would you want to customize the installation of Azure AD Connect, as it’s just easier to go with the express option and provide a couple of credentials through the installation and configuration wizard?  Options…  One requirement could be environments having multiple forests that are synchronized to a single Azure AD tenant.  Another could be having to make choices that are not covered by the express option.  In this example, I use a remote SQL Server installation and enable pass-through authentication.

Getting started

I already obtained the latest installer at  The Azure Active Directory team at Microsoft regularly updates Azure AD Connect with new features and functionality.  Launching the installer presents the Welcome To Azure AD Connect screen.  Following that is where a decision whether to go express or custom is made.  I select the customize option.

Custimizing the Installer

Install required components

The first set of customization options include the use of an existing SQL Server.  You may need to use a full-blown SQL Server as the SQL Server Express that is installed by default on the local server has some limitations.  SQL Server Express has a 10 GB size limit that enables you to manage approximately 100 000 objects.  Microsoft Azure SQL Database is currently not supported as a database.  I am also using a managed service account (versus a normal domain account) in my environment as I am connecting to a remote SQL Server.

Specify an existing SQL Server and MSA

A group managed service account is recommended if you use a remote SQL server.

I am not specifying a custom installation path here as I am happy with the default “C:\Program Files\Microsoft Azure AD Sync”.  I also stick to the local groups that are created by default on the Azure AD Connect server.

Local Sync Groups

User sign in

Here’s another reason you may want to customize the installation – user sign-in options.  Password Hash Synchronization is enabled by default with the express option but a different sign on method may be required.  In this setup, I go with Pass-through authentication and also enable single sign-on for corporate desktop (intranet) users.  With pass-through authentication, credentials are validated by on-premises domain controllers.

User Sign-in Options

It is recommended that you have a cloud only company administrator account so that you are able to manage pass-through authentication in the event of an on-premises failure.

Connect to Azure AD

The Connect to Azure AD screen is the same as what we saw in the express installation.  I supply credentials of a global administrator Azure AD account.

Connect to Azure AD

I’m prompted to authenticate using my mobile device as I have multi-factor authentication (MFA) enabled the Global Administrator account I am using.

MFA Challenge

Connect your directories

An on-premises Active Directory account with sufficient permissions is required for reading object information, and sometimes for updating attribute values too. It is recommended that you let the wizard create a new account, and credentials of an account belonging to the Enterprise Admins group is required for this.  Otherwise, an existing account with sufficient permissions could be used.

On-Premise AD Credentials

Once credentials have been supplied, the directories need to be added as shown below.  I have added one forest with two domains, which we will see the domain and OU filtering section.

Connect On-Premise Directories

Azure AD sign-in configuration

To sign-in to Azure AD with the same credentials as what we have on-premises, a matching Azure AD domain is required.  I have already verified my domain in Azure AD and setup the UPN suffix in my forest.  I leave the default and recommended userPrincipalName as the attribute to use for logging on to Azure AD.

Active Directory UPN Suffixes

Users will not be able to sign-in to Azure AD with on-premises credentials if the UPN suffix does not match a verified domain.  In this environment, I cannot sign-in to Azure AD with as an example.

Domain and OU filtering

My on-premises environment consists of two domains in a single forest.  The customized installation path offers the granularity to select which domains and/or containers you want to include in the synchronization scope.  Some containers are essential for the functionality and should not be unselected.  One example is the ForeignSecurityPrincipals in a multi-forest environment with trusts.  Another, which is not depicted below, is the RegisteredDevices organizational unit if the device write back feature is enabled.

Domain and OU Filtering

Uniquely identifying users

We are next presented to select how users should be identified in the on-premises directories.  What I have highlighted below is a common scenario (users are presented only once across all directories).  Options presented here also cater for multiple forests where you could have linked mailboxes in another forest for example.  I have a single forest, so I proceed with the default.  I also let Azure manage the source anchor.  The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object.  It uniquely identifies an object as being the same object on-premises and in Azure AD.  The attribute is also called immutableId and the two names are used interchangeable.

Identifying Users

Filter users and devices

The synchronizing all users and devices option is recommended for production environments.  Note that using group filtering is intended for pilot deployments.  Nested groups are not supported – objects you wish to synchronize would have to have direct membership.

Group Filtering

Optional features

This page provides optional functionality that may be required by some organizations  Examples include password hash synchronization and password writeback, which I select.  By the way, we opted to use pass-through authentication earlier during the user sign-in page.  It is recommended to also enable password hash synchronization here, especially since features such as Azure AD Identity Protection require it.

Select Optional Features

Enable single sign-on

I don’t have to re-enter a domain administrator account required to configure the on-premises forest for use with single sign-on as the account I am using already has necessary permissions to create the required computer object in the on-premises Active Directory.

Enable Single Sign-On

Ready to configure

Almost there!  Everything is ready – proceeding with the installation:

  • configures the synchronization services on the local computer
  • installs the Microsoft Azure AD Connect Authentication Agent for pass-through authentication
  • enables pass-through authentication and single sign-on
Ready to Configure

Clicking install completes the installation.


A quick look in the portal confirms that the installation succeeded with both password hash sync and pass-through authentication enabled.  It is recommended to have 3 or more pass-through authentication agents installed for high availability.

AAD Sync Status

The express install option is used in most deployments, but there may be a requirement to use custom installation.  In this blog post, I covered a scenario connecting to a remote SQL Server, as well as using pass-through authentication as a sign-in option.


Till next time…