In a hybrid tenant, Microsoft Entra Connect carries changes from on-premises Active
Directory to the cloud on a 30-minute delta cycle. When it stops, the cloud
silently keeps serving stale data. Nothing errors; things simply stop changing.
What stops flowing
- Password changes. Password hash sync is part of the same engine. A user who
changes their password on-premises finds the cloud still expects the old one.
- Account disables. A leaver disabled in AD keeps working cloud access. This is
the part to state explicitly when you escalate — it is a security exposure, not
just an inconvenience.
- New accounts, group membership changes, and attribute updates.
- Password writeback, so self-service reset stops working in the other direction.
Recognising it from the service desk
The reports arrive as individual credential problems, which is why it is easy to
miss. The pattern:
- Several users, all of whom recently changed their password, all failing in the
cloud with 50126 while their domain sign-in works perfectly.
- Often a shift or a department together, because password expiry is date-driven and
people were provisioned in batches.
- Failures start at a specific time and never stop.
Two simultaneous reports of this shape is enough to check sync health. Do not work
them as three separate tickets.
What to check
- Sync status and last successful sync. A last-success timestamp hours or days
old is the answer.
- The error on the failed runs. Common causes: the AD DS connector (
MSOL_)
service account password expired, the sync service is stopped, a schema or
permissions change, an expired certificate, or the server is simply off.
- Objects pending export. The size of the backlog is the size of the incident.
- On a user, the last directory sync timestamp corroborates it.
This is an incident
Escalate rather than treating symptoms. A good escalation states:
- sync stopped at this time,
- because of this error,
- affecting this many pending objects and these categories of change,
- including disabled accounts that still have cloud access.
The trap
Resetting the cloud password of a synchronised user unblocks that one person — and
creates a divergence between their on-premises and cloud credential. When sync is
restored the on-premises hash wins and the reset stops working. Do that for every
caller and you have hidden a tenant-wide outage behind a growing pile of broken
identities.
Clearing smart lockout is reasonable in the meantime: it removes a second, unrelated
reason the account is failing. It does not fix the password.
Related
- Reading sign-in failure codes (AADSTS)
- Escalating an incident