Azure Active Directory Connect (AADC) Part 2— Pass-Through Authentication(PTA)

If you have not yet read part 1 of this series, please spare some time to go through as we would be reusing a lot of the content there in this article.

Before moving forward, we should ensure at least the prerequisite steps in part 1 are completed. If that is not an issue, we could carry on with the steps below for configuring AADC to use PTA as the authentication method.

PTA would not be storing any password on the cloud, but solely relying Windows AD to authenticate the authentication requests. The general logic behind the scene is that whenever an user tries to authenticate through Azure portal, the request would be encrypted by PTA service public key and sent to a queue for PTA agent to process. PTA agent would then grab the request and decrypt it with the service private key and send it over to Windows AD to complete the authentication. If everything is as expected, Windows AD send the request back to PTA agent and the agent would then forward to AAD. This also tells us that no inbound ports need to be opened since PTA agent would be proactively grabbing requests from the queue.

Configure AADC to Synchronize Windows AD to AAD via PTA

If you have followed through the steps, your AADC should be using PHS. The only way to configure AADC to use PTA is by reinstalling the AADC, to go through AADC installation user interface again.

• Uninstall AADC

• Download AADC installation execution again here if you have not

• Once you agree the terms on the first page of the AADC installation user interface, you could select “Customize”

• Select “Install” unless you have existing services ready for the implementation

• Choose “Pass-through authentication” → select “Next”

• Put down AAD Global Administrator credential

• Put down Windows AD Enterprise Admin credential

• Check “Continue with matching all UPN suffixes to verified domains” as our internal domain name is not verified on AAD and it should not be.

• Select “Sync all domains and OUs” or “Sync selected domains and OUs”

• If users are unique in the Windows AD forest, just use the default selection. Otherwise, choose accordingly.

** Since this page mentions about “Hard Match” and “Soft Match”, quoting from the official documentation on what those are.

“When Azure AD Connect (sync engine) instructs Azure Active Directory to add or update objects, Azure AD matches the incoming object using the sourceAnchor attribute to the immutableId attribute of objects in Azure AD. This match is called a Hard Match.

When Azure AD does not find any object that matches the immutableId attribute with the sourceAnchor attribute of the incoming object, before provisioning a new object, it falls back to use the ProxyAddresses and UserPrincipalName attributes to find a match. This match is called a Soft Match. The Soft Match is designed to match objects already present in Azure AD (that are sourced in Azure AD) with the new objects being added/updated during synchronization that represent the same entity (users, groups) on premises.”

— Quoted from Trouble-shoot synchronization errors — Learn | Microsoft Docs

• Select “Synchronize all user and devices” unless other concerns

• Select the optional features accordingly.
• PHS here is acting as a backup option when PTA is not working. For example, AADC agent server lost connectivity and users are not able to authenticate themselves on Azure. If you have PHS as optional feature, there would be hashed content of each user’s password stored on the cloud, so users could use the existing data to authenticate themselves.
• Password writeback allows users to change Windows AD users’ password from the cloud, but this would need extra attention on Windows AD group policy around password management.

• When logging in on Azure portal, please remember to use Windows AD user credential with alternate domain suffix. If you are not clear how to do this, please refer to AADC Part 1 — PHS article. Inside the section of prerequisite steps, you would find the how to achieve this.

• Check Azure AD Connect section, you should see “Pass-through authentication” showing “Enabled”

• On AADC agent server, you could see a new service being created

If you are still not clear how AADC uses PTA as the main authentication method, detailed step-by-step instruction could be found in Microsoft official documentation.

That should cover a very basic scenario for AADC with PTA! If anything goes south or does not work as expected, we could use AAD PowerShell commands for general troubleshooting. Please refer to this site for getting a better idea on this!