Hybrid Identity: Authentication and Synchronisation in Microsoft Entra ID
Tenth and last in this series on Microsoft Entra ID, covering the operational mechanics of hybrid identity: which authentication method actually validates a sign-in, and how Microsoft Entra Connect keeps on-premises Active Directory and the cloud tenant in sync. The design-level rationale for hybrid identity — why to centralise, why to limit synchronised privilege — is covered in the first post of this series; this one is about the how.
Authentication methods
Three sign-in methods came up for hybrid identity: password hash synchronisation syncs password hashes from on-premises AD to Microsoft Entra ID, so users authenticate in the cloud with the same password as on-premises. Pass-through authentication lets users sign in with the same on-premises password, but the actual authentication happens against on-premises Active Directory itself at sign-in time, with no extra infrastructure like AD FS required. Federation is the optional path requiring an on-premises Active Directory Federation Services server, enabling a fuller hybrid authentication setup.
One correction here: the original note described these three as mutually exclusive. That's not accurate. Only one of pass-through authentication or federation is the primary sign-in method at a time, but password hash synchronisation is commonly deployed alongside either one as a backup — if the PTA agents or the federation server become unavailable, PHS can keep authentication working, though the failover to it isn't automatic; you have to switch the configured sign-on method in Microsoft Entra Connect deliberately when that happens.
Synchronising with Microsoft Entra Connect
Synchronisation is the process of copying users, groups, and other objects from on-premises Active Directory into Microsoft Entra ID. Microsoft Entra Connect is the classic downloadable agent installed on-premises that does this, including syncing password hashes to Entra ID. Microsoft Entra Connect Cloud Sync, by contrast, runs its orchestration in the cloud, with only a lightweight agent bridging on-premises and cloud — and it supports syncing from multiple on-premises AD forests into a single tenant, all orchestrated centrally, which Connect's classic architecture doesn't do as cleanly.
Filtering lets administrators control which objects actually sync — by domain, organisational unit, or user/computer attribute. By default, all users synchronise, which is exactly the gap flagged in the first post of this series: the default filtering only excludes the built-in Administrator account, not Domain Admins or Enterprise Admins, so deliberate filtering matters for anything privileged.
Password write-back enables users to change or reset their password in the cloud, with the change flowing back to on-premises AD — this is the SSPR-enabling feature covered in detail in the SSPR post earlier in this series, named precisely here to avoid the confusion in the original note between write-back and password hash sync. Device write-back does the equivalent for device objects, covered in more detail in the devices and guest users post.
Accidental delete prevention limits how many objects can be deleted in a single synchronisation run before Connect stops and requires confirmation — the default threshold is 500 objects, measured within the scheduler's default 30-minute sync cycle, and it exists specifically to catch mass deletions caused by scripting errors before they propagate to the cloud directory. The threshold is configurable via the Enable-ADSyncExportDeletionThreshold PowerShell cmdlet if 500 turns out to be wrong for your environment's scale.
Gotchas and caveats
The "mutually exclusive" authentication methods claim is the kind of thing that, if taken at face value, would talk someone out of a genuinely recommended resilience pattern — PHS as a backup for PTA or federation. Worth double-checking any hybrid authentication guidance against current Microsoft Learn rather than older training material, since Microsoft's own guidance actively recommends layering PHS in as a fallback rather than treating the three methods as a strict either/or choice.
More generally, across this whole series: a striking number of hybrid and premium features gate on a Microsoft Entra ID P1 or P2 licence — Conditional Access, Access Reviews, administrative unit administration, device write-back, and hardware OATH tokens among them (see the licensing tiers post for the full breakdown). It's worth treating tenant licensing as a first-class design constraint from the start of any hybrid identity project, not something to check at the end.