Every hybrid tenant has to answer one question early: when a synced user types a password, who checks it? Microsoft Entra ID gives three answers: password hash synchronization (PHS), pass-through authentication (PTA) and federation, usually with AD FS. In this post I'll explain how each works, what it depends on and how it fails, with a decision table and commands to check your tenant.
How each method works#
The real difference is where the password gets checked; it doesn't depend on whether you sync with Connect Sync or Cloud Sync.
Password hash synchronization#
The sync engine reads each in-scope user's NT hash from Active Directory and hardens it before upload: it adds a per-user salt and runs the result through PBKDF2 with HMAC-SHA256 and 1,000 iterations. Only that derived value reaches Microsoft Entra ID, over TLS, and sign-in is then validated entirely in the cloud. Password changes flow roughly every two minutes, independently of the regular sync cycle.
Pass-through authentication#
Lightweight Authentication Agents on domain-joined Windows servers keep outbound connections open to Microsoft Entra ID. At sign-in, Entra ID encrypts the credentials for the agents and queues the request; one agent picks it up, validates it against a domain controller and returns the result. Because Active Directory checks the account every time, disabled or locked-out accounts, expired passwords and logon-hour restrictions take effect immediately.
Federation#
The domain is marked as federated, so once the user enters a UPN with that suffix, Entra ID redirects the browser to your federation service, typically an AD FS farm published through Web Application Proxy (WAP). AD FS authenticates the user, applies its own claim rules and access policies, and returns a token signed with a certificate Entra ID trusts. Entra ID never sees the password.
Dependencies and failure modes#
| Method | On-premises footprint | What stops cloud sign-in | Health view |
|---|---|---|---|
| PHS | The sync server, which isn't in the sign-in path | Nothing on-premises; if sync stops, the last synced password still works | Connect Sync status |
| PTA | Agent servers with outbound HTTPS and line of sight to domain controllers | All agents offline, domain controllers unreachable, or a proxy breaking the agents' TLS | Agent status in the Microsoft Entra admin center |
| Federation | Two or more AD FS and WAP servers, load balancing, public DNS and certificates | Any of those layers, an expired certificate, or unavailable domain controllers | Connect Health for AD FS |
For PTA, Microsoft recommends three agents in total, so one can fail while another is in maintenance. Agents need outbound port 443 (and 80 for revocation lists), aren't supported in a perimeter network and shouldn't sit behind TLS inspection; the limit is 40 per tenant. Protect agent servers like domain controllers.
Watch out: Failover is never automatic. If PTA or AD FS goes down, you can only move users to PHS if hashes were already syncing before the outage; then you change the sign-in method in Entra Connect (PTA) or convert the domain to managed (federation). Microsoft notes that organizations with PHS already enabled restored cloud sign-in after on-premises attacks far faster than those without.
Security differences that matter#
- Leaked credentials. Microsoft Entra ID Protection checks credential pairs found in leaks against your synced hashes, so leaked credentials detection needs PHS whatever your sign-in method. The report and risk-based policies need Microsoft Entra ID P2; see my ID Protection guide.
- Account state lag with PHS. A disabled account reaches Entra ID with the next sync cycle (up to about 30 minutes); locked-out and password-expired states aren't synced at all. For urgent leavers, run a delta sync and revoke sessions with
Revoke-MgUserSignInSession. - Lockout. Smart lockout protects PHS and PTA sign-ins. With PTA, set the Entra lockout threshold lower than AD's and the lockout duration longer than AD's reset counter, so cloud attacks can't lock out AD accounts.
- MFA. With PHS or PTA, MFA happens in Microsoft Entra ID. A third-party MFA product that only integrates with AD FS drops out of the path.
Choosing: a decision table#
| If you need... | Choose | Why |
|---|---|---|
| The simplest, most resilient sign-in | PHS | No on-premises dependency; Microsoft's recommended cloud authentication |
| AD account states and logon hours enforced on every sign-in | PTA, with PHS enabled as a backup if policy allows | Active Directory validates each sign-in |
| sAMAccountName sign-in (DOMAIN\user), a third-party MFA or identity product that requires federation, or multi-site geo-DNS authentication | Federation | Not supported natively by Entra ID |
| Smart card or certificate sign-in | Usually PHS or PTA with Microsoft Entra certificate-based authentication | Certificates no longer force federation |
| Leaked-credential detection and an outage fallback | PHS enabled, whatever the primary method | Both depend on synced hashes |
SSO works with all three. Microsoft Entra joined and hybrid joined Windows devices get it from the Primary Refresh Token; devices that are only domain-joined can use Seamless SSO with PHS or PTA.
Check what your tenant does today#
- In the Microsoft Entra admin center, open Entra ID › Entra Connect › Connect Sync. It shows whether password hash sync is enabled, plus federation, Seamless SSO and pass-through authentication status. The commands below confirm the same from PowerShell.
- If PHS is off and you run PTA or federation, enable it without changing sign-in: in the Entra Connect wizard, choose Customize synchronization options and tick Password hash synchronization on the Optional features page. Users keep signing in as before.
- For PTA, check the agent list and add agents until at least three are active.
# Which domains are federated?
Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified
# On the Entra Connect Sync server: is PHS on?
Import-Module ADSync
Get-ADSyncAADCompanyFeature | Select-Object PasswordHashSyncVerify#
- Domains:
AuthenticationTypeisManagedfor PHS or PTA andFederatedfor AD FS. - PHS: on the Connect server,
Invoke-ADSyncDiagnostics -PasswordSync(moduleADSyncDiagnostics) should report PHS enabled for the tenant and each AD connector; Application log events 656 and 657 show password batches and results. - PTA: every agent shows Active, and a test account disabled in AD is refused at its next cloud sign-in.
- Federation: no open Connect Health alerts, and the token-signing certificate from
Get-AdfsCertificate -CertificateType Token-Signingmatches whatGet-MgDomainFederationConfiguration -DomainId contoso.comshows in Entra ID.
Tips and gotchas#
- Enable PHS even when PTA or federation is primary. If a regulation forbids it, document how you'd restore cloud sign-in during an on-premises outage.
- The sign-in option in the Connect wizard is tenant-wide: a new or replacement sync server must keep the active server's option.
- For PTA through a firewall or proxy, allow
*.msappproxy.netand*.servicebus.windows.netwithout inspection. - Still on AD FS only for Microsoft 365? My guide to moving from AD FS to cloud authentication with staged rollout walks through the cutover.
