Organizations operating Hybrid Identity Environments need a reliable method for allowing Users whose Identities Originate in On-Premises Active Directory Domain Services (AD DS) to Authenticate to Microsoft Entra ID and Cloud Applications.
Two of the Primary Cloud Authentication Methods available for hybrid identities are Password Hash Synchronization (PHS) and Pass-through Authentication (PTA).
Both allow Users to use the same Password for On-Premises and Cloud Resources, but the Authentication Architecture is fundamentally different.
With Hash Synchronization (PHS) , Microsoft Entra ID performs the Authentication. A derived representation of the User's On-Premises Password Hash is synchronized to Microsoft Entra ID.
With Pass-through Authentication (PTA), Microsoft Entra ID receives the Authentication Request, but the Password is validated against the Organization's On-Premises Active Directory through Pass-through Authentication Agents.
This architectural difference affects availability, Security, Infrastructure requirements, Disaster Recovery, Operational Complexity, and the Organization's Dependency on its On-Premises Environment.
At a High Level:
Hash Synchronization (PHS)
User → Microsoft Entra ID → Cloud Authentication
Pass-through Authentication (PTA)
User → Microsoft Entra ID → PTA Agent → Domain Controller → Active Directory Authentication
Microsoft recommends Password Hash Synchronization (PHS) as the simplest and most resilient Hybrid Authentication Option because Authentication can continue without dependency on the On-Premises Active Directory Environment after the required Identity and Password Information has been Synchronized.
What is Password Hash Synchronization?
Password Hash Synchronization (PHS) is a Microsoft Entra Hybrid Identity Authentication Method that Synchronizes a derived representation of a User's Password hash from On-Premises Active Directory to Microsoft Entra ID.
Despite the name, Microsoft Entra Connect does not simply upload the Active Directory Password hash directly into Microsoft Entra ID.
Additional Cryptographic processing is performed before the resulting value is Transmitted to Microsoft Entra ID.
The User's Plaintext Password is Never Synchronized.
Once Synchronization has occurred, Microsoft Entra ID can Authenticate the User directly.
The architecture therefore looks like this:
On-Premises Active Directory
│
│ Password Hash Synchronization
▼
Microsoft Entra Connect
│
│ Derived Password Hash
▼
Microsoft Entra ID
│
▼
Cloud Applications
During Authentication:
User
│
│ Username + Password
▼
Microsoft Entra ID
│
│ Validate Cloud Credential
▼
Authentication Successful
The important architectural characteristic is that the user's domain controller is not contacted during normal Microsoft Entra authentication.
Microsoft Entra ID performs the Authentication.
This dramatically reduces the dependency of cloud authentication on the availability of the organization's Datacenter, Domain Controllers, Microsoft Entra Connect server, WAN connectivity, and other On-Premises Infrastructure.
Password Hash Synchronization Prerequisites
Before deploying Password Hash Synchronization (PHS) , several infrastructure and identity requirements must be satisfied.
Microsoft Entra Tenant
The organization must have a Microsoft Entra tenant containing or receiving the synchronized hybrid identities.
Active Directory Domain Services
The organization must have an on-premises Active Directory environment containing the users that will be synchronized.
Microsoft Entra Connect Sync or Supported Synchronization Architecture
Microsoft Entra Connect Sync can synchronize identities and password hashes between Active Directory and Microsoft Entra ID.
The Microsoft Entra Connect server should be domain joined and appropriately secured.
Microsoft currently recommends Windows Server 2025 or Windows Server 2022 for Microsoft Entra Connect installations. Microsoft also classifies the Microsoft Entra Connect server as a highly privileged identity infrastructure component that should be protected accordingly.
Important: Microsoft has announced that Microsoft Entra Connect synchronization services running versions earlier than 2.5.79.0 will stop working on September 30, 2026. Existing environments should verify their Microsoft Entra Connect version and upgrade where necessary.
Active Directory Permissions
The AD DS Connector account requires permissions that allow Microsoft Entra Connect to retrieve the Password Information required for Synchronization.
For Password Hash Synchronization, the account requires:
Replicate Directory Changes
Replicate Directory Changes All
These Permissions allow Microsoft Entra Connect to retrieve the Password Hashes through the Active Directory Replication Mechanism.
Network Connectivity
Microsoft Entra Connect requires connectivity to:
On-premises Active Directory Domain Controllers
Microsoft Entra ID endpoints
Required Microsoft identity and synchronization services
TLS 1.2 must be available for supported Microsoft Entra Connect communications.
How Password Hash Synchronization Works
Password Hash Synchronization uses a considerably more sophisticated process than simply copying the NTLM hash from Active Directory into Microsoft Entra ID.
The simplified process is:
User Password
│
▼
Active Directory Password Hash
│
▼
Microsoft Entra Connect
│
│ Additional Hashing + Salt
▼
Derived Password Hash
│
│ TLS
▼
Microsoft Entra ID
Microsoft Entra Connect's Password Hash Synchronization Agent requests password hashes from a Domain Controller through the standard Active Directory Replication Protocol.
The Synchronization Process operates independently from the normal Directory Synchronization Schedule. Password Synchronization checks occur approximately every Two Minutes, and Microsoft does not provide a supported mechanism for changing this interval.
The detailed process is:
- Microsoft Entra Connect requests the User's Stored Password Hash from an Active Directory Domain Controller using the standard Domain Controller Replication Mechanism.
- The Domain Controller securely transfers the required Password-Hash Information to Microsoft Entra Connect.
- Microsoft Entra Connect processes the Active Directory MD4 Password Hash in Memory.
- Microsoft Entra Connect expands the original Hash Representation.
- A unique Per-User Salt is added.
- Additional Cryptographic processing using PBKDF2 and HMAC-SHA256 is performed.
- The resulting derived Password Hash, Salt, and required processing Information are transmitted to Microsoft Entra ID over TLS.
- Microsoft Entra ID stores the derived representation required for Authentication.
The original Active Directory MD4 password hash is not transmitted to Microsoft Entra ID.
Microsoft also states that password hash values are processed in memory and are not stored in the Microsoft Entra Connect SQL database.
When the user subsequently authenticates:
User enters password
│
▼
Microsoft Entra ID
│
▼
Equivalent cryptographic processing
│
▼
Compare calculated result
with stored derived hash
│
├── Match ──► Authentication Successful
│
└── No Match ► Authentication Failed
The on-premises Domain Controller does not participate in this authentication transaction.
Step-By-Step Password Hash Synchronization Deployment
The exact screens can change between Microsoft Entra Connect versions, but the deployment architecture remains consistent.
Step 1: Prepare Active Directory
Verify Active Directory health before deploying synchronization.
Confirm:
DNS resolution is functioning correctly.
Domain Controllers are healthy.
Active Directory replication is healthy.
User Principal Names are configured correctly.
The Active Directory forest and domains intended for synchronization are reachable from the Microsoft Entra Connect server.
Step 2: Prepare Microsoft Entra ID
Verify that the appropriate custom domains have been added and verified in Microsoft Entra ID.
For Example: contoso.com
Users should ideally have routable UPNs that correspond to verified Microsoft Entra Domains.
Example: user@contoso.com
rather than: user@contoso.local
Step 3: Prepare the Microsoft Entra Connect Server
Deploy a dedicated or appropriately protected Windows Server.
The Server should:
Be Domain Joined.
Have required connectivity to Domain Controllers.
Have outbound connectivity to required Microsoft endpoints.
Meet Microsoft Entra Connect hardware and software requirements.
Be protected as privileged identity infrastructure.
Step 4: Install Microsoft Entra Connect
Launch the Microsoft Entra Connect installation.
Organizations using a simple single-forest topology can use Express Settings where appropriate.
Password Hash Synchronization is automatically enabled when Microsoft Entra Connect is installed using Express Settings.
Complex environments should use Customize.
Step 5: Configure Directory Synchronization
Configure:
Microsoft Entra Tenant
Active Directory Forest
Directory Credentials
Domain and OU Filtering
Optional Synchronization Features
User Sign-In Configuration
Step 6: Select Password Hash Synchronization
Under the User Sign-In configuration, select:
Password Hash Synchronization
Complete the remaining Microsoft Entra Connect configuration.
Step 7: Perform Initial Synchronization
Microsoft Entra Connect performs the initial directory synchronization.
When Password Hash Synchronization is enabled for the first time, password hashes for the synchronized users are processed and synchronized.
Step 8: Verify Synchronization
Verify that synchronized users appear correctly in Microsoft Entra ID.
Confirm:
UPN
Display Name
Synchronization status
Source
Group membership where applicable
Step 9: Test Authentication
Use a test account to authenticate to a Microsoft Entra-integrated application.
For Example:
Microsoft 365
Azure Portal
Enterprise Application
My Apps
Verify that the user’s on-premises Active Directory password successfully authenticates against Microsoft Entra ID.
Step 10: Test Password Changes
Change the test user’s password in Active Directory.
Wait for Password Hash Synchronization.
Verify that the new password successfully authenticates to Microsoft Entra ID.
Password changes are generally synchronized within minutes because the Password Hash Synchronization process runs every two minutes.
When Should You Use Password Hash Synchronization?
Password Hash Synchronization should generally be the preferred option when the organization wants:
Maximum Cloud Authentication Resilience
Microsoft Entra authentication does not depend on the availability of on-premises Domain Controllers.
Minimal Infrastructure
No authentication agents are required to process each authentication request.
Reduced Operational Complexity
There are fewer authentication components to deploy, monitor, patch, and troubleshoot.
Cloud-First Architecture
Organizations moving workloads toward Microsoft 365, Azure, SaaS, and Microsoft Entra-integrated applications can reduce their authentication dependency on the datacenter.
Protection Against On-Premises Outages
A failure involving the datacenter, Domain Controllers, Microsoft Entra Connect, or the WAN does not immediately prevent already-synchronized users from authenticating to Microsoft Entra ID.
Microsoft Entra ID Protection Capabilities
Password Hash Synchronization enables Microsoft Entra ID Protection to compare synchronized credentials against credentials Microsoft identifies as leaked.
Password Hash Synchronization Components
A typical Password Hash Synchronization deployment contains:
Active Directory Domain Services
Stores the authoritative on-premises user identities and password hashes.
Domain Controllers
Provide the Password Information to Microsoft Entra Connect through the Active Directory Replication Mechanism.
Microsoft Entra Connect Sync
Synchronizes identities and Password-Derived Information to Microsoft Entra ID.
AD DS Connector
Connects Microsoft Entra Connect to Active Directory.
Microsoft Entra Connector
Connects the synchronization engine to Microsoft Entra ID.
Password Hash Synchronization Agent
Processes the Password Hash Synchronization Workflow.
Microsoft Entra ID
Stores the derived Password representation and performs Cloud Authentication.
Microsoft Entra Applications
Applications such as Microsoft 365, Azure, and SaaS applications rely on Microsoft Entra ID authentication.
Password Hash Synchronization Best Practices
Use Password Hash Synchronization as the Default Hybrid Cloud Authentication Method unless there is a Specific Technical, Security, Regulatory, or Organizational requirement for another Authentication Architecture.
Keep Microsoft Entra Connect current and supported.
Monitor Synchronization Health.
Use Microsoft Entra Connect Health where appropriate.
Maintain accurate UPNs.
Limit Synchronization Scope to required objects.
Use staged rollout when Migrating from another Authentication Method.
Test Authentication changes with Controlled Groups before broad deployment.
Maintain documented Disaster Recovery Procedures for Microsoft Entra Connect.
Remember that failure of Microsoft Entra Connect stops Synchronization but does not immediately stop Microsoft Entra Authentication for Users whose Credentials have already been Synchronized.
Password Hash Synchronization Security Best Practices
The Microsoft Entra Connect server should be treated as Highly Privileged Infrastructure.
Microsoft specifically recommends protecting Microsoft Entra Connect as a Tier 0 / Control Plane component.
Administrative access should therefore be extremely limited.
Use dedicated Administrative identities where appropriate.
Do not install unnecessary applications on the Microsoft Entra Connect Server.
Do not use the Server for General Administration, Web Browsing, Email, or Unrelated Workloads.
Keep Windows Server and Microsoft Entra Connect Fully Patched.
Protect Administrative Authentication with strong Authentication Controls.
Monitor Synchronization-Related Security Events.
Restrict Interactive Logon.
Apply appropriate Endpoint Protection.
Monitor Privileged Group Membership.
Secure the underlying Active Directory Environment.
Use Conditional Access and MFA to Protect Cloud Identities.
Use Microsoft Entra ID Protection where Licensing Permits.
What is Pass-through Authentication?
Microsoft Entra Pass-through Authentication (PTA) is a hybrid authentication method in which Microsoft Entra ID passes the User's Authentication request to an On-Premises Authentication Agent, which validates the Password Directly against Active Directory.
Unlike Password Hash Synchronization, Pass-through Authentication (PTA) does not rely on a Synchronized Cloud Password Hash to perform the Normal Authentication.
The architecture is:
User
│
▼
Microsoft Entra ID
│
▼
Pass-through Authentication Service
│
▼
PTA Authentication Agent
│
▼
Active Directory Domain Controller
│
▼
Authentication Result
│
▼
Microsoft Entra ID
The User still interacts with Microsoft Entra ID.
However, the Password Validation Occurs Against the Organization's Active Directory Environment.
Microsoft describes PTA as an alternative for Organizations that want Cloud Authentication while validating Passwords directly Against On-Premises Active Directory.
How Pass-through Authentication Works
Assume a user attempts to access Microsoft 365.
User
│
▼
Microsoft 365
│
▼
Microsoft Entra ID
│
▼
Authentication Request
│
▼
PTA Agent
│
▼
Domain Controller
│
▼
Active Directory
The process operates approximately as follows:
- The User Accesses an Application protected by Microsoft Entra ID.
- The Application redirects the user to Microsoft Entra ID.
- The User enters a Username.
- Microsoft Entra ID determines that the domain uses Pass-through Authentication.
- The User provides the Password.
- Microsoft Entra ID securely places the Authentication request into the Pass-through Authentication Infrastructure.
- An available on-premises PTA Agent retrieves the Authentication request through its Outbound Connection.
- The PTA Agent validates the Credentials against Active Directory.
- Active Directory returns the Authentication result to the PTA Agent.
- The PTA Agent securely returns the result to Microsoft Entra ID.
- Microsoft Entra ID applies the remaining Authentication Controls.
These can include:
Conditional Access
Multifactor Authentication
Identity Protection
Device requirements
Session controls
- Microsoft Entra ID issues the appropriate authentication token when authentication succeeds.
PTA therefore maintains a real-time dependency on the organization's on-premises Active Directory environment.
Step-By-Step Pass-through Authentication Deployment
Step 1: Verify Active Directory Health
Before deployment, verify:
Domain Controller availability
DNS
Active Directory replication
User UPN configuration
Network connectivity
Time synchronization
Step 2: Prepare Microsoft Entra ID
Verify the Organization's Domains in Microsoft Entra ID.
Confirm that Synchronized Users have appropriate UPNs.
Step 3: Prepare Microsoft Entra Connect
Deploy Microsoft Entra Connect on a supported, Domain-Joined Windows Server.
Verify connectivity to:
Active Directory Domain Controllers
Microsoft Entra ID
Required Microsoft authentication endpoints
Step 4: Install Microsoft Entra Connect
Start Microsoft Entra Connect.
Choose the appropriate configuration method.
For environments requiring PTA, use the configuration path that allows selection of the user sign-in method.
Step 5: Select Pass-through Authentication
Select:
Pass-through Authentication
Optionally configure:
Enable Single Sign-On if Seamless SSO is required.
Seamless SSO can operate with either Password Hash Synchronization or Pass-through Authentication.
Step 6: Complete Microsoft Entra Connect Configuration
Configure:
Active Directory Forest
Microsoft Entra Tenant
Synchronization Scope
OU Filtering
Optional Features
User Sign-In Settings
Complete the Configuration.
Step 7: Verify the First PTA Agent
Enabling PTA through Microsoft Entra Connect installs the initial Authentication Agent.
Verify that the agent is registered and active.
Step 8: Deploy Additional Authentication Agents
Do not design production PTA around a Single Agent.
Microsoft recommends deploying three Authentication Agents for high availability: the initial agent plus two additional agents.
A production architecture could therefore look like:
Microsoft Entra ID
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
PTA Agent 1 PTA Agent 2 PTA Agent 3
│ │ │
└───────────┼───────────┘
│
▼
Domain Controllers
│
▼
Active Directory
Step 9: Test Authentication
Use a Synchronized Test Account.
Authenticate to a Microsoft Entra Application.
Verify successful Authentication.
Step 10: Test Agent Failure
Stop or isolate one PTA Agent.
Verify that Authentication continues through another Agent.
Step 11: Test Infrastructure Failure Scenarios
Production testing should consider:
PTA Agent Failure
Domain Controller Failure
Internet Connectivity Failure
Datacenter Failure
DNS Failure
Firewall Failure
Network Segmentation Failure
The purpose is to verify that no Single Infrastructure Component can unnecessarily stop Authentication.
Pass-through Authentication Agents
The Microsoft Entra Pass-through Authentication Agent is the On-Premises Component responsible for validating Authentication requests against Active Directory.
Agents establish Outbound Connections to Microsoft Services.
This is an important Architectural Characteristic because Organizations do not need to expose Domain Controllers or Pass-through Authentication Agent directly to Inbound Internet Authentication Traffic.
The Pass-through Authentication Agent retrieves Authentication requests, validates them against Active Directory, and returns the result.
Because the Pass-through Authentication Agent Participate Directly in Authentication, their availability is Critical.
A single Pass-through Authentication Agent represents an unacceptable Availability Dependency for most Enterprise Production Environments.
Microsoft recommends three Pass-through Authentication Agent to provide High Availability and Maintenance Flexibility.
Pass-through Authentication Agent Prerequisites
Each Pass-through Authentication Agent requires:
A supported Windows Server.
Connectivity to Active Directory Domain Controllers.
DNS resolution for the Active Directory Environment.
Outbound Internet connectivity requires Microsoft Endpoints.
TLS Support.
Appropriate Firewall Configuration.
Reliable Network Connectivity.
The server must be able to reach Domain Controllers because every Pass-through Authentication (PTA) Authentication Request ultimately requires credential validation against Active Directory.
Microsoft specifically notes that Pass-through Authentication Agent require Network Access to Domain Controllers and should not be deployed in a perimeter network/DMZ as a method of isolating them from the Internal Directory Environment.
When Should You Use Pass-through Authentication?
Pass-through Authentication (PTA) should be considered when an organization has a specific requirement for passwords to be validated directly against Active Directory.
Examples Include Environments where:
Authentication must reflect certain On-Premises Active Directory Account Conditions Immediately.
The Organization requires direct Active Directory Password Validation.
Internal Security Architecture requires On-Premises Credential Validation.
A regulatory or Organizational Requirement Prevents the Organization from relying exclusively on Cloud Password-Hash Authentication.
The organization accepts the infrastructure dependency associated with On-Premises Authentication.
Pass-through Authentication (PTA) should not be selected simply because Synchronizing a Password Hash sounds less secure.
Password Hash Synchronization does not Synchronize the Plaintext Password, nor does it simply upload the original Active Directory Password Hash to Microsoft Entra ID. Microsoft Applies additional Cryptographic processing before transmitting the derived value.
Pass-through Authentication Prerequisites
A complete Pass-through Authentication (PTA) Deployment requires:
Microsoft Entra Tenant
On-premises Active Directory Domain Services
Synchronized Hybrid Identities
Microsoft Entra Connect or an appropriate Synchronization Architecture
PTA Authentication Agents
Reliable Domain Controllers
DNS Infrastructure
Internal Network Connectivity
Outbound Internet Connectivity
Appropriate Firewall Configuration
High Availability
Monitoring
Operational procedures for Authentication-Agent Maintenance
Users must first be provisioned into Microsoft Entra ID from On-Premises Active Directory. Pass-through Authentication (PTA) does Not Provide Authentication for Cloud-Only Identities in the same Manner because there is no corresponding On-Premises Active Directory identity Against which the Pass-through Authentication (PTA) Agent can validate the Password.
Pass-through Authentication Components
A production Pass-through Authentication (PTA) environment contains several important components.
Microsoft Entra ID
Receives the User's Authentication request and coordinates the cloud authentication process.
Microsoft Entra Pass-through Authentication Service
Coordinates Authentication requests between Microsoft Entra ID and available Pass-through Authentication (PTA) Agents.
Pass-through Authentication (PTA) Agents
Retrieve and validate Authentication requests.
Active Directory Domain Controllers
Perform the underlying Active Directory credential validation.
Active Directory Domain Services
Contains the Authoritative On-Premises Identities and Credentials.
Microsoft Entra Connect
Synchronizes user identities and can install/configure the initial Pass-through Authentication (PTA) Agents.
Network Infrastructure
Provides connectivity between Pass-through Authentication (PTA) Agents, Domain Controllers, DNS, and Microsoft Cloud Services.
Microsoft Entra Applications
Consume the authentication tokens issued after Successful Authentication.
Pass-through Authentication Best Practices
Deploy at least three PTA Agents for Enterprise Production Environments, following Microsoft's High-Availability recommendation.
Distribute Agents Across failure boundaries where practical.
Do not place all Pass-through Authentication (PTA) Agents on the same Virtualization Host.
Do not make all Pass-through Authentication (PTA) Agents dependent on the same Network Path.
Ensure agents can reach multiple Domain Controllers.
Monitor Pass-through Authentication (PTA) Agent Health.
Keep Agents Updated.
Monitor Domain Controller Availability.
Document Firewall Requirements.
Test Pass-through Authentication (PTA) Agent Failover.
Test Domain Controller Failover.
Test Internet Failure Scenarios.
Monitor Authentication Latency.
Maintain Password Hash Synchronization (PHS) as a Disaster-Recovery Authentication option where organizational requirements permit it.
Pass-through Authentication Security Best Practices
Treat Pass-through Authentication (PTA) Agent Servers as sensitive identity infrastructure.
Restrict Administrative Access.
Do not install unnecessary Software.
Do not use Pass-through Authentication (PTA) Agent Servers for General-Purpose Administration.
Apply Windows Server Security Baselines.
Keep Servers and Pass-through Authentication (PTA) Agents Patched.
Use Endpoint Protection.
Monitor Security Logs.
Protect Service Identities.
Restrict Privileged Logon Rights.
Maintain Secure Domain Controllers.
Segment Identity Infrastructure Appropriately.
Monitor Outbound Network Connectivity.
Protect Microsoft Entra Administrative Accounts with MFA.
Use Conditional Access.
Use privileged Administrative Workstations where Appropriate.
Monitor Microsoft Entra Sign-In and Risk Events.
Most Importantly, Recognize that compromising a Pass-through Authentication (PTA) Agent or the Infrastructure Surrounding it represents an Identity Security Concern because the Agent Participates directly in the Authentication Path.
Password Hash Synchronization (PHS) vs. Pass-through Authentication (PTA)
The architectural differences become clearer when the two technologies are compared directly.
|
Capability |
Password Hash Synchronization |
Pass-through Authentication |
|
Authentication location |
Microsoft Entra ID |
On-premises Active Directory |
|
Password hash synchronized |
Yes, a derived hash-of-hash representation |
Not required for primary PTA authentication |
|
Plaintext password synchronized |
No |
No |
|
Domain Controller required during cloud authentication |
No |
Yes |
|
Microsoft Entra Connect required during each authentication |
No |
No |
|
PTA Agent required |
No |
Yes |
|
Dependency on on-premises network during authentication |
No |
Yes |
|
Dependency on Domain Controllers during authentication |
No |
Yes |
|
Authentication infrastructure complexity |
Low |
Higher |
|
Authentication resilience during datacenter outage |
High |
Requires working PTA infrastructure and AD |
|
Authentication Agent high availability |
Not applicable |
Required for production design |
|
Microsoft recommended PTA Agent count |
Not applicable |
Three |
|
Supports Seamless SSO |
Yes |
Yes |
|
Suitable for cloud-first architecture |
Excellent |
Possible, but retains on-premises dependency |
|
Operational overhead |
Lower |
Higher |
|
Can provide backup authentication for PTA |
Primary method |
PHS can be maintained as backup |
|
Automatic PTA-to-PHS disaster failover |
Not applicable |
No |
When Should I Choose One Over the Other?
For most organizations, the decision should begin with Password Hash Synchronization (PHS) .
Microsoft describes Password Hash Synchronization (PHS) as the simplest and most resilient Hybrid Authentication Option.
Choose Password Hash Synchronization (PHS) when:
You want Maximum Cloud Authentication Availability.
You want Minimal Infrastructure.
You want to reduce Dependency on the Datacenter.
You want Authentication to continue during Domain Controller Outages.
You want Lower Administrative Overhead.
You are moving toward a Cloud-First Identity Architecture.
You do not have a specific requirement for Real-Time Password Validation Against Active Directory.
Choose Pass-through Authentication when:
You have a defined requirement for Password Validation to occur directly Against On-Premises Active Directory.
Your security or regulatory Architecture requires On-Premises Authentication.
Your organization accepts the additional availability and infrastructure requirements.
You can provide redundant PTA Agents, Domain Controllers, Networking, DNS, and Internet Connectivity.
The Architectural Question is therefore not simply:
Which Authentication Technology is more secure?
A better Question is:
Where does the organization require the User's Password to be validated?
If the answer is:
Microsoft Entra ID then Password Hash Synchronization is generally the better Architecture.
If the answer is:
Our Active Directory Domain Controllers then Pass-through Authentication provides that Architecture.
Password Hash Synchronization vs. Pass-through Authentication: How Do They Work Together?
Password Hash Synchronization and Pass-through Authentication (PTA) are sometimes presented as mutually exclusive technologies.
From the perspective of the Primary Authentication Method, they are.
A User's Cloud Authentication request is Normally Processed using the configured Authentication Method.
However, Password Hash Synchronization can also be enabled while Pass-through Authentication (PTA) remains the Primary Authentication Method.
This produces an important disaster-recovery architecture.
Normal Operation
User
│
▼
Microsoft Entra ID
│
▼
PTA Agent
│
▼
Active Directory
│
▼
Authentication
At the same time:
Active Directory
│
│ Password Hash Synchronization
▼
Microsoft Entra Connect
│
▼
Microsoft Entra ID
The Password-Derived Information is therefore already available in Microsoft Entra ID even though PTA is handling Normal Authentication.
If the On-Premises Authentication Environment Experiences a Major Outage:
PTA Agents
X
Domain Controllers
X
Datacenter
X
The Organization has the Option of changing its Authentication Method to Password Hash Synchronization.
The Architecture then becomes:
User
│
▼
Microsoft Entra ID
│
▼
Cloud Password Authentication
│
▼
Application
This can allow cloud authentication to continue even though the on-premises authentication infrastructure is unavailable.
However, there is One Extremely Important Detail:
Failover from Pass-through Authentication to Password Hash Synchronization is not automatic.
Microsoft states that Administrators must manually change the Sign-In Method when Pass-through Authentication (PTA) is unavailable and Password Hash Synchronization (PHS)
is being used as the Backup Authentication Method.
Therefore, organizations using this architecture should create and test a documented Authentication Disaster-Recovery Procedure.
Recommended Enterprise Architecture
For organizations that specifically require PTA, a resilient hybrid authentication architecture can look like this:
USERS
│
▼
Microsoft Entra ID
│
┌─────────────┴─────────────┐
│ │
│ Primary Authentication │
▼ │
Pass-through Authentication │
│ │
┌──────┼──────┐ │
│ │ │ │
▼ ▼ ▼ │
PTA-1 PTA-2 PTA-3 │
│ │ │ │
└──────┼──────┘ │
│ │
▼ │
Domain Controllers │
│ │
▼ │
Active Directory │
│ │
│ Password Hash Sync │
▼ │
Microsoft Entra Connect ───────────┘
Under Normal Conditions:
Pass-through Authentication (PTA) Authenticates Users against Active Directory.
In the Background:
Password Hash Synchronization (PHS) keeps Password-Derived Authentication Information Synchronized to Microsoft Entra ID.
During a Major On-Premises Authentication Failure:
Administrators can switch the Tenant Authentication Method from Pass-through Authentication (PTA) to Password Hash Synchronization (PHS).
This provides Significantly Greater Disaster-Recovery Capability than operating PTA without Synchronized Password Hashes.
If Password Hash Synchronization (PHS) is already enabled alongside Pass-through Authentication (PTA), switching the Tenant's Primary Authentication Method is done from the Microsoft Entra Connect Wizard. Microsoft explicitly notes that PTA does Not Automatically Fail Over to PHS; the Sign-In Method must be Changed Manually.
Switch from Password Hash Synchronization (PHS) to Pass-through Authentication (PTA)
On the active Microsoft Entra Connect server:
- Launch Microsoft Entra Connect.
- Select Configure.
- Select Change User Sign-In.
- Click Next.
- Authenticate to Microsoft Entra ID with the required Administrative Credentials.
- On User Sign-In, change:
Pass-Through Authentication
to:
Password Hash Synchronization
- Keep Enable Single Sign-On selected if you currently use Seamless SSO and want to retain it.
- Continue to Ready to configure.
- Select Configure.
- When configuration completes, select Exit.
Microsoft documents Change User Sign-In specifically for switching between Password Hash Synchronization (PHS) , Pass-through Authentication (PTA) and Federation.
The authentication path changes from:
BEFORE — Pass-through Authentication (PTA)
User
│
▼
Microsoft Entra ID
│
▼
PTA Agent
│
▼
Domain Controller
│
▼
Active Directory
to: AFTER — Password Hash Synchronization (PHS)
User
│
▼
Microsoft Entra ID
│
▼
Password validated using
synchronized password hash
│
▼
Authentication Successful
The important prerequisite is that Password Hash Synchronization (PHS) needs to have been enabled and Password Hashes Synchronized before you need the Emergency Switch. Microsoft recommends implementing Password Hash Synchronization (PHS) where possible specifically to improve Hybrid Authentication Resilience.
Authentication Failure Comparison
Consider a Complete On-Premises Datacenter Outage.
Password Hash Synchronization (PHS)
On-Premises Datacenter
X
Microsoft Entra Connect
X
Domain Controllers
X
│
│ No Immediate Authentication Impact
▼
Microsoft Entra ID
│
▼
User Authentication
│
▼
Microsoft 365 / Azure / SaaS
Already Synchronized Users can continue Authenticating to Microsoft Entra ID because Authentication Occurs in the Cloud.
Synchronization Stops until the On-Premises Infrastructure returns, but existing Synchronized Authentication Data Remains Available.
Pass-through Authentication (PTA)
User
│
▼
Microsoft Entra ID
│
▼
PTA Agent
X
│
▼
Domain Controller
X
Authentication cannot be completed through Pass-through Authentication (PTA) when the required On-Premises Authentication Infrastructure is unavailable.
If Password Hash Synchronization has also been enabled, administrators can invoke the documented Disaster-Recovery Procedure and switch authentication to Password Hash Synchronization (PHS).
This difference is one of the most important Architectural Considerations when selecting a Hybrid Authentication Method.
Final Recommendation
For new Microsoft Entra Hybrid Identity Deployments, Password Hash Synchronization (PHS) should generally be the Starting Point unless the Organization has a specific requirement that makes Pass-through Authentication (PTA) necessary.
Password Hash Synchronization (PHS) provides a simpler Authentication Architecture:
AD DS
│
│ Synchronization
▼
Microsoft Entra ID
│
│ Authentication
▼
Users
Pass-through Authentication (PTA) provides direct Active Directory Password Validation but introduces additional dependencies:
Microsoft Entra ID
│
▼
PTA Agents
│
▼
Network
│
▼
DNS
│
▼
Domain Controllers
│
▼
Active Directory
That additional dependency is not inherently wrong. In some organizations it exists because of a deliberate security, regulatory, or architectural requirement.
But it Should be a Deliberate Decision.
For organizations that require Pass-through Authentication (PTA), enabling Password Hash Synchronization alongside Pass-through Authentication (PTA) provides an important Additional Resilience Mechanism. Microsoft specifically recommends considering Password Hash Synchronization (PHS) as a Backup Authentication Method for Pass-through Authentication (PTA).
The resulting Enterprise Strategy is straightforward:
PHS only: Simplest, Cloud-Resilient Architecture.
PTA only: Direct Active Directory authentication, but greater dependency on on-premises infrastructure.
PTA + PHS: PTA performs normal authentication while synchronized password hashes provide a potential disaster-recovery path.
For most modern Microsoft Entra hybrid environments, reducing unnecessary dependencies while maintaining strong security and recoverability makes Password Hash Synchronization the preferred architecture, while Pass-through Authentication remains appropriate when direct on-premises password validation is an explicit organizational requirement.
Found this Article Useful? 😊
If this Article saved you an hour of Troubleshooting, a few minutes of searching, or one Microsoft documentation Rabbit Hole, consider turning some of that saved time into a Coffee. ☕ Your support helps keep new Technical Guides coming.
0 comments