PHS, PTA, and federation: Where is the user, and how are they authenticated?

1. Core mechanism

In hybrid identity, the authentication method is a decision independent of the synchronization technology. Microsoft Learn states that sign-in methods apply regardless of whether Entra Connect Sync or Cloud Sync is used, and that the sync technology doesn't change sign-in behavior. For an on-premises-sourced hybrid user, the object originates in AD DS and is synchronized to the cloud; what changes is where the password is validated.

Interfaces and specifications

• PHS is a sign-in method: Entra ID validates against synchronized password-derived data. Both Connect Sync and Cloud Sync support PHS. The detailed derivation and two-minute cycle below are documented for Connect Sync; they are not asserted as Cloud Sync implementation details.
• For the Connect Sync implementation, the PHS chain is documented: the agent requests the unicodePwd value from a DC through the MS-DRSR replication protocol; the DC encrypts the MD4 hash using the MD5 hash of the RPC session key and a salt, then sends it to the agent. The agent expands the 16-byte hash to 64 bytes, adds a 10-byte per-user salt, and produces a 32-byte result with 1,000 iterations of PBKDF2/HMAC-SHA256. The per-user salt and iteration count are appended before the value is sent to Entra ID over TLS.
• For Connect Sync PHS, the AD DS connector account has the documented replication permissions. The original MD4 value and clear-text password are not synchronized to Entra ID; the result of the derivation is. This is a privileged component, not a general user-data reader.
• PTA: During sign-in to Entra ID, the password is verified directly against the on-premises Active Directory. A lightweight agent installed on on-premises servers performs the verification; The agent only opens an outbound connection and communicates with Entra ID using certificate-based authentication.
• Federation: Entra ID delegates validation to a separate trusted authentication system, typically on-premises AD FS. The federation service issues a SAML assertion; Entra ID validates that assertion and then issues its own token. Federation can be chosen for requirements such as a third-party MFA provider that Entra ID doesn't support natively.
• When PTA or federation is the primary method, PHS can be configured separately as a backup. Failover is not automatic: the sign-in method must be changed through a prepared process. The leaked-credentials capability also requires PHS independently of the selected primary method.

The question isn't “where is the password?” but “where does validation happen?”

The key distinction among the three methods is which component validates the credentials. In PHS, that component is Entra ID: the user enters a password in the cloud, and Entra ID compares it with the derived value it stores. In PTA, validation depends on on-premises Active Directory; an agent relays the request and response. In federation, a trusted authentication system such as AD FS validates the user and issues a SAML assertion, which Entra ID validates before issuing its own token.

This distinction affects availability. With PHS, cloud sign-in can continue if on-premises identity components become unavailable, as long as the password hash was synchronized. With PTA and federation, authentication depends on the on-premises path. Microsoft documents PHS as a separately configured backup for PTA and federation; failover isn't automatic. Staged rollout is a separate way to test cloud authentication before migration.

What exactly is synchronized in PHS?

The following parameter chain describes Microsoft Entra Connect Sync. Cloud Sync can also enable PHS, but support for the method does not verify that every implementation detail below is identical.

A common mistake in PHS discussions is to say that “the password goes to the cloud.” The documented flow doesn't support that claim. When the agent decrypts the envelope from a DC, it has the MD4 hash, not the clear-text password; Microsoft states that the agent never has access to the clear-text password. The hash is expanded to 64 bytes, a 10-byte per-user salt is added, and the result is processed with PBKDF2/HMAC-SHA256 for 1,000 iterations.

The 32-byte result, per-user salt, and iteration count are sent to Entra ID over TLS. Microsoft states that the original MD4 hash isn't transmitted and that the derived value can't be used in an on-premises pass-the-hash attack if obtained.

MD5 is another source of confusion. It's used only to protect the on-premises replication exchange between a DC and the agent, not as the password-protection algorithm used for the cloud value.

unicodePwd (MD4)
  -> DC: enveloped with MD5(RPC session key + salt)
  -> Agent: opens the envelope, obtains MD4 (no clear text)
  -> 16 bytes -> 32-character hex -> UTF-16 -> 64 bytes
  -> + 10-byte per-user salt
  -> PBKDF2 / HMAC-SHA256, 1000 iterations -> 32 bytes
  -> 32 bytes + salt + iteration count -> Entra ID over TLS

The price of PTA is a decision path, not a server

PTA is sometimes chosen because “the hash doesn't go to the cloud.” In the PTA validation path, the password is checked against on-premises Active Directory, and Microsoft states that the on-premises password isn't stored in the cloud. That statement doesn't include the derived password hash synchronized if PHS is configured separately. The tradeoff is that every cloud sign-in depends on available on-premises agents; Microsoft recommends agents on multiple servers for high availability.

Another distinguishing feature of PTA is that it enforces on-premises account state at sign-in. If each sign-in must honor whether an account is expired, disabled, locked out, whether its password has expired, or whether logon hours are restricted, validation needs the on-premises path.

PTA works with cloud controls such as Conditional Access and MFA, and it can be combined with seamless SSO. It isn't a “cloudless” model: cloud policy evaluation still happens in Entra ID; only password validation is on-premises.

State and data flow

1. The user goes to a cloud application; The application redirects to Entra ID. Entra ID looks at the sign-in method configured for the user's domain.
2. For the Connect Sync PHS example, Entra ID compares the password-derived value with its stored value; a matching password completes this validation, without requiring a live on-premises DC for the attempt.
3. If PTA is configured, the authentication request is forwarded to the on-premises agent; The agent verifies the password against Active Directory and carries the result back to Entra ID. The agent uses only outbound connections.
4. For the illustrative AD FS path, the farm authenticates the user and signs a SAML assertion. Entra ID validates that assertion; an assertion failure ends authentication before Conditional Access enforcement.
5. After first-factor authentication completes, Entra ID enforces applicable Conditional Access policies. A password or assertion failure is different from a policy block. Meeting these checks continues the token flow; it does not establish authorization to every application resource.

2. Exploitation

Broken trust assumption

The assumption that “PHS sends our password to the cloud, so PTA and federation are automatically more secure”; Accordingly, the belief that the sign-in method alone determines a security level and that the choice of synchronization technology changes the verification behavior.

Technical prerequisites

• The team does not know what the value is transmitted to Entra ID in PHS and whether this value can be used in an on-premises pass-the-hash attack.
• There is no risk in the register that in PTA and federation the authentication path depends on on-premises components and these components become a prerequisite for cloud access.
• It is not included in the privilege inventory that the ADDS Connector account has Replicate Directory Changes and Replicate Directory Changes All permissions and the sync server is therefore a high value target.

Exploitation mechanism

Compare the decision owner and its dependencies, not just the method label. In Connect Sync PHS, Entra ID checks the synchronized derived value while the privileged connector and sync server maintain that data. In the PTA validation path, an on-premises agent checks the password against AD DS; PHS can separately remain enabled in the same environment, so PTA does not prove that no password-derived value exists in the cloud. In the AD FS example, the farm authenticates the user and signs a SAML assertion; Entra ID validates it before issuing its own token. Signing configuration, claim rules, agent health and cloud policy are different control surfaces with different owners.

Sync ID is not a side component

For PHS to work, the ADDS Connector account must have Replicate Directory Changes and Replicate Directory Changes All permissions; Microsoft Learn writes that these permissions are granted by default during installation. This is an authority that can read sensitive replication data from the directory, and the server hosting the identity carrying this authority deserves the same level of protection as domain controllers.

This course does not teach a method for extracting identification material. From a defense perspective, the correct implication is that the sync server and sync ID should be treated as tier 0 entities in terms of access control, admin login, patching, and monitoring; Anyone with administrative access to this component should be counted towards the authentication limit.

A change of method is a transfer of risk

Moving from Federation to cloud authentication or vice versa is risk transfer, not risk reduction. Maintaining on-premises farming is critical in the Federation; In cloud authentication, policy, session and token management on the cloud side comes to the fore. Microsoft states that the method change requires planning, testing, and possible disruption and recommends testing it on selected user groups with a staged rollout.

A frequently overlooked detail in the transition plan is that PHS can be activated as a backup alongside the federation. This backup must be configured prior to failure so that it can be deployed if the primary sign-in method fails; It is not a precaution to be taken hastily during an outage.

3. Defense & Detection

Telemetry scope

• Record the sign-in method chosen for each federated or managed domain and when this method was changed; Method change is an architectural change.
• If PHS is used, keep the permissions of the ADDS Connector account and the administrative access list of the server where this identity is running in your tier 0 inventory.
• If PTA is used, monitor the number of installed agents, the servers they are located on, and their health status; A single agent is a single point of failure.
• For the AD FS example, track token-signing certificate validity, federation trust and claim-rule changes. These affect the signed assertion that Entra ID validates, not an Entra-issued token signed by AD FS.
• If ID Protection's leaked credentials report is expected, let it be written that this report requires password hash sync regardless of which sign-in method is chosen.

Events and relevant fields

• The sudden increase in cloud sign-in failures may be related to the accessibility of the on-premises component in the authentication path in environments using PTA or federation; This alone is not evidence of a credential attack.
• Connect Sync PHS has a documented two-minute synchronization cycle. This is not a guarantee of end-to-end visibility: failures can delay an update, and an existing session may not request a password again.
• If an error occurs during password synchronization, a record will be dropped in the event viewer; The absence of these records is not proof that the synchronization is working correctly.
• Session cookies created with the Keep me signed in option may cause the user not to be asked for a password again, regardless of the authentication method; This does not mean that the verification flow is skipped.

Match deduction drill with method

Exercise outages according to the configured method. PHS can keep validating already synchronized passwords while new password changes wait for synchronization. PTA depends on the agent/AD DS validation path. In the AD FS example, an unavailable farm or invalid signing configuration prevents a usable federation assertion. PHS backup requires prior configuration and a separate method-change decision; it is not an automatic outage response.

Each of these scenarios requires a different recovery path and does not fit into a common runbook. If the drill report does not state which method, which component and for what period of time were tested, the next team will assume an incorrect level of preparation.

Separate sign-in method from synchronization technology

Microsoft Learn clearly writes that hybrid authentication methods are independent of the synchronization technology used and that the choice of technology does not determine sign-in behavior. Despite this, in practice, the two issues are often discussed as one decision and the question "Will the authentication change if we switch to Cloud Sync?" The question remains unclear.

Documenting this distinction facilitates both change management and incident investigation. A disruption in synchronization affects the flow of objects and attributes; Any disruption to the sign-in method will affect verification. Although the two symptoms may seem similar, their root causes and owners are different.

Detection logic · KQL

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| summarize failures = count(), users = dcount(UserPrincipalName) by bin(TimeGenerated, 15m), ResultType
| order by TimeGenerated asc

Query assumptions

• Illustrative query, not executed. The linked SigninLogs schema defines ResultType as a string: "0" denotes success, so the sample compares string values. Validate the actual collected table before use; aggregation alone does not distinguish PHS, PTA, federation or policy failures.
• The query does not distinguish which path the error occurs in, PHS, PTA, or federation; The component where the verification path is interrupted should be read from separate sources.
• On-premises agent and federation farm health records may not be included in this table; Correlation requires separate data source.

False positives

• The increased number of failed sign-ins during a planned maintenance window may be the result of an expected outage, not an attack.
• The number of errors may increase when an application's re-authentication behavior changes; This does not mean that there is a change in the identity infrastructure.
• Negative example: In an environment using PHS, cloud sign-in can continue successfully during an on-premises outage; The fact that the number of successes remains high is not evidence of on-premises health.

Hardening

• Assess each method’s decision owner and dependencies; a method name alone is not a security rating.
• If PHS is used, protect the sync server and sync ID at the domain controller level; Bind admin access to a separate, monitored path.
• If PTA is used, ensure high availability by installing agents on multiple servers and classify the agent servers as privileged infrastructure.
• Test migration from Federation to cloud authentication on limited user groups with staged rollout; Write the return step in your transition plan.
• If the primary method fails, set up and practice the backup configuration that will be activated before the failure.
• In user communication, use a clear explanation of where the verification takes place, instead of technically incorrect statements such as 'your password is being sent to the cloud'.

Read the examples

30 24 0c 03 50 48 53 0c 06 50 42 4b 44 46 32 0c 0b 48 4d 41 43 2d 53 48 41 32 35 36 02 02 03 e8 02 01 0a 02 01 20

Two reality checks

Assumption: Password hash synchronization sends users' passwords to the cloud; That's why pass-through authentication is a safer choice in every environment.

In fact: PHS synchronizes password-derived data, not the clear-text password or the original MD4 value. The parameter chain in this lesson is documented for Connect Sync; Cloud Sync also supports PHS, without this lesson asserting identical internal details. PTA depends on the on-premises validation path and may coexist with separately enabled PHS. Choosing PTA therefore neither proves the absence of cloud password-derived data nor establishes that it is safer in every environment.

Assumption: Switching to Cloud Sync instead of Entra Connect Sync also changes how users are authenticated.

In fact: No. Microsoft Learn writes that hybrid authentication methods are implemented regardless of the synchronization technology used and that the choice of synchronization technology does not determine sign-in behavior. Synchronization manages the flow of objects and attributes; The choice of PHS, PTA or federation is a separate decision that determines where the verification takes place.

Sources

• Microsoft · Implement password hash synchronization with Microsoft Entra Connect Sync
  Detailed description of how password hash synchronization works: unicodePwd request with MS-DRSR, Replicate Directory Changes / Replicate Directory Changes All permissions, MD5+salt envelope, expansion to 64 bytes, 10-byte per-user salt, 1,000 iterations of PBKDF2/HMAC-SHA256, not transmitting the original MD4, two-minute cycle.
• Microsoft · What is password hash synchronization with Microsoft Entra ID?
  Definition of PHS as a sign-in method; ability to configure it as a backup alongside federation; relationship with leaked credential detection.
• Microsoft · Microsoft Entra Connect: Pass-through Authentication
  Validating the password directly against on-premises Active Directory; not storing on-premises passwords in the cloud; lightweight agent that opens only outbound connections; certificate-based agent authentication; high availability with multiple agents; interoperability with Conditional Access and MFA.
• Microsoft · Authentication for Microsoft Entra hybrid identity solutions
  Scope of this article note: sign-in methods being independent of synchronization technology; definitions of cloud authentication and federated authentication; requirement to enforce on-premises account status at each sign-in; ID Protection's password hash sync requirement; transition testing with staged rollout.
• Microsoft · Cloud Sync deep dive
  Optional PHS support; no equivalence claim for internal algorithm
• Microsoft · Hybrid authentication resilience
  Federation assertion validated by Entra
• Microsoft · SigninLogs schema
  ResultType string,0success; query not executed
• Microsoft · Conditional Access overview
  Enforcement after first-factor authentication