Entra Connect Password Hash Sync Not Working: A Read-First Heartbeat, Event 611, and Per-User Triage

A user changed their password on-premises at 9:00. At 9:40, Outlook on the web still only accepts the old one. Connect Health has raised Password Hash Synchronization heartbeat was skipped in last 120 minutes, and the Application log on the sync server shows Event 611 from Directory Synchronization. Someone in the ticket has already found the "trigger a full sync of all passwords" script and wants to run it "just to be safe."

Don't run anything that changes state yet. A password change made in Active Directory only works for a cloud sign-in when the whole chain holds: password hash sync is enabled for the tenant and for that AD connector → the server you're looking at isn't in staging mode → each forest's password sync channel is alive (heartbeats are logged) → the AD DS connector account can replicate password hashes from a reachable domain controller in every domain → the user is an in-scope user object that's joined to an exported Entra object by a sync rule with password sync turned on → the password isn't a "temporary" one the client skips → the sign-in actually uses the synced hash (managed domain, not federation or pass-through). The event IDs and the per-user password sync log tell you which link failed.

If the problem is object-level export errors (duplicate UPNs, InvalidSoftMatch, permission-issue 8344) rather than passwords, start with the Entra Connect sync errors triage. If Connect-MgGraph refuses the read-only queries below, the Connect-MgGraph "Insufficient privileges" walkthrough covers scopes and roles. This post covers password hash synchronization in Microsoft Entra Connect Sync (the on-premises sync engine). Microsoft Entra Cloud Sync has its own agent and its own troubleshooting docs.

TL;DR

• Decide first: all users or one user? Microsoft's troubleshooting splits along exactly that line, and the reads are different.
• Password hash sync runs every 2 minutes and you can't change that. When nothing is pending, each AD connector logs a heartbeat, Event 654, every 30 minutes. No 654 in the last few hours means the channel is down, not "nobody changed a password."
• A server in staging mode syncs no passwords. Check which server is active before you read anything else.
• Event 611 with RPC error 8453 ("Replication access was denied") = the AD DS connector account is missing Replicating Directory Changes and/or Replicating Directory Changes All at a domain root. RPC 1722 = it can't reach the domain controller over RPC.
• One user only: read that object's password sync log (kept 7 days). FilteredByTarget = "User must change password at next logon" is set, so the temporary password wasn't synced. TargetNotExportedToDirectory = the cloud object isn't exported yet.
• "Synced" doesn't mean "used." A federated domain authenticates at the federation service, and pass-through authentication doesn't automatically fail over to the synced hash.
• The full password sync script is a "run once" tool. Microsoft says if you need it more than once, something else is wrong.

Where in the chain did it break?

Write down the user's DN, UPN, the time of the password change, and which Entra Connect server is active before you change anything.

Step 1: All users or one user, and how does the domain sign in?

Then read how the domain authenticates, because a hash can sync perfectly and still never be used. Read-only Microsoft Graph PowerShell:

Connect-MgGraph -Scopes 'Domain.Read.All'
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified   # Managed or Federated

The tenant-level switches are on onPremisesDirectorySynchronization in Microsoft Graph. Microsoft documents OnPremDirectorySynchronization.Read.All for this read, with Global Administrator as the supported role:

Connect-MgGraph -Scopes 'OnPremDirectorySynchronization.Read.All'
(Get-MgDirectoryOnPremiseSynchronization).Features |
  Select-Object PasswordSyncEnabled, UserForcePasswordChangeOnLogonEnabled, CloudPasswordPolicyForPasswordSyncedUsersEnabled

PasswordSyncEnabled is the tenant side. The next step reads the server side. Both have to agree.

Step 2: Feature, server, and per-connector channel

Read-only, on the Entra Connect server (elevated PowerShell). This is a shortened version of Microsoft's "Get the status of password sync settings" script:

Import-Module ADSync

# Tenant feature as the sync engine sees it, and whether this server is allowed to sync at all
"PasswordHashSync feature in tenant : $((Get-ADSyncAADCompanyFeature).PasswordHashSync)"
"This server in staging mode        : $((Get-ADSyncScheduler).StagingModeEnabled)"   # True = no passwords sync from here

