5.2 PHS, PTA & Seamless SSO

Cloud authentication versus federation

Synchronizing objects into Microsoft Entra ID does not by itself decide where the password is checked. Hybrid sign-in methods fall into two families:

1. Cloud authentication — Microsoft Entra ID is the primary STS for password validation paths using password hash synchronization (PHS) and/or pass-through authentication (PTA), optionally with seamless single sign-on (seamless SSO).
2. Federated authentication — Microsoft Entra ID redirects password-based auth for a domain to an external STS such as Active Directory Federation Services (AD FS) (or another supported IdP).

SC-300 modernization scenarios almost always prefer cloud authentication unless the stem requires federation-specific claims, certificate authentication patterns tied to AD FS, or a third-party IdP that remains authoritative.

Password hash synchronization (PHS)

Password hash synchronization is a feature of hybrid identity (commonly enabled with Microsoft Entra Connect Sync, and available in supported Cloud Sync scenarios per current Microsoft capability) that periodically synchronizes a hash of the hash of the user’s AD password to Microsoft Entra ID.

Important conceptual points for the exam:

• Microsoft Entra ID does not receive the clear-text password.
• Users can authenticate to cloud apps with the same password they use on-premises.
• If the on-premises directory or VPN path is down, users can often still sign in to cloud apps with PHS because validation happens in Entra ID (subject to overall service health and user state).
• PHS also powers leaked credential detection / identity protection signals that compare known leaked credentials against the synced hash material—frequently cited as a security reason to enable PHS even when PTA or federation is primary.
• Password changes on-premises synchronize on the PHS cycle (near real time for many environments, not always instant for every edge case).

When PHS is the best answer:

• Cloud authentication modernization with simplest operations.
• Desire for cloud sign-in resilience if on-premises sites fail.
• Combine with seamless SSO for domain-joined UX.
• Enable as backup even when PTA or federation is primary (common Microsoft recommendation pattern: PHS as safety net).

Exam traps about PHS:

• PHS is not reversible encryption of the password sitting in a spreadsheet.
• PHS is not the same as PTA (no live AD check on each cloud sign-in).
• Enabling PHS does not automatically migrate every federated domain; domain sign-in method conversion is a deliberate step.

Pass-through authentication (PTA)

Pass-through authentication validates the user’s password against on-premises Active Directory at sign-in time, without storing a password hash in Microsoft Entra ID for validation.

How it works at a high level:

1. User signs in to a Microsoft Entra–integrated app with UPN and password.
2. Microsoft Entra ID places an authentication request for an on-premises agent to retrieve.
3. A PTA authentication agent on a domain-joined server picks up the request over an outbound connection.
4. The agent validates the credentials against AD (via Windows APIs against domain controllers).
5. Success or failure is returned to Microsoft Entra ID, which completes the cloud sign-in (tokens issued subject to Conditional Access and other controls).

PTA agents and high availability

SC-300 loves the HA question: “Users cannot sign in to Microsoft 365 after a single server reboot.” If the tenant uses PTA with one agent on that server, the fix is install additional PTA agents, not “buy more AD FS proxies.”

When PTA is the best answer

• Security or compliance stakeholders reject cloud validation of password hashes and insist passwords be checked only in on-prem AD.
• On-premises password policies and immediate disablement must be enforced at every cloud sign-in without waiting for hash sync timing edge cases.
• Organization wants cloud auth UX and Conditional Access without a full AD FS farm, but still wants live AD validation.

PTA still requires healthy AD and agents. It is not as resilient to total on-premises outage as PHS for password validation.

Seamless single sign-on (seamless SSO)

Seamless SSO reduces password prompts for users on domain-joined devices that can reach on-premises domain controllers (typically corporate network or connectivity that allows Kerberos to AD).

Mechanism (conceptual):

• During Connect configuration (or related setup), a computer account (commonly AZUREADSSOACC) is created in on-premises AD.
• Browsers/clients that support integrated Windows authentication can obtain a Kerberos ticket for that account.
• Microsoft Entra ID accepts the ticket as proof for the user session in supported flows, so users already logged into Windows often get into Entra apps without retyping the password.

Key clarifications:

Exam stem: “Domain-joined PCs on the corporate network should not prompt for passwords repeatedly when opening Microsoft 365, but remote users on personal devices still authenticate normally.” → enable seamless SSO with cloud auth (PHS or PTA), not “force federation for everyone.”

Also remember browser allowlists / intranet zone configuration historically matters for integrated auth; questions may hint that IT must prepare clients, not only tick a wizard box.

Comparison table: PHS vs PTA vs federation

Exam decision scenarios (cloud auth modernization)

Walk scenario stems with this algorithm:

1. Is federation explicitly required? (third-party IdP, complex claims, certificate auth via AD FS only, app that cannot use Entra directly) → federation remains.
2. Must passwords never be validated from cloud hash material? → PTA (+ consider PHS as backup if policy allows).
3. Otherwise for hybrid password users → PHS as primary cloud authentication.
4. Domain-joined corporate UX without password prompts → add seamless SSO.
5. Resilience / Identity Protection → enable PHS even if PTA or federation is primary, when the question allows dual configuration.
6. Simplify and decommission AD FS → migrate domains to managed cloud auth (PHS/PTA), staged rollout (next section).

Worked examples:

Scenario A: Contoso has AD FS, frequent certificate outages, and wants Microsoft 365 sign-in to keep working during AD FS maintenance windows. → Move to PHS (cloud auth); use staged rollout; keep monitoring via Connect Health during transition.

Scenario B: Fabrikam policy forbids storing password validation material in the cloud and requires instant AD disablement enforcement. → PTA with multiple agents; optionally discuss PHS only if policy later allows backup.

Scenario C: Users hate typing passwords on domain-joined laptops in the office but already use PHS. → Enable seamless SSO, validate browser/device conditions.

Scenario D: All agents were on one VM that failed; cloud password sign-ins broke; hashes were never enabled. → That topology was PTA without HA; install more agents and/or enable PHS for resilience.

PHS + PTA + seamless SSO together

These features are not mutually exclusive in Microsoft’s hybrid model:

• PHS + seamless SSO — common default modernization pair.
• PTA + seamless SSO — live AD validation with better domain-joined UX.
• PHS + PTA — PTA primary validation with PHS as backup / Identity Protection data plane (per supported configuration guidance).
• Federation + PHS — federated sign-in remains, but PHS supports smart lockout/leaked credential scenarios and emergency cutover planning.

Do not confuse seamless SSO with same sign-on (old GUID-based patterns) or with SSO via the My Apps portal bookmarks. Seamless SSO is the Kerberos-to-Entra feature for domain-joined clients.

Common traps

• Choosing AD FS because “we have AD” — AD alone is not federation; Connect + PHS is enough for many tenants.
• Thinking PTA stores passwords in the cloud — it does not; it validates on-premises.
• Thinking PHS sends clear text — it synchronizes hash material derived from the AD password hash.
• Deploying one PTA agent and calling it highly available.
• Expecting seamless SSO to skip MFA when Conditional Access requires MFA.
• Using Azure RBAC roles to “fix” hybrid auth — wrong control plane; this is Entra Connect / authentication method design.

Master the comparison table and the modernization algorithm. Most SC-300 hybrid authentication items are decision questions, not deep protocol traces.