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.
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.
I already obtained the latest installer at https://aka.ms/aadconnect. 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.
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.
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.
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.
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.
I’m prompted to authenticate using my mobile device as I have multi-factor authentication (MFA) enabled the Global Administrator account I am using.
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.
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.
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.
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 email@example.com 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.
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.
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.
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.
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.
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
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.
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.
- Azure AD Connect: Design concepts
- Prerequisites for Azure AD Connect
- Custom installation of Azure AD Connect
- Azure Active Directory Pass-through Authentication: Quick start
- Azure Active Directory Pass-through Authentication security deep dive
- Azure AD Connect: Accounts and permissions
- Azure AD Connect sync: Understanding Declarative Provisioning
- Install Azure AD Connect using SQL delegated administrator permissions
- Azure AD Connect: Version release history
- Protect your Office 365 global administrator accounts
Till next time…