# One password sync channel per on-premises AD connector (forest)
$adConnectors = Get-ADSyncConnector | Where-Object { $_.ConnectorTypeName -eq 'AD' }
foreach ($c in $adConnectors) {
  "`n=== AD connector: $($c.Name) ==="
  Get-ADSyncAADPasswordSyncConfiguration -SourceConnector $c.Name

  # Heartbeat = Event 654, logged with the connector's identifier in the message
  $id   = $c.Identifier.ToString('D')
  $beat = Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Directory Synchronization'
                                            Id = 654; StartTime = (Get-Date).AddHours(-3) } -ErrorAction SilentlyContinue |
          Where-Object { $_.Message -match [regex]::Escape($id) } | Select-Object -First 1
  if ($beat) { "Latest heartbeat (654): $($beat.TimeCreated)" } else { 'No heartbeat (654) in the last 3 hours' }
}

How to read it:

Microsoft's wizard has the same checks built in: Entra Connect wizard > Additional tasks > Troubleshoot > Launch, then Troubleshoot password hash synchronization > Password hash synchronization does not work at all. It validates the tenant feature, staging mode, each connector's channel and heartbeat, DC reachability, and the AD DS account's username, password, and permissions. Read its prompts. Some menus in that console can apply fixes, so don't accept a change until you've finished Step 4.

Step 3: Read the Directory Synchronization events

Microsoft's manual steps say events 0, 611, 652, and 655 from source Directory Synchronization indicate a connectivity problem, and the message names the forest or domain involved. Read the last day (read-only):

$ids = 0, 603, 604, 607, 611, 612, 613, 616, 621, 652, 655, 662, 664, 667
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'Directory Synchronization'
                                  Id = $ids; StartTime = (Get-Date).AddHours(-24) } -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, LevelDisplayName,
    @{n = 'Message'; e = { ($_.Message -split "`r?`n" | Select-Object -First 3) -join ' ' }} |
  Format-Table -Wrap

Microsoft's event table for password hash sync, the IDs that matter most when it's broken:

Microsoft also suggests making the Application log bigger, because PHS logs a lot and older events get overwritten.

Inside an Event 611, the RPC error number tells you the cause. From Microsoft's 611 and RPC-error troubleshooting articles:

FIPS. Microsoft documents that MD5 is disabled on servers locked down to FIPS, and PHS needs it to decrypt the hash envelope from the DC. Microsoft's fix is an enforceFIPSPolicy enabled="false" entry in miiserver.exe.config, with a known-issue warning about editing that file on some Connect versions. Reading Event 667 as the FIPS symptom is our interpretation of the event name, so confirm the server's FIPS policy before you edit anything.

Step 4: AD DS connector account permissions and DC reachability

Find the account first. Synchronization Service Manager > Connectors > your AD connector > Properties > Connect to Active Directory Forest shows the username and its domain. (Get-ADSyncADConnectorAccount from the ADSyncConfig module returns the same thing.)

Microsoft's requirement: that account needs Replicating Directory Changes and Replicating Directory Changes All at the root of every domain in the forest. Express setup grants them automatically. Custom installs, rebuilt accounts, and "we tightened AD permissions" projects are where they go missing.

Microsoft's read-only viewer (from the ADSyncConfig module that ships with Entra Connect):

Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1'
Get-ADSyncADConnectorAccount
Show-ADSyncADObjectPermissions -ADobjectDN 'DC=contoso,DC=com'   # repeat for each domain root

A narrower read with the ActiveDirectory module. It looks only for the two extended rights by their schema GUIDs:

Import-Module ActiveDirectory
$acct = 'MSOL_1a2b3c4d5e6f'                   # the account from Connect to Active Directory Forest
$root = (Get-ADDomain).DistinguishedName      # run against each domain in the forest
$need = @{
  '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2' = 'Replicating Directory Changes'
  '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2' = 'Replicating Directory Changes All'
}
(Get-Acl -Path "AD:\$root").Access |
  Where-Object { $_.IdentityReference -like "*\$acct" -and $need.ContainsKey($_.ObjectType.ToString()) } |
  Select-Object @{n = 'Right'; e = { $need[$_.ObjectType.ToString()] }}, AccessControlType, IdentityReference, IsInherited

