How to Connect On-Premises Active Directory to
Microsoft Entra ID Safely with Hybrid Identity
The word "safely" is doing real work in this brief, because the unsafe version of this project is disturbingly easy to build by accident: sync every OU including Domain Admins, run the sync server with more privilege than it needs, skip the backup authentication path, and cut every domain over to cloud auth in one afternoon with no test group. Each of those choices feels like the fast path. Each is also how a compromised on-premises account becomes a compromised tenant.
Hybrid identity — connecting an on-premises Active Directory to Microsoft Entra ID so users get one identity and one password across both worlds — is one of the highest-leverage, highest-risk projects in a typical Azure adoption. Done well, it's close to invisible to end users and gives IT a single control plane for identity governance. Done carelessly, it becomes the exact bridge an attacker needs: a compromised on-premises Domain Admin account that was never supposed to sync to the cloud, syncing anyway, now sitting in Entra ID with privileges nobody explicitly granted there. This guide is built around the "safely" in the brief specifically — not just how to get directory sync working, but the decisions that determine whether that sync is a controlled, auditable bridge or an unintentional privilege escalation path. That starts with picking the right sync engine for your actual environment, which — as of a real, current deadline covered in Section 2 — is no longer a decision you can defer indefinitely.
Before any security consideration, the foundational choice is which engine actually does the synchronization — and this choice constrains almost everything downstream, including which authentication methods and features are available.
| Aspect | Cloud Sync | Entra Connect Sync |
|---|---|---|
| Recommended for | New deployments, where it meets requirements | Complex scenarios Cloud Sync doesn't yet cover |
| Architecture | Lightweight agents, cloud-managed config, no local database | Dedicated server, local SQL database, self-managed |
| High availability | Multiple agents natively, for redundancy | Requires a separate staging-mode server, managed manually |
| Object scope (current) | Users, groups, and contacts | Full object scope, including devices |
| AD FS federation | Not supported | Supported |
| Pass-Through Authentication | Not supported | Supported |
| Device/group writeback | Not currently supported | Supported |
| Multi-forest with complex trusts | Basic multi-forest support | The more mature, tested option |
| Microsoft Defender for Identity integration | Shallower — fewer deep audit hooks | Native, deep integration |
The practical decision rule current guidance suggests: start with Cloud Sync for a new deployment if you don't need Pass-Through Authentication, AD FS federation, or advanced writeback. If your environment has multiple AD forests with complex trust relationships, existing custom sync rules, or a genuine requirement for PTA, Entra Connect Sync remains the right tool. Don't default to the heavier, self-managed option out of habit or because older tutorials assume it — check the requirement list against Cloud Sync's current capabilities first.
A real, current, actionable fact for anyone already running Entra Connect Sync: all installations must be running version 2.5.79.0 or later by September 30, 2026. This is tied to a Microsoft backend security hardening change — installations left on an older version don't degrade gracefully, they simply stop syncing on that date.
| Detail | Fact |
|---|---|
| Minimum version | 2.5.79.0 or later |
| Deadline | September 30, 2026 |
| Cause | A Microsoft backend security hardening change |
| Effect of missing it | Synchronization stops entirely — not a warning, a hard stop |
| What this is NOT | A retirement of directory synchronization as a capability — it's a mandatory minimum-version requirement specifically |
If you're running Entra Connect Sync today and haven't verified the installed version recently, this is worth checking immediately rather than waiting — an unplanned sync outage discovered on or after September 30, 2026 is a considerably worse position than a scheduled upgrade window well before it. Since this deadline is specifically about the traditional Entra Connect Sync engine, it's also a natural moment to revisit Section 1's decision: is this still the right engine for your environment, or has Cloud Sync's capability grown to cover your actual requirements since you last checked?
Beyond which engine syncs your directory objects, a separate and equally consequential decision is how users actually authenticate to cloud services once synced.
| Method | How it works | Where passwords are validated |
|---|---|---|
| Password Hash Sync (PHS) | A securely processed hash of the on-premises password hash is synced to Entra ID | In the cloud |
| Pass-Through Authentication (PTA) | An on-premises agent validates the password against AD in real time, per sign-in | On-premises, per authentication |
| Federation (AD FS) | Sign-in requests are redirected to on-premises AD FS for validation | On-premises, via a federation service |
Microsoft's own guidance describes PHS as generally simpler to implement than a federation service, with no additional on-premises infrastructure required to validate sign-ins — the trade-off is that authentication depends on cloud availability rather than on-premises availability, which for most organizations is the more resilient direction to depend on, not less.
A password change while a user is actively signed in doesn't affect their current session — but the next authentication requires the new credentials, and without additional configuration, users may be prompted more often than expected even when nothing changed on their end. Configuring Microsoft Entra join or Microsoft Entra hybrid join (Section 8) automatically signs users in when they're on a corporate, domain-connected device, meaningfully reducing this friction — worth planning alongside the authentication method decision, not as an afterthought.
This is one of the most concrete, actionable "safely" recommendations in hybrid identity design, and it's directly stated in Microsoft's own guidance: if you deploy Pass-Through Authentication or Federation as your primary authentication method, also enable Password Hash Sync — specifically as a backup.
- The failure scenario this protects against. If your on-premises authentication infrastructure fails — the PTA agents go down, or AD FS becomes unavailable — users can't authenticate to cloud services at all under PTA or Federation alone, because both methods depend on that on-premises infrastructure being reachable.
- The fix: PHS as a dormant, ready backup. With PHS also enabled (even while PTA or Federation is your primary method), you can manually switch to Password Hash Sync during an on-premises outage, restoring cloud authentication without waiting for on-premises recovery.
- PHS runs continuously, on its own cycle, independent of the primary method. Once enabled, Password Hash Sync operates on its own two-minute cycle regardless of which method is currently the primary — meaning the backup path is already current and ready, not something that needs to be activated and populated during the actual incident.
Without PHS enabled as backup, an on-premises PTA agent or AD FS outage means cloud authentication is fully down for the duration of the on-premises recovery — potentially hours, for a hardware or infrastructure failure. With PHS already running in the background, the same incident becomes a deliberate, manual switch to an already-synchronized authentication path, measured in minutes rather than however long on-premises recovery actually takes. This is a low-cost, high-value resilience measure specifically because PHS's ongoing sync cost is minimal and it requires no incident-time setup.
There's no built-in way to define a specific subset of user passwords you want synchronized within a single connector — it's effectively all-or-nothing per connector. In a multi-forest environment with multiple connectors, you can disable PHS for specific connectors while leaving it enabled for others using the same Set-ADSyncAADPasswordSyncConfiguration cmdlet, if your design genuinely requires that granularity — for instance, deliberately excluding a specific forest's accounts from ever having password hashes leave that forest's boundary.
This is the security principle most likely to be overlooked, and it's the one that actually determines whether "safely" is more than a word in the brief. Whatever runs your directory synchronization — the Entra Connect Sync server, or the machine hosting Cloud Sync agents — has meaningful, sensitive capability: it can read broadly from on-premises AD (including data used in password hash processing, if PHS is enabled) and write into your Entra ID tenant.
| Protection | Why it matters |
|---|---|
| Treat the host OS with domain-controller-equivalent rigor | Compromise of this machine can mean compromise of directory sync integrity and, in PHS scenarios, exposure to password-hash-adjacent processing |
| Least-privilege service account, not a broad admin role | The sync service needs specific, scoped directory permissions — not Global Administrator or unrestricted Domain Admin rights |
| Restrict interactive logon to the sync server | Minimize who can log onto this machine directly, the same discipline applied to domain controllers |
| Patch and monitor as rigorously as a domain controller | This is not a general-purpose application server — its blast radius on compromise is directory-wide |
| Only one active (non-staging) sync server at a time | Multiple simultaneous active sync servers can produce conflicting writes and sync instability — a documented operational requirement, not just a preference |
The sync server or agent host is, functionally, a trust bridge between on-premises Active Directory and Microsoft Entra ID — two systems most organizations already protect as their most sensitive infrastructure individually. A machine that has meaningful read access into one and write access into the other deserves at least the same protection as either endpoint alone, not less because it's "just a sync tool." Standard AD tiering models place this class of asset at Tier 0, alongside domain controllers and PKI infrastructure — apply that classification here explicitly rather than treating it as a lower-tier application server by default.
Both sync engines let you control which objects and OUs actually get synchronized to Entra ID, using OU-level and domain-level filtering. Getting this scope right is a core "safely" decision — the default of syncing everything is rarely the correct answer.
| What to exclude from sync scope | Why |
|---|---|
| On-premises privileged/Tier 0 accounts (Domain Admins, Enterprise Admins, Schema Admins) | These accounts don't need cloud presence for their on-premises administrative function, and syncing them creates an unnecessary path from on-prem compromise to cloud-visible privileged accounts |
| Service accounts with no legitimate cloud use case | Reduces the sync scope's overall attack surface and keeps the tenant's object count focused on accounts that actually need cloud access |
| Legacy or disabled accounts not actively cleaned up on-premises | Stale accounts synced to the cloud extend an on-premises hygiene problem into the tenant rather than resolving it |
| Test/lab OUs not intended for production cloud access | Keeps the synchronized directory representing genuine production identity, not incidental sprawl |
An on-premises Domain Admin account that syncs to Entra ID exists in both worlds simultaneously — and if that on-premises account is ever compromised (a genuinely common outcome given how frequently on-premises AD environments are targeted), the compromise can extend directly into whatever cloud presence and permissions that synced identity carries in Entra ID. The mitigation is straightforward and should be treated as a default, not an advanced hardening step: scope sync filtering to explicitly exclude privileged administrative accounts and OUs from the start, and manage cloud administrative access through separate, cloud-native privileged accounts instead.
For environments where privileged status isn't cleanly captured by OU structure alone, group-based filtering — syncing based on membership in specific security groups rather than OU location — is often more maintainable, since it can reflect actual role/privilege status directly rather than relying on OU placement staying consistent over time. Either approach is valid; the important part is that the scoping decision is deliberate and documented, not left at whatever the default wizard configuration produced.
Staged Rollout is a specific, documented feature that lets you test cloud authentication features — Microsoft Entra multifactor authentication, Conditional Access, Identity Protection, and Identity Governance — with a selected subset of users before switching your entire domain to cloud authentication.
- What it solves. A domain-wide cutover to cloud authentication, done all at once, means any misconfiguration or unexpected interaction with an existing policy affects every user simultaneously. Staged Rollout confines that blast radius to a deliberately chosen test group first.
- How it works. Specific users or groups are enabled for staged rollout of a given cloud authentication feature, letting you validate sign-in behavior, MFA prompts, and Conditional Access policy interactions against real accounts before the broader domain switch.
- What it doesn't replace. Staged Rollout is a testing mechanism for the cutover, not a permanent operating mode — the goal is validating the full-domain switch, not running two authentication configurations indefinitely.
Conditional Access policies can behave in subtle, unexpected ways when combined with a new authentication method for the first time — a policy that worked correctly against federated sign-ins might interact differently once PHS or a new Cloud Sync configuration is live. Staged Rollout's test group is exactly the mechanism to catch this class of surprise against a small, controlled set of real accounts, rather than discovering the interaction the moment the entire domain switches over.
Two features that materially improve the end-user experience of hybrid identity, and are worth planning alongside the core sync and authentication decisions rather than as later add-ons.
| Feature | What it does |
|---|---|
| Seamless Single Sign-On (SSO) | Automatically signs users in when they're on a corporate, domain-joined device connected to the corporate network — no password prompt for cloud resources in that context |
| Microsoft Entra hybrid join | Registers on-premises domain-joined devices as known, trusted devices in Entra ID, enabling device-based Conditional Access policies and reducing prompts further |
| Keep Me Signed In (KMSI) | An admin-configurable session cookie option, valid up to 180 days, that reduces repeated sign-in prompts outside the corporate network context |
Once devices are hybrid-joined, Conditional Access policies can require a known, compliant device as a sign-in condition — a materially stronger security posture than password-only or even password-plus-MFA alone, since it adds "is this a device we actually trust" to the evaluation. Planning hybrid join alongside the initial hybrid identity rollout, rather than retrofitting it later, means Conditional Access policies can be designed around device trust from the start instead of being redesigned once device state becomes available.
Choose your sync engine deliberately — default to Cloud Sync unless a specific requirement rules it out
Check your actual requirements (PTA, AD FS federation, device/group writeback, complex multi-forest trusts) against Section 1's comparison before defaulting to the heavier, self-managed Entra Connect Sync out of habit.
If using Entra Connect Sync, confirm you're on version 2.5.79.0 or later now
Don't wait for the September 30, 2026 deadline — verify the current version and plan the upgrade well ahead of a hard synchronization stop.
Design your OU/group filtering scope before the first sync, explicitly excluding privileged accounts
Document which OUs or groups are in scope and which are deliberately excluded — Domain Admins, Enterprise Admins, service accounts with no cloud need, and any Tier 0 administrative accounts.
Provision and harden the sync server or agent host as a Tier 0 asset from day one
Apply domain-controller-equivalent hardening: restricted interactive logon, least-privilege service account, rigorous patching, and monitoring — before the first object syncs, not retroactively.
Choose your primary authentication method, and enable PHS as a backup regardless
Whether PHS, PTA, or Federation is primary, enable Password Hash Sync as a parallel, continuously-updated backup authentication path per Section 4 — this is a low-cost, high-value resilience measure worth including by default.
Run the initial synchronization and verify object counts and scope match your design
Confirm the synced object count and the specific accounts present in Entra ID match your intended scope — this is the moment to catch an over-broad sync before it's been live for months.
Use Staged Rollout to test cloud authentication features against a small group first
Validate MFA, Conditional Access, Identity Protection, and Identity Governance behavior against real accounts in the test group before the full-domain cutover to cloud authentication.
Configure Seamless SSO and Microsoft Entra hybrid join alongside the rollout
Plan device trust and reduced-prompt sign-in experience as part of the initial deployment, so Conditional Access policies can be designed around device trust from the outset.
Cut the full domain over to cloud authentication only after the staged rollout group is clean
Confirm no unexpected issues surfaced in the test group across a reasonable observation period before expanding to the full domain — resist the urge to compress this validation window under deployment-timeline pressure.
Document the failover procedure to PHS explicitly, and rehearse it once
If PTA or Federation is primary, make sure the manual switch to PHS during an on-premises outage is a documented, tested runbook step — not a capability that exists in theory but has never actually been exercised by the team who'd need to use it during a real incident.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Syncing every OU by default, including privileged/Tier 0 accounts | "Simplest to just sync everything" | Creates a direct path from on-premises credential compromise to a privileged, cloud-visible identity — scope this deliberately from day one |
| Running the sync server without domain-controller-equivalent hardening | "It's just a sync tool, not a DC" | It has meaningful read access to on-prem AD and write access to Entra ID — functionally a Tier 0 asset regardless of how it's labeled |
| Skipping PHS entirely because PTA or Federation is the primary method | "We already have a primary authentication method" | Leaves cloud authentication fully dependent on on-premises infrastructure availability, with no fast manual failover if that infrastructure goes down |
| Cutting the entire domain to cloud authentication in one step, no test group | "Faster to just do it all at once" | Any misconfiguration or unexpected policy interaction affects every user simultaneously — Staged Rollout exists specifically to avoid this |
| Ignoring the Entra Connect Sync version until close to the September 2026 deadline | "We'll handle it when it becomes urgent" | An unplanned sync stoppage discovered at the deadline is a considerably worse position than a scheduled upgrade well ahead of it |
| Defaulting to Entra Connect Sync for a new deployment "because that's the established tool" | "It's the mature, well-documented option" | Cloud Sync is now Microsoft's preferred path for new deployments where it meets requirements — check the actual requirement list before defaulting to the heavier option |
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- Purging the Keys: Migrating Azure OpenAI Applications to Managed Identities and RBAC
- Azure Site-to-Site VPN Prerequisites: Network Planning, Gateway Requirements, IPsec, and Routing
- How to Design Azure Landing Zones: The Enterprise Architecture Blueprint
- Enterprise Network Segmentation in Azure: Architecture Patterns That Actually Scale