Azure AD is a service that provides identity and access management capabilities in the cloud. With Pass-through Authentication, users are able to sign in to both on-premises and cloud-based applications using the same credentials. In this guide, you will learn how to sync on-premises AD with Azure AD via Azure AD Connect. Please see how to add or delete users, and set permissions in Azure Active Directory, why do I need to deploy Azure Active Directory and how to use the built-in AAD Connect troubleshooting tool.
When synchronized and the user performs a sign-in request to cloud applications. This feature validates users’ credentials directly against your on-premises Active Directory.
Note: Azure AD has been renamed to Microsoft Entra ID. The name change was announced last year (2023). The services remain the same, only the names have changed.
Please see these exciting guides: For reasons to deploy AAD, how to set up Azure AD Tenant,
Pass-through Authentication
With Pass the Hash Synchronization (PHS). Your password hashes are saved in the cloud. However, certain organisations wanting to enforce their on-premises Active Directory security and password policies can choose to use Pass-through Authentication (PTA) instead for better security options.
Pass-through Authentication is an alternative to Azure AD Password Hash Synchronisation. Which provides the same benefit as cloud authentication to organizations.
Please visit the following article to learn more about the various methods available for integrating Azure Active Directory with on-Premise Active Directory. Below are two diagrams illustrating how PTA works when users try to access cloud applications such as Microsoft365 etc. For more information on how this works, please refer to this article.
Choosing the correct authentication method is the first concern for organizations wanting to move their apps to the cloud.
The following section helps you decide which authentication method is right for you by using a decision tree. It helps you determine whether to deploy a cloud or federated authentication for your Azure AD hybrid identity solution.
Accounts used for Azure AD Connect
Azure AD Connect uses 3 accounts in order to synchronize information from on-premises or Windows Server Active Directory to Azure Active Directory. These accounts are:
- AD DS Connector account: used to read/write information to Windows Server Active Directory.
- ADSync service account: used to run the synchronization service and access the SQL database.
- Azure AD Connector account: used to write information to Azure AD.
In addition to these three accounts used to run Azure AD Connect, you will also need the following additional accounts to install Azure AD Connect. These are:
- Local Administrator account: The administrator who is installing Azure AD Connect and who has local administrator permissions on the machine.
- AD DS Enterprise Administrator account: Optionally used to create the “AD DS Connector account” above.
- Azure AD Global Administrator account: used to create the Azure AD Connector account and configure Azure AD. You can view global administrator accounts in the Azure portal.
Please see how to Repair or Uninstall Azure AD Connect: How to uninstall Azure AD Connect, how to fix “AD Connect Sync Service not running: Cannot proceed because the sync service is not running, start the ADSync service and restart the AD Connect Wizard to continue“, and how to fix “Azure AD Connect Tool status displays inactive“.
Integrate your on-premises environment
In order to integrate your on-premises environment, kindly ensure the following steps are followed strictly. 1: Windows Server with Active Directory (AD) installed: See the following articles on how to install Windows Server 2019 and Windows Server 2016 or on a Hyper-V Server. See the following link for the post-installation of Windows Server 2019. After setting up the Windows Server environment, you should install Active Directory Domain Services. To do this, see how to set up a Domain Controller and how to add a second Domain Controller (DC) to your environment. Also, you would like to create Active Directory Users and Contacts, to begin with.
2: Microsoft Azure Account (Tenant): See this guide for how to set up an Azure AD Tenant. Also when the tenant is up and running, ensure you add a custom domain in the Azure Active directory.
3: Create an Azure Global or Administrative account: See this guide on how to add a user account and set permissions in Azure.
4 Download the Azure AD Connect: After completing the above steps, we will have to download and install Azure AD Connect to synchronize your on-premises to Azure Active Directory as well. You should download Microsoft Azure Active Directory Connect. There are various ways to have this downloaded on the Azure portal.
Download Azure AD Connect
Alternatively, you can navigate to Azure AD, select Azure AD Connect as shown below, and click on download Azure AD Connect. In this way, you will be able to sync on-premises AD with Azure AD via Azure AD Connect.
Note: Azure AD Connect can be installed on any server in your on-premise environment. But in my lab, I will be installing it on my Domain Controller.
An Azure AD Connect sync server is an on-premises computer that runs the Azure AD Connect sync service. This service synchronizes information held in the on-premises Active Directory to Azure AD. For example, if you provision or de-provision groups and users on-premises, these changes propagate to Azure AD.
Now that I have downloaded the Azure AD Connect to my on-premise Active Directory as shown below
Install Azure AD Connect
Double-click on the MSI file to start the installation.
Note after the components are registered, a new shortcut will be available on the desktop.
To start the process, launch the Azure AD Connect installation. Click on “I agree with the License agreements and privacy rules” and click on “Continue” as shown below.
Choose whether you would go with an express installation or a customized installation. I will be using the “Customized” installation since I do not want to use the express settings because I do not want to have my password hash etc and also my attributes synchronized.
This will open the “Install required components” window. Click on the checkbox “Specify custom installation location” as shown below and you can browse to whatever location you want. For me, I will leave the default installation path.
Also, you can use an existing SQL Server, but in my case, I will be using the default MS SQL Server Express. If you are syncing over 100 thousand objects, a dedicated (full) MS SQL Server is recommended.
SQL Server Express database setup
These steps will work through the SQL Server Express database setup etc as shown below. This will take a little while, please exercise a little patience 😉
This will open the “User Sign-in” method as shown below. I will be selecting “Pass-through Authentication“.
Select “Enable single sign-on” as well. This option is available to both password hash sync and pass-through authentication. It provides a single sign-on experience for desktop users on corporate networks. And finally, click on “Next“.
Enter your Azure Global Administrator credential
This will open the Connect to Azure AD window. Enter your Azure Global Administrator credential in order to authenticate to the Azure AD environment. See this guide on how to add a user account and set permissions in Azure.
You may get an error here saying “The password has expired, update your password and try again”, please use this link to fix the issue.
Enter connection information for your on-premise directory or forests and click on add directory (Without this, you can not proceed).
Note: As of build 1.4.18.0, you cannot use your Enterprise or Domain administrator account for your AD Forest account. It is recommended to let Azure AD Connect or you can specify a synchronisation account with the correct permission.
I will be using an existing account I have in AD. Click on “OK” as shown below
Now, click on Next as shown below
This will retrieve the Directory Schema for TechDirect.Local and prompt Azure AD Sign-in Configuration as shown below.
In the “Azure AD Sign-in Configuration” wizard, click on continue without matching all UPN suffixes to verified domains
Sign in to Azure AD with an on-premise credential
Users will not be able to sign in to Azure AD with an on-premise credential if the UPN suffix does not match a verified domain
Review every domain that's marked as Not Added or Not Verified. Make sure that the domains you use have been verified in Azure AD. After you verify your domains, select the circular refresh icon. Refer to this reference link.
- Azure AD should verify the domains, also known as the UPN-suffix before users are synchronized.
If the userPrincipalName attribute is non-routable and can't be verified, then you can select another attribute. You can, for example, select email as the attribute that holds the sign-in ID. When you use an attribute other than userPrincipalName, it's known as an alternate ID.
- Note: Microsoft recommends that you keep the default attribute userPrincipalName.
If you are trying to verify a child domain, verify the parent domain first. Make sure the parent domain is created and verified first before you try to verify the child domain. Reference link.
- If the userPrincipalName attribute is non-routable and can't be verified, then you can select another attribute. You can, for example, select email as the attribute that holds the sign-in ID. When you use an attribute other than userPrincipalName, it's known as an alternate ID.
- Note: Alternate IDs aren't compatible with all Microsoft 365 workloads etc.Sync all the domains or the selected domain
In the next window, you will be provided with the option to sync all the domains or the selected domain.
Note: If you plan to use group-based filtering, then make sure the OU with the group is included and isn’t filtered by using OU filtering.
OU filtering is evaluated before group-based filtering is evaluated. I will go with the second option “Sync select domain and OUs”. Unselect the OUs’ you do not want to sync and click on Next to continue
Specify how users will be identified
In the next dialog box, select how the users should be identified in your on-premise directory. The options I have selected in the image below are enough for my task, there I will proceed by clicking on Next.
In the window below, you can choose whether to include all users and groups or a selected group and user respectively.
– I will go with the first option here “to synchronize all users and devices”.
In the “Optional features” as shown below, select the functionalities that are required by your organization. Here some features are greyed out because they require a P1 or P2 license.
I am okay with the Password write-back, so whenever I make changes to my passwords in the cloud, it will be written back to the same user on-premise
Enable SSO for use with password synchronization or pass-through authentication
In the “single sign-on (sso)” dialog window, you are required to enter your domain administrator account to configure the on-premise forest to use SSO.
Enter the Domain credential as shown below and this will create the necessary computer account in your on-premises instance of Active Directory.
Enable Single Sign-On
On the Single sign-on page, you configure single sign-on for use with password synchronization or pass-through authentication as it is in my case. You do this step once for each forest that’s being synchronized to Azure AD. Configuration involves two steps:
Create the necessary computer account in your on-premises instance of Active Directory (This is being done in the image below). And then, configure the intranet zone of the client machines to support single sign-on.
As we can see below, the forest is configured for a single sign-on.
Install Your Configuration Settings
This will open the “Ready to Configure Dialog box as shown below”. Click on install.
Note: I selected to start the synchronisation process when the configuration completes as well.
This will continue the installation as listed in the image above
The configuration is now complete and you can verify in your Azure AD that the user accounts have been created, and now you have learned how to sync on-premises AD with Azure AD via Azure AD Connect.
After the installation has been completed, sign out and sign in again before you use the Synchronization Service Manager or Synchronization Rule Editor.
Note: Be aware that this may take a few hours to complete. To verify users are synchronized do the following.Confirm the synchronization between your on-premises AD with Azure AD
To confirm the synchronization between your on-premises AD with Azure AD, log on to the Azure portal
– Navigate to Active Directory
– Click on Azure Active Directory
– Click on All Users
In the all-users list, you will see the following accounts are being added. Therefore, our on-premise AD is fully synchronized with Azure AD.
Before testing, configure the intranet zone of the client machines to support single sign-on.
Configure the intranet zone for client machines
Configure the intranet zone for client machines. To ensure that the client signs in automatically in the intranet zone, make sure the URL is part of the intranet zone. This step ensures that the domain-joined computer automatically sends a Kerberos ticket to Azure AD when it’s connected to the corporate network.
On a computer that has Group Policy management tools:
- Open the Group Policy management tools.
- Edit the group policy that will be applied to all users. For example, the Default Domain policy.
- Go to User Configuration|Administrative Templates|Windows Components|Internet Explorer|Internet Control Panel|Security Page.
- Then select Site to Zone Assignment List.
Enable the policy. Then, in the dialog box, enter a value name of https://autologon.microsoftazuread-sso.com and value of 1. Your setup should look like the following image.
More information can be found in this guide "Pass-Through Authentication issues, non-routable domain: Invalid username and password – Your account or password is incorrect if you cannot remember your account reset it now" or in this link.From any device (PC) in the organization, open the following URL below, you will not be prompted to enter for Username and Password.
https://myapps.microsoft.com/techdirectarchive.comNote: If your domain is routable, you should be able to access cloud applications with your on-premise password. Microsoft recommends not to use (avoid) a non-routable domain name suffix, such as Techdirect.local. The .local suffix isn’t routable and can cause issues with DNS resolution.
How to fix Pass-Through Authentication issues, non-routable domain: Invalid username and password
Not the following error: You may never be able to sign in if your on-premise UserPrincipalName (UPN) is different from the user’s cloud UPN as it is in my case. This is because the domain “Techdirect.local” is not routable.
To resolve this issue, please see the following guide “Pass-Through Authentication issues, non-routable domain: Invalid username and password – Your account or password is incorrect if you cannot remember your account reset it now“.
It may interest you to know, a Startup menu of Azure AD Connect will also be available to you as shown below
- Here you can manually perform full or manual synchronization of our on-premise environment to the Azure AD using the “synchronization Service”
- Also, you can reconfigure what you probably must have missed during the initial configuration using “Azure AD Connect”
Click on Synchronisation Service as shown, you can explore all others as well. Here you will be able to see the operations that took place behind the scene
You can also perform delta synchronisation via the command line using the following cmdlets.
- Import-Module Adsync - Start-ADSyncSyncCycle -PolicyType Delta
I hope you found this blog post helpful. Now, you have learned how to sync on-premises AD with Azure AD via Azure AD Connect. If you have any questions, please let me know in the comment session.