Reachability. If the Connect server can't reach every domain controller, Microsoft's manual steps say to configure Only use preferred domain controllers on the AD connector (Configure Directory Partitions). The same list is used for password sync, import, and export, and the ADSync service needs a restart to apply it. Event 616 points at a failing preferred DC.

Step 5: One user. Follow the object and read its password sync log

The quickest route is Microsoft's wizard: Troubleshoot > Troubleshoot password hash synchronization > Password isn't synchronized for a specific user account. It checks the object in the AD connector space, the metaverse, and the Entra connector space, confirms a sync rule with password sync enabled applies, and shows the last sync attempt. The same diagnostic from PowerShell:

Import-Module ADSyncDiagnostics
Invoke-ADSyncDiagnostics -PasswordSync -ADConnectorName 'contoso.com' -DistinguishedName 'CN=Bob Taylor,OU=Staff,DC=contoso,DC=com'

To read the raw log yourself (read-only):

Import-Module ADSync
$cs = Get-ADSyncCSObject -ConnectorName 'contoso.com' -DistinguishedName 'CN=Bob Taylor,OU=Staff,DC=contoso,DC=com'
$cs | Format-List                      # no object = not in the AD connector space (filtering / scope)

# Connector space object log = the password sync history for this object (kept 7 days by default)
Get-ADSyncCSObjectLog -Identifier $cs.ObjectId -Count 10 | Format-List

In the UI it's the same data: Connectors > [AD connector] > Search Connector Space (scope DN or Anchor) > Properties > Log. Microsoft's status values:

If the log is fine but you're not sure the object is wired correctly, Microsoft's manual check on the same Properties dialog:

• Lineage tab: at least one rule in the PasswordSync column is True (default: In from AD - User AccountEnabled).
• Metaverse Object Properties: no cloudFiltered attribute, and domainFQDN / domainNetBios have the values you expect.
• Connectors tab: the object has connectors to both AD and Entra ID. The Entra row's Lineage shows an outbound rule with PasswordSync True (default: Out to Microsoft Entra ID - User Join).

Two scope facts from Microsoft that explain a lot of "just this one user" tickets: password sync is supported only for the user object type, not iNetOrgPerson, and you can't pick a subset of users for PHS. The only scoping is per connector.

Step 6: The password itself (temporary, expired, or overwritten)

Read the AD side and the Entra side of the same user side by side (read-only):

# On-premises (RSAT ActiveDirectory)
Get-ADUser -Identity 'bob' -Properties pwdLastSet, PasswordLastSet, PasswordExpired, PasswordNeverExpires, AccountExpirationDate |
  Select-Object SamAccountName, ObjectClass, Enabled, PasswordLastSet,       # PasswordLastSet is local time
    @{n = 'MustChangeAtNextLogon'; e = { $_.pwdLastSet -eq 0 }}, PasswordExpired, AccountExpirationDate

# Entra (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -UserId '[email protected]' -Property userPrincipalName, onPremisesSyncEnabled, onPremisesLastSyncDateTime, lastPasswordChangeDateTime, passwordPolicies |
  Select-Object UserPrincipalName, OnPremisesSyncEnabled, OnPremisesLastSyncDateTime, LastPasswordChangeDateTime, PasswordPolicies   # UTC

Before you turn on ForcePasswordChangeOnLogon: Microsoft cautions to use it only when Self-Service Password Reset and password writeback are enabled, so a password the user sets in the cloud flows back to AD.

Step 7: Synced, but the sign-in still fails or still takes the old password

If the log says Success and the timestamps line up, read the sign-in instead of the sync. Read-only (or use Sign-in logs in the Entra admin center). Microsoft says the sign-in log API needs a Microsoft Entra ID P1 or P2 license in the tenant, plus AuditLog.Read.All:

Connect-MgGraph -Scopes 'AuditLog.Read.All'
$since = (Get-Date).ToUniversalTime().AddHours(-24).ToString('yyyy-MM-ddTHH:mm:ssZ')
Get-MgAuditLogSignIn -Filter "userPrincipalName eq '[email protected]' and createdDateTime ge $since" -All |
  Sort-Object CreatedDateTime -Descending |
  Select-Object CreatedDateTime, AppDisplayName, ClientAppUsed,
    @{n = 'ErrorCode'; e = { $_.Status.ErrorCode }}, @{n = 'Reason'; e = { $_.Status.FailureReason }}

And the session side. Microsoft says a synced password change doesn't affect a session that's already signed in. The user is asked for the new password when the service next requires authentication, and Keep me signed in can stretch that out. A device still using a cached session isn't proof that sync failed. The Outlook keeps asking for my password card covers the client side.

Timing: when "still broken" is just waiting

A brand-new AD user needs two things in order: the object exported by the regular sync cycle, then the hash. Until the export happens, the log shows TargetNotExportedToDirectory.

When a change is justified

FAQ

Why is password hash sync not working in Entra Connect?
Most cases fall into one of four buckets: the server is in staging mode or the feature/channel is off, the per-forest channel stopped (no Event 654 heartbeat), the AD DS connector account can't replicate hashes (Event 611 with RPC 8453 or 1722), or a single user is out of scope, unexported, or has a temporary password. Run the wizard's Troubleshoot password hash synchronization task first. It checks most of these in one go.

What does "Password Hash Synchronization heartbeat was skipped in last 120 minutes" mean?
It's a Microsoft Entra Connect Health alert. Microsoft's description is that PHS hasn't connected with Entra ID in the last 120 minutes, so passwords won't sync. Read the Directory Synchronization events (611, 652, 655) and the per-connector heartbeat before you take Microsoft's documented remediation, restarting the Microsoft Entra ID Sync service, at a time when no sync cycle is running.

How do I fix Event 611 "Replication access was denied"?
RPC error 8453 inside Event 611 means the AD DS connector account is missing Replicating Directory Changes and/or Replicating Directory Changes All at the domain root. Confirm the account and read the domain root's permissions. Then grant exactly those two rights with Set-ADSyncPasswordHashSyncPermissions or the Entra Connect troubleshooter, on every domain in the forest.

How often does password hash sync run?
Every 2 minutes, and Microsoft says the interval can't be changed. That's separate from the 30-minute directory sync scheduler. A new user needs the scheduler to export the object before the hash can land. When nothing is pending, each AD connector logs a heartbeat (Event 654) every 30 minutes.

Why can a user still sign in with an expired AD password?
By default, a synced user's cloud password is set to never expire. Entra Connect writes DisablePasswordExpiration to the user's passwordPolicies when it syncs the hash. The cloud password only changes the next time the password changes on-premises. To enforce cloud expiration for synced users, Microsoft documents the CloudPasswordPolicyForPasswordSyncedUsersEnabled feature, ideally enabled before PHS is turned on.

Related posts

• Entra Connect Sync Errors Detected: A Read-First Duplicate Attribute, Soft Match, and 8344 Permission Triage (when the object never exports, so its hash has nowhere to land)
• A Tier-1 helpdesk card for "Outlook keeps asking for my password" (the client side of a password change)
• Connect-MgGraph "Insufficient privileges to complete the operation": scopes, roles, consent, and app-only
• Entra ID Break-Glass Accounts: Best Practices After Mandatory MFA (why emergency admin accounts stay cloud-only and don't depend on sync)

Free checklist

Password hash sync is more than a sign-in method. Microsoft's leaked credentials risk detection in Identity Protection needs PHS for on-premises passwords, and that detection is one of the signals risk-based Conditional Access acts on. If you're heading toward enforcing Conditional Access, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-connect-password-hash-sync-not-working

If you want the rest of the identity and Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=entra-connect-password-hash-sync-not-working

Admin Pack Studio; not affiliated with Microsoft. Steps 1–7 only read (the Graph calls are GET-only; the ADSync, ADSyncConfig, and AD cmdlets shown are Get-/Show- reads and the Microsoft diagnostics) until you deliberately change connector permissions, sync features, service state, or a user's password. Fix the channel before you touch individual users, run a full password sync at most once, and check current Microsoft docs for feature names and defaults.