Hybrid identity failure modes nobody tests for

Hybrid identity is tested at deployment against a handful of pilot accounts, all of which are ordinary, current and correctly formed. It then runs for years against a directory full of accounts that are none of those things.

The failures below are the ones I have learned to look for. None of them appear in a pilot, and most produce a symptom that points somewhere other than the cause.

The symptom is almost never “sync is broken”

What gets reported is one of these:

• A new starter cannot sign in to Microsoft 365, but exists in Active Directory.
• A user’s email address changed on premises and did not change in the cloud.
• Someone has two accounts in the cloud, one of which they cannot use.
• Sign-in fails for everyone at a branch office, or for everyone, at a specific moment.
• A leaver was disabled on premises and can still reach their mailbox.

Directory synchronisation touches identity, mail routing, licensing and authentication, so its failures surface as problems in all four. The first diagnostic act is to establish whether the object is synchronising, and separately whether authentication is working. Those are different systems and they fail independently.

Failure one: the source anchor was chosen badly

The source anchor is the immutable value linking an on-premises object to its cloud object. Current Entra Connect deployments use ms-DS-ConsistencyGuid, which is writable and therefore survives the object being deleted and recreated, or moved between forests. Older deployments used objectGUID, which does not.

The failure appears years later, during an Active Directory migration or a forest consolidation. Objects move, their objectGUID changes, and the cloud sees a brand new identity. You get duplicate accounts, or a user whose mailbox is suddenly unreachable.

Check which anchor you are using before any project that moves objects between forests or recreates them. Changing it is possible but it is a deliberate, planned operation, not something to discover mid-migration.

Failure two: an object leaves the sync scope

This is the one that causes real damage, and it is almost always an accident.

Move an organisational unit out of scope, change an attribute filter, or tick the wrong box in the configuration wizard, and every affected object is treated as deleted. The cloud objects go to the recycle bin, where they are recoverable for 30 days — but licences, mailbox access and group membership all break in the meantime.

Entra Connect has a deletion threshold precisely for this, defaulting to 500 objects. An export that would delete more than the threshold is blocked and raises an alert. Two observations:

• Do not disable it because it blocked an export. It blocked the export because something unexpected was happening. Investigate first, then raise it deliberately for a known bulk change and put it back afterwards.
• A threshold of 500 is not protective for a small tenant. If you have 400 users, the default will never trigger while your entire directory is deleted. Set it to something proportionate.

Before any scoping change, run a preview export and read what it intends to do. The configuration wizard’s summary is not the same as the export’s plan.

Failure three: duplicate attributes and the quarantine

Two objects with the same userPrincipalName or the same proxyAddresses value cannot both synchronise. Duplicate attribute resiliency handles this by quarantining the conflicting attribute rather than failing the whole object: the object synchronises with a placeholder value, and the conflicting attribute is held aside.

The consequence is a user who exists in the cloud, can sign in, and does not receive mail — because their proxy address was quarantined. Nobody reports “a quarantined attribute”. They report “email is not working for one person”.

This is what IdFix is for, and it is worth running periodically rather than only before the initial deployment. Duplicates accumulate: shared mailboxes, contacts created for leavers, and accounts created by an application all add addresses that collide.

Failure four: the UPN suffix is not a verified domain

An on-premises user principal name with a suffix that is not a verified domain in the tenant synchronises with the onmicrosoft.com suffix substituted. The user then signs in to Microsoft 365 with a name that does not match the one they use on premises, which is confusing and breaks single sign-on expectations.

This most often hits organisations whose internal Active Directory namespace is a non-routable suffix, or a corp. subdomain they never verified. The fix is to add and verify the domain, then add the correct UPN suffix in Active Directory Domains and Trusts and change the users’ UPNs — which is a change with downstream effects on anything keyed to the UPN, so it is a project rather than a checkbox.

Failure five: Seamless single sign-on’s Kerberos key expires

Seamless SSO works by creating a computer account named AZUREADSSOACC in Active Directory and sharing its Kerberos decryption key with Entra ID. Microsoft’s guidance is to roll that key regularly — every 30 days — and the key does not roll itself.

If the account’s password is changed by a routine process, or the account is moved or deleted by a directory cleanup like the one in retiring stale accounts, seamless sign-on stops for everyone at once. Users are prompted for credentials rather than being signed in silently. It is not an outage, which is why it can persist unnoticed for weeks, but it is a clear regression.

Add AZUREADSSOACC to your exclusion list for any account cleanup, and put the key rollover on a schedule with an owner.

Failure six: authentication method assumptions

The three methods fail differently, and the difference matters for your continuity plan.

Password hash sync keeps a hash of the password hash in Entra ID. Authentication happens entirely in the cloud, so it continues working when your on-premises environment is unreachable. This resilience is the reason I would have it enabled — at minimum as a fallback — even where another method is primary.

Pass-through authentication validates the password against a domain controller through an agent making outbound connections. No inbound firewall rule, but it does mean every authentication depends on your site being reachable and at least one agent being healthy. Deploy more than one agent. A single agent is a single point of failure for all cloud authentication, and it is installed on a server somebody will eventually reboot.

Federation puts AD FS in the path, and adds certificate lifetimes to your list of things that expire. The token-signing certificate rollover is the classic total outage: it happens on a date nobody diarised, and it takes down cloud authentication for everyone simultaneously.

The test nobody runs is the one that matters: disconnect the on-premises environment and see whether cloud sign-in still works. For password hash sync, it does. For the other two, it does not, and your business continuity plan should say so in writing.

Failure seven: the disabled leaver who still has access

Disabling an account on premises synchronises to the cloud and blocks new sign-ins. It does not revoke existing tokens. Refresh tokens remain valid for their lifetime, so a leaver can retain access to a mailbox or files after the account is disabled — for hours.

Where the departure is sensitive, disable the account and revoke the sessions, rather than assuming the first did the second. Sync latency adds to this: a change on premises waits for the next sync cycle, which by default is every 30 minutes for the standard cycle.

The diagnostic sequence I use

1. Does the object exist in the cloud, and when did it last sync? This separates a sync problem from an authentication problem in one step.
2. Is the sync service running and are cycles completing? Check the sync service manager for export errors, not just the last run status. A cycle can complete with per-object errors.
3. Is this object in scope? Organisational unit, attribute filter, and whether it was recently moved.
4. Are there attribute conflicts? Check for quarantined attributes and run IdFix.
5. Which authentication method is in play, and is its dependency healthy? Agents for pass-through, certificates for federation, nothing for password hash sync.
6. Only then look at the user’s own state — licence, mailbox, group membership.

Entra Connect Health is worth having configured before you need it. It reports sync errors, agent health and authentication failures in one place, and it is considerably faster than reconstructing the same picture from event logs during an incident.

What I would put in place now

• A second pass-through authentication agent, or password hash sync enabled as a fallback.
• Password hash sync enabled regardless of primary method, purely for resilience.
• A deletion threshold proportionate to your directory, not the default.
• AZUREADSSOACC on the cleanup exclusion list, with a scheduled key rollover.
• A diarised owner and date for every certificate in the authentication path.
• A periodic IdFix run, not just a pre-deployment one.
• A staging-mode server, so a failed primary is a cutover rather than a rebuild.

Verification and limits

Source anchor behaviour, deletion threshold defaults, duplicate attribute resiliency, seamless SSO key rollover guidance, authentication method characteristics and default sync intervals were checked against current Microsoft documentation on 20 September 2026.

Nothing here was executed against a tenant for this article. Sync scope, source anchor and deletion threshold changes can delete cloud objects at scale — always run a preview export and read its plan before committing a configuration change, and make scoping changes with the recycle bin’s 30-day window in mind rather than relying on it.

References

• Microsoft Entra Connect Sync: understand and customise synchronisation
• Common hybrid scenarios with Microsoft Entra ID
• Microsoft Entra Connect: prevent accidental deletions
• Microsoft Entra Connect: seamless single sign-on