Microsoft Entra Cloud Sync Passwords Not Syncing? How We Fixed a Paused PHS Job
Microsoft 365 & Cloud
Microsoft Entra Cloud Sync healthy but passwords not syncing? Discover how to identify and resume a paused Password Hash Synchronisation job.
By LinkedUp Communications | Technical troubleshooting / Real-world case study
Introduction
A healthy Microsoft Entra Cloud Sync configuration does not necessarily mean passwords are synchronising. In this real-world case, a customer’s users and groups were provisioning correctly, yet Password Hash Synchronisation (PHS) had never completed a cycle. The decisive finding was a paused password synchronisation job, separate from the active provisioning job.
The environment used Windows Server 2022 Active Directory, Microsoft Entra Cloud Sync, Microsoft 365 and a group Managed Service Account (gMSA). This article explains the checks we performed, how Microsoft’s diagnostic tools exposed the job state, and how we verified the recovery without assuming an unproven root cause.
Symptoms: Healthy Cloud Sync but passwords not synchronising
Cloud Sync appeared healthy and successfully synchronised users and groups into Microsoft Entra ID. PHS was enabled, but there was no completed password synchronisation cycle. That distinction mattered: object provisioning demonstrated that part of the service worked, not that password hashes were reaching the tenant.
We used a controlled test account to separate the symptoms. The test user appeared successfully in Microsoft Entra ID, but after an on-premises Active Directory password change, Microsoft 365 initially rejected the new password. This gave us a repeatable test rather than relying solely on an overall health indicator.
Initial troubleshooting
We first verified the provisioning agent and reviewed the Active Directory replication permissions associated with the gMSA. Password hash synchronisation requires the appropriate directory permissions; successful user provisioning alone is not proof that every password-related prerequisite has been satisfied.
We also checked DNS forwarders, resolution of Microsoft endpoints, outbound connectivity over ports 443 and 80, and relevant firewall rules. These were checks against potential environmental obstacles, not evidence that DNS or the firewall had caused the issue. Network requirements should always be assessed against Microsoft’s current Cloud Sync documentation.
The controlled password-change test remained important throughout. It connected the administrative checks to the actual user experience: an account could be provisioned while its latest password was still unavailable for Microsoft 365 sign-in. None of these initial checks conclusively identified why password synchronisation had never run.
The breakthrough: AD2AADPasswordHash job was Paused
The breakthrough came from Microsoft’s Cloud Sync diagnostic module on the provisioning agent server. In Windows PowerShell, we imported the module from its installed utility location:
Next, we connected to the tenant. The address below is an illustrative placeholder, not a customer account. Replace it with an appropriate administrator sign-in for your tenant:
We then checked the synchronisation jobs using this PowerShell command:
The diagnostic output revealed the critical difference: AD2AADProvisioning was Active, while AD2AADPasswordHash was Paused. This explained how object provisioning could continue while password synchronisation had not completed a cycle. The overall configuration’s healthy appearance had not exposed this distinction clearly enough during the initial checks.
How we resumed Password Hash Synchronisation
Before proceeding, we identified the actual paused password job belonging to the affected configuration. Resuming a job is a configuration-changing operation, not a read-only diagnostic check. Administrators should verify the tenant, configuration and complete job ID, and follow their normal change-control process.
We resumed only the paused password synchronisation job using the following command pattern:
The identifier shown here is illustrative. Replace the entire value with the actual job ID returned by your environment; do not copy the bracketed placeholders literally or select the active provisioning job. Where several configurations exist, confirm the intended job before making any change.
Immediately afterwards, the password job initially showed NotRun. We did not treat that transitional status as proof of success or failure. Instead, we allowed time for processing and checked the portal for completed password synchronisation cycles.
Resolving the MSAL.PS ClientId authentication error
A separate diagnostic-tools authentication issue produced this error:
The property ‘ClientId’ cannot be found on this object
Different MSAL.NET assembly versions had been loaded in the PowerShell session. Opening a fresh Windows PowerShell session and importing the diagnostic module resolved the authentication issue. Starting clean avoided reusing the session containing conflicting authentication assemblies.
This was a tooling/session problem encountered during investigation, not evidence that the same error had paused PHS. If you encounter it, distinguish failure to authenticate the diagnostic tools from the underlying synchronisation fault. Avoid loading unrelated authentication modules into the fresh session before retrying the Cloud Sync tools.
Verification and successful testing
Shortly after the password job was resumed, the Microsoft Entra portal displayed successful password synchronisation cycles. The interval shown was five minutes. This was the observed portal interval in this case, not a guarantee that every environment or password change will complete within exactly five minutes.
We then repeated the practical sign-in check. The test user’s new Active Directory password was accepted by Microsoft 365. Successful cycles and the working sign-in together provided stronger confirmation than either the job state or general configuration health alone.
Important considerations
Microsoft Entra Cloud Sync differs from Microsoft Entra Connect Sync. Cloud Sync uses the provisioning agent and cloud-managed configuration; Connect Sync uses a different synchronisation architecture and tooling. Do not run ADSync commands against Cloud Sync or assume Connect Sync troubleshooting steps apply unchanged.
The reason the password synchronisation job originally became paused was not conclusively established. We therefore do not attribute the incident to DNS, firewall configuration or the provisioning agent. Resuming the job restored password synchronisation in this case; it did not establish the original trigger.
Keep an appropriate record of the job state, approved change and verification results. If a job pauses again, investigate the available service diagnostics and configuration history rather than repeatedly resuming it without understanding the circumstances. Protect diagnostic records because they may contain tenant or infrastructure identifiers.
Conclusion
When Microsoft Entra Cloud Sync is healthy but passwords are not synchronising, inspect password synchronisation separately from user and group provisioning. Here, identifying and carefully resuming the paused AD2AADPasswordHash job restored successful cycles and resolved the test user’s Microsoft 365 sign-in problem.
Talk to LinkedUp