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. 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. Please see the following guide Azure Active Directory integration with on-Premise AD using PTA for more information and also this guide for reasons to deploy AAD, how to set up Azure AD Tenant, 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.
Note: With 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 instead for better security options.
Pass-through Authentication is an alternative to Azure AD Password Hash Synchronisation, which provides the same benefit of 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.
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 can download Microsoft Azure Active Directory Connect here. There are various ways to have this downloaded on the Azure portal.
– Alternatively, you can navigate to Azure AD, select Azure AD Connect as shown below, and click on download 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
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.
This 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” methods 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“.
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 184.108.40.206, 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
Summary: 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.
In the next window, you will be provided with the option to sync all the domains or the selected domain. 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
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
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.
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). - 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.
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
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.
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 as. 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 “https://myapps.microsoft.com/techdirectarchive.com“, you will not be prompted to enter for Username and Password.
Note: 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.
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 explorer 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. If you have any questions, please let me know in the comment session.