Most enterprises have an identity problem they rarely name: their users exist twice. Once in on-premises Active Directory — the decades-old directory that controls office logins, file shares, and that Kerberos festival from earlier on this trail — and once in a cloud identity platform that controls email, collaboration tools, and SaaS apps. Hybrid identity is the machinery that makes those two records behave as one person, and it's the daily reality of identity work in almost every large organisation.
Why two worlds at all?
History, simply. AD arrived circa 2000 and everything in the building grew roots into it. Cloud services arrived later with their own directories. Ripping out AD is a multi-year project most organisations haven't finished (or started), so the pragmatic architecture is a bridge: keep AD as the master, synchronise identities upward to the cloud, and let users hold one username and password for both worlds.
The bridge: a synchronisation engine
A connector service (in the Microsoft world, historically Entra Connect) runs on-premises and copies identity objects — users, groups, attributes — from AD to the cloud directory on a cycle, typically every half hour. Three details carry most of the operational weight:
- Source of authority. Synced objects are owned by AD: edit the user on-premises and the change flows up; try editing the synced copy in the cloud and you're mostly blocked. This single concept explains the most common hybrid confusion — "why can't I change this attribute in the portal?" Because the portal isn't the master; the answer lives downstairs in AD.
- How passwords work across the bridge. The mainstream option, password hash synchronisation, syncs a derived hash of the password hash (never the password) so the cloud can verify logins independently — meaning cloud access survives even if the on-premises world is down. The alternative, federation, keeps all verification on-premises: the cloud redirects logins back to your own servers. More control, more infrastructure, and a hard dependency — if your federation servers die, cloud sign-in dies with them. The industry has drifted decisively toward the simpler option.
- Sync scope. You choose which organisational units flow upward — and forgetting to include (or exclude) one is the classic cause of "user exists but has no mailbox" and its many cousins.
The security angle that earns the Summit badge: a bridge carries traffic both ways in an attacker's imagination. Compromise on-prem AD and you can often mint your way into the cloud (synced accounts, stolen sync-service credentials); several major real-world intrusions pivoted exactly this way. Mature designs therefore treat the sync server as tier-zero infrastructure — domain-controller-grade protection — and keep a handful of cloud-only break-glass admin accounts that no on-premises compromise can touch.
Where this is all heading: most organisations are slowly inverting the arrow — new apps bind to cloud identity, devices join the cloud directly, and AD's kingdom shrinks toward legacy systems. "Hybrid" is officially a transition state. It has also been one for fifteen years, which is why understanding the bridge — source of authority, sync cycles, and the tier-zero risk — remains one of the most employable pieces of knowledge in infrastructure.