Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 2: Authentication options (PHS, PTA)

Introduction

In this second part of our lab exercise, we shift focus to exploring authentication methods, discussing Password hash sync and Pass-through authentication in detail. These features are essential for improving user experience and enhancing security in hybrid identity environments.

This post assumes you’re familiar with basic security concepts like hashing and encryption. Don’t worry. I’ll explain everything in a clear and simple way! 😊

---

Goal

By the end of this exercise, you will:

Configure multiple authentication methods in Entra ID (Password Hash Sync, Pass-through Authentication).

Let's jump right in! :)

Recap what we have so far:

We deployed a virtual network and a server including all of its necessary components like network interface card, static private IP address (10.1.1.5). The server acts as a Domain Controller and a DNS server. We successfully synchronized users from on-premise to Entra ID.

Discussing the authentication options

While we value the on-premises data source, the focus is shifting towards leveraging the cloud to reduce reliance on on-premises resources.

One way to achieve this is by enabling Password Hash Synchronization (PHS). With PHS, authentication is handled by Entra ID, which uses a securely stored hash of the on-premises password hash to validate sign-in requests.

This approach allows users to continue using their familiar AD passwords, but authentication is managed entirely by Entra ID rather than the on-premises Active Directory. This shift enhances reliability, reduces dependency on on-premise infrastructure, and supports cloud-first strategies while providing a good user experience by eliminating the need to remember separate credentials. This also reduces helpdesk costs by minimizing the volume of password reset requests.

---

Are you ready to dig a little bit deeper in this topic?

How PHS works?

Active Directory domain service stores the user's password in a hash format. The hash is a result of a one-way mathematical function, there is no way to revert back to the original plain text.

On the DC passwords are stored as NT hashes, which are based on MD4 algorithm. You are right if you ask: isn't it weak? Indeed, MD4 is considered as a weak hash algorithm by modern standards, however it is used to ensure compatibility with older systems.

Don't worry. The process implement security features for the data in transit between the AD and the PHS agent on the Entra Connect Sync server. Entra Connect Sync agent will make sure the hash is secure enough to meet modern standards.

1. Sync:
Every 2 minutes the PHS agent queries the AD DC for the password hash, it uses a standard replication protocol called MS-DRSR.

The MS-DRSR (Directory Replication Service Remote Protocol) is an RPC(Remote Procedure Call) protocol that facilitates replication and management of Active Directory data between Domain Controllers.

2. Secure the hash before sending:
The DC creates a key from the MD5 hash of the RPC session key and a salt.
Encryption key = MD5# session key + a salt.

Salt is simply an added security mechanism, making the hash unique even if the passwords are the same.

3. Data transmit:
DC sends the encrypted hash, and the salt separately (the salt itself is not encrypted) to the PHS agent over RPC (Remote Procedure Call).

4. Decryption:
**The **synchronization agent uses the MD5 hash of the RPC session key combined with the salt to generate the decryption key. This key is then used to decrypt the encrypted MD4 password hash sent by the DC.

Just for fun: the decryption key is generated by the MD5CryptoServiceProvider which is .NET framework that provides a managed implementation of the MD5 hash algorithm.

If you worried about the MD4 not being secure enough you can relax :).
Entra Connect Sync makes sure the password hash is secure even by the strictest security standards. Let’s explore how it achieves this level of protection.

5. Making the hash secure:

a. Expanding the size of the hash from 16 bytes to 64 bytes.
b. The agent adds a 10 byte per-user salt to further protect the hash.
c. The 64 bytes hash and the 10 bytes user specific salt is combined and put through the Password-Based Key Derivation Function 2 (PBKDF2)
PBKDF2 applies the HMAC-SHA256 hashing algorithm 1,000 times to the input. This computational effort makes the hash much more resistant to attacks.
HMAC (Hash-based Message Authentication Code) with SHA-256 is a strong hashing algorithm used to generate a final 32-byte hash.

6. Sending to Entra ID:
The final 32 byte hash is sent to Entra ID over a secure TLS connection along with the user-specific salt and the iteration count.

7. Authentication:
When a user attempts to authenticate, their password undergoes the same hashing process. If the resulting hash matches the securely stored value, the user is successfully authenticated.

The user might have to enter their corporate credentials when authenticating to Entra ID even if they already authenticated on-prem. However, the "Keep me signed in" option creates a session cookie that allows users to stay signed in for up to 180 days.
The session cookies also follow corporate security policies, adding an assurance of security.

Additionally, you can minimize password prompts by configuring Microsoft Entra join or Microsoft Entra hybrid join devices. These configurations enable automatic sign-ins for users on their corporate devices when connected to the corporate network.

I hope this diagram I created helps you understand the process better, as it provides an overview about what is happening.

Checking the PHS status

If you remember we enabled PHS when we setup the Connect Sync:

We can, however, still enable or disable this option with Entra Connect Sync:

Configure sync options in Entra Connect:

Configure synchronization options:

Authenticate and go to Optional features:

Confirmation and troubleshooting

Let's check the status of the sync in Entra ID:

In the portal go to Entra ID » Microsoft Entra Connect » Connect Sync

You can see that the PHS is enabled.

Use the following command-line tool to validate sync status:

Invoke-ADSyncDiagnostics -PasswordSync

Let's review the output:

AAD Tenant - calcio15gmail.onmicrosoft.com
Password Hash Synchronization cloud configuration is enabled

» this means that the PHS is enabled on the Entra side. No issue here.

AD Connector - neontiger.local
Password Hash Synchronization is enabled
Latest Password Hash Synchronization heartbeat is detected at: 01/19/2025 16:33:28 UTC

» this means that the PHS is enabled on the AD side. It shows the latest heartbeat. No issue here.

Check the time of the latest sync:

Last successful attempt to synchronize passwords from this directory partition started at: 1/19/2025 4:5
1:29 PM UTC and ended at: 1/19/2025 4:51:29 PM UTC

Only Use Preferred Domain Controllers: False

Verify the connectivity to the domain:

Checking connectivity to the domain...
Domain "neontiger.local" is reachable

Let's assume you want to troubleshoot the PHS issue for one particular user.

At the end on the output it ask you:

Did you find Password Hash Sync General Diagnostics helpful? [y/n]: y

Your answer, yes or no it doesn't matter :).

The next question is:

Would you like to diagnose single object issues? [y/n]: y

Yes, you would like :).

Copy the distinguished name from: Users and Computers » Users » right click on the user » Properties » Attribute Editor » distinguishedName

Paste it:

Please enter AD connector space object Distinguished Name: CN=CloudUp1,CN=Users,DC=neontiger,DC=local

Check the output:

The object is available in the AD connector space - neontiger.local
The object is a connector, it has a link to the metaverse
The object is synced to the AAD connector space

» Here you can verify the status of the object in the connector space.

We would like to see this output at the end:

_Password hash is synchronized successfully _

NOTE:
You can run the Invoke-ADSyncDiagnostics cmdlet without any parameter and navigate through the different diagnostic options.
Feel free to explore it! :)

If that wasn't enough, then run this script that might further help you with the troubleshooting process:

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-password-hash-synchronization#get-the-status-of-password-sync-settings

Here is a comprehensive guide from Microsoft in case you face any issue here:

https://learn.microsoft.com/en-gb/entra/identity/hybrid/connect/tshoot-connect-password-hash-synchronization

This setup now should allow your users to sign-in to cloud applications with their on-premise password.

To verify this quickly, go to DC1 and select a user from your on-premises Active Directory. Use their credentials to sign in to office.com. Voilà, your user signed in to a cloud application without creating a username/password in that application.

Keep in mind that you set the default password for these users in the users.ps1 script. If you haven’t changed it since, you should already know what it is. 😊

---

Next up, we'll explore the Pass-through authentication as an alternate sign-in option.

Pass-through authentication (PTA)

Pass-through authentication (PTA) allows users to authenticate to cloud applications using their Active Directory (AD) credentials. However, in this case, the authentication is handled by the on-premises Active Directory rather than Entra ID.
This option is ideal for organisation that want to keep authentication processes within their own infrastructure for compliance or control reasons.

Note: only AD synced users can authenticate with this method.

How PTA works

Components involved in the PTA authentication:

Microsoft Entra Security Token Service (STS):
Stateless service used to handle sign-in requests and issue security tokens to browsers, clients, or services.

Azure Service Bus:
Azure Service Bus is a cloud-based messaging service enabling communication between applications and services. It offers features like message queues and publish-subscribe topics to decouple applications.
Publish-subscribe topics allow multiple publishers (any application, service, or component, whether on-premises or cloud-based) to send messages to a central topic, which subscribers can receive based on their filtering rules, ensuring efficient and scalable communication.

Microsoft Entra Connect Authentication Agent:
The on-premise component responsible for listening and responding to the password validation requests.

Azure SQL Database:
Holds authentication agents information including their metadata and encryption key.

Windows Server AD:
On-prem AD, where the user account and their associated password is stored.

Install and register authentication agents

You can enable PTA two ways:

1. When you first setup Entra Connect Sync:

Choose Pass-through authentication as a Sign-in option instead of Password Hash Sync.

1. Modify the Sign-in option with the Entra Connect Sync wizard

More on these options when we enable PTA in our environment.

The authentication agent is installed and registered with Entra ID when you enable PTA.

The preparation of the authentication agent involves three main phases:

• Installation
• Registration
• Initialization

Now, let's uncover each phase in details.

Installation

For the installation and registration process you need a user with either Hybrid Identity Administrator or a Global Admin.

Two methods available to install the agent:

Enabling Pass-Through Authentication (PTA) with Entra Connect:
This method integrates the authentication agent during the Entra Connect setup process.

Standalone Installation:
You can also install the authentication agent separately by downloading the installer and configuring it manually.

Agent registration:

1. After installation, the agent registers with Entra ID.
2. Entra then issues a certificate, facilitating secure communication between the agent and Entra ID. This process also binds the authentication agent to the tenant, ensuring Entra recognizes which agent is authorized to handle password validation requests.
3. This procedure must be repeated for each agent you register.

Let's see it in detail:

1. During setup, the Hybrid Identity Administrator (or Global Admin) authenticates to Entra ID. In the sign-in process the authentication agent receives an access token allowing it to act on behalf of the user.

2. The authentication agent generates an RSA 2048-bit public-private key pair. The private key is securely stored on the on-premises server where the agent resides.

Note:
As of now, RSA 2048-bit encryption is still in use. However, recent guidelines recommend upgrading to more secure encryption by the end of 2025. Stay tuned for Microsoft announcements to see if any action is needed from your side.

1. The authentication agent sends a registration request to Entra ID over HTTPS, including the components:

• The access token
• The public key
• A Certificate Signing Request (CSR) applying for the digital identity certificate

1. Entra verifies the request:
   Is come from an authorized user?
   The access token is valid?

2. The root CA in Entra ID signs the digital identity certificate, which is used exclusively for the PTA feature. The certificate's subject is the tenant ID, ensuring it can only be used with your tenant.

3. Entra ID stores the public key in an Azure SQL database, which is accessible only by Entra.

4. The on-premise server stores the certificate in the Windows certificate store (CERT_SYSTEM_STORE_LOCAL_MACHINE).

Initialization:

1. The authentication agent send a secure request to Entra ID to start the process.
   Over port 443.

2. Entra provides an access key for a unique Service Bus queue linked to your tenant.

3. The agent establishes a secure (HTTPS)connection to this queue.

If you have multiple authentication agents, the initialization process ensures that the agents connects to the same Service Bus queue.

Now, we will dive into how the actual sign-in requests are handled.

PTA Sign-in requests:

1. When a user tries to access an application like Outlook Web App and is not signed in, the app redirects the browser to the Entra ID sign-in page. The Entra STS service then responds with the sign-in page.

2. User enters his/her credentials.

3. Entra STS encrypts the password with the public key of the registered authentication agents (retrieved from Azure SQL Databese) producing one encrypted password for each registered authentication agent.

4. In the next step, the Entra STS places the encrypted password into the Service Bus queue specific to your tenant.

5. During the initialization phase, the authentication agent configured a persistent connection to the Service Bus queue, allowing it to retrieve password validation requests.

6. The authentication agent decrypts the password with it's private key.

7. The authentication agent validate the username/password with AD DS.

8. The result is retrieved from AD DS is either success, username/password incorrect, or password expired.

Here is a diagram explaining the PTA sign-in process:

Transmitting passwords between servers needs strong security measures. We'll talk about these measures in the next section.

PTA security capabilities

Secure multi-tented architecture:

Even though Entra is built on a shared infrastructure, each tenant's data and sign-in requests are completely isolated from one another, ensuring the organization's data remains secure and private.

On-premises passwords are not stored in the cloud

The connection from the authentication agents is outbound only:
The agent initiates a connection to Entra ID and retrieves password validation requests by making an outbound connection to the Service Bus queue.
This makes sure that only outbound ports (80, 443) required:

• 443 for all authenticated communications.
• 80 to download certificate revocation lists (CRLs)

Passwords used are encrypted in the cloud before sending it to the on-premise infrastructure using a secure HTTPS channel.

Works with Entra features for protecting the identity:

• Conditional access policies
• MFA
• Block legacy authentication
• Smart lockout

Important considerations:

Since this solution relies on the on-premise infrastructure configure more than one server hosting authentication agent for high reliability.
Treat them as Tier 0 systems:
Tier 0 systems are the most critical assets in the organisation. These systems are highly privileged, must be strictly managed and protected.

Now, that you are equipped with the necessary understanding about the PTA let's configure it in our environment!

As already mentioned, you can enable PTA two ways:

1. When you first setup Entra Connect Sync:

Choose Pass-through authentication as a Sign-in option instead of Password Hash Sync.

Check out the note there:
Microsoft recommends that the user performing the Pass-through Authentication (PTA) setup should be a cloud-only user. This is crucial because, once Pass-through Authentication is enabled, hybrid users will be unable to sign in if there is a service disruption to the on-premises Active Directory.

To avoid being locked out, ensure you have cloud only account that can manage sign-in options (and Entra).

1. Modify the Sign-in option with the Entra Connect Sync wizard

Click Configure in Entra Connect Sync.

Choose Change user sign-in.

Authenticate with your Hybrid Identity Admin or Global admin user.

Change the Sign-in to Pass-through authentication.

Click Next.

Now the Entra Connect Sync will install and initialize the authentication agent.

Click Configure and wait for the wizard to complete the task.

Password hash synchronization (PHS) is enabled, as shown. It is a good practice to enable PHS even if you are using Pass-through Authentication (PTA). This is because Microsoft continuously monitors the dark web for leaked credentials and can notify you if any of your users' credentials are compromised.

You can also use Password hash sync as a fallback option in case PTA experiences issues (e.g., connectivity or service outages with the on-premises agent).

If you want to disable, run the wizard again and change the settings in Customize synchronization options. Disable Password hash sync.

Check if the PTA is enabled correctly:

Here's another useful troubleshooting technique using the Invoke-ADSyncDiagnostics cmdlet:

We'll create a log file that displays the status of the synchronization process.

Run the cmdlet, enter: 3 and wait for the result. The log file will open in Internet Explorer.

The log file will provide a comprehensive overview for every aspect of Entra Connect Sync. Look for the Microsoft.UserSignIn.SignOnMethod:

Check it in Entra portal:

Entra ID » Microsoft Entra Connect » Connect Sync:

You can see it is Enabled.

Click on the Pass-through authentication to check the status.

The recommendation emphasise the importance of having multiple (at least 3) authentication agent for high availability.

This is the end of this lab and overview of the different authentication options.
Still there are a lot to discuss.
In the next session we will discuss and enable SSO.