Site icon Windows Active Directory

How to setup entra connect and cloud sync with the right sync engine

Arun Kumar

Hybrid identity is no longer a “maybe later” project. It is now the default state for most enterprises: on-premises active directory still runs many core workloads, while microsoft entra id is the control plane for modern access, conditional access, and saas. The connector you choose between those worlds determines whether sign-ins are boring (good) or chaotic (bad).

When people say “set up entra connect and cloud sync,” they often mean “get my users from active directory into entra id.” That’s the surface view. The deeper truth is that you are designing a reliable identity supply chain: authoritative sources, transformation rules, conflict boundaries, and operational guardrails. If you design the supply chain well, the tooling becomes easy.

This guide is a comparison-first, deployment-focused reference on microsoft entra connect sync (classic) and microsoft entra connect cloud sync—what they really are, how they behave under stress, and how to implement either without creating a fragile directory.

I’ll link to a couple of authoritative microsoft sources for exact capabilities and setup details, plus a small dose of practitioner reality from forums where migrations succeed and fail in predictable ways.

What these tools actually do (and what they don’t)

Definition for snippet extraction: microsoft entra connect sync and microsoft entra connect cloud sync are hybrid identity synchronization tools that copy and transform selected objects (users, groups, contacts, and certain attributes) from on-premises active directory into microsoft entra id, so cloud services can authenticate and authorize users consistently.

That definition is correct, but incomplete.

The surface understanding (and why it’s incomplete)

Most tutorials frame sync as a one-way pipeline: “install, sign in, select ous, done.” That’s how you get objects into the cloud, but it’s not how you keep an enterprise stable over years of change.

The missing pieces are:

Microsoft has been increasingly explicit that cloud sync is the modern direction for many hybrid scenarios, with cloud-managed configuration and a lightweight agent model. (Microsoft Learn) But “modern direction” is not the same as “feature complete.” The decision hinges on your topology and your edge cases.

Truths of directory synchronization

If you remember nothing else, remember these rules. They explain almost every surprising behavior you’ll see in production.

1) Identity objects need a stable join key

At the cloud boundary, you are not “syncing a user.” You are maintaining a mapping between an on-premises object and a cloud identity. That mapping must be stable across renames, moves, and attribute edits.

In microsoft hybrid identity, the practical join key is typically the on-premises object’s immutable anchor (often derived from objectguid) that becomes the cloud’s source anchor / immutable id in the connector logic. If your join key strategy changes mid-flight, you create duplicates or orphaned cloud users. That’s not a tool bug; that’s broken identity math.

2) You must enforce single-writer ownership per object

A hard boundary: an object should be in scope in only one sync tool at a time. Microsoft calls this out in cloud sync planning and piloting guidance.

Violating single-writer ownership creates “last writer wins” chaos:

This exact class of confusion shows up in real-world threads when admins leave the old connect sync scheduler running while expecting cloud sync to own password hashes. (Reddit)

3) You are building a controlled replication system, not a copy job

Password hash synchronization is a great example. People often think passwords are uploaded. They are not.

With connect sync, the password hash sync process relies on the directory replication protocol (ms-drsr) to request password hashes from a domain controller, and then re-hashes them with additional salting and pbkdf2 before sending to the cloud. The clear-text password never leaves the dc.

If you understand that, you also understand why:

4) Operational architecture beats feature checklists

Classic connect sync is a server application with a local rules engine. Cloud sync is a cloud-managed service with lightweight agents. Those choices change everything:

Cloud sync vs connect sync: a decision model that holds up in real environments

Microsoft now publishes a structured decision guide comparing capabilities and scale limits. It’s worth using as your baseline, then layering your own constraints on top.

When cloud sync is the better default

Cloud sync is compelling when your priority is simpler operations and your requirements are mostly “users/groups/contacts + password hash sync.”

Use cloud sync when you want:

Cloud sync also has clearly stated cadence expectations: password hash sync cycles are on the order of minutes, and object provisioning cycles are typically 10–20 minutes, with real latency depending on change volume.

When connect sync still wins

Connect sync remains the right choice when you need classic hybrid depth:

Cloud sync currently has explicit scale constraints (for example, per-domain object limits and large group membership limits) that can be decisive in big enterprises.

The underrated option: coexistence as a strategy, not a compromise

A mature pattern is to let cloud sync handle the “80% standard identity flow” while connect sync remains for the “20% legacy or special” cases. Microsoft describes this parallel approach as valid when scoped correctly.

This can be the cleanest path when:

The only non-negotiable: no object overlap.

How to deploy cloud sync and connect sync with guardrails

This section is intentionally dense and practical. Treat it as a runbook. It focuses on cloud sync first, then connect sync, then migration/coexistence patterns.

Part 1: production setup for entra connect cloud sync (agent-based)

Architecture in one paragraph

Cloud sync uses the microsoft entra cloud provisioning service plus an on-premises provisioning agent installed on a domain-joined windows server. The agent authenticates to entra, reads from active directory, applies scoping and mapping rules defined in the entra admin center, and provisions into entra id.

1) prerequisites that actually matter (beyond “windows server 2016+”)

Microsoft’s prerequisites are clear, but the “why” matters more than the checkbox list.

Key items and what they imply:

2) install the provisioning agent like you expect to audit it later

High-level steps are straightforward:

  1. In the entra admin center, navigate to entra id → entra connect → cloud sync and download the provisioning agent installer.
  2. Run the installer on the chosen server, then register it to your tenant during setup.

What advanced admins do differently:

Common failure: agent registration fails because registration scripts can’t run due to local powershell execution policy restrictions. Microsoft documents this as a known troubleshooting area.

3) create the configuration in entra, but design the scope first

In the portal, the guided experience is:

The portal flow is easy. The scope design is the hard part.

Scope design rules:

Cloud sync explicitly supports ou scoping, and the broader planning guidance emphasizes avoiding object overlap when piloting with connect sync. (GitHub)

4) password hash sync: enable it, then validate it scientifically

Cloud sync supports password hash sync, and it runs on a frequent schedule.

Validation checklist (practical):

  1. Pick 2–3 test users inside your scoped ou/group.
  2. Change passwords on-prem.
  3. Wait for at least one full phs cycle (minutes).
  4. Verify sign-in to a cloud-only app, and confirm audit events in entra.

If password hash sync “does nothing,” the first-principles diagnosis is usually:

That overlap mistake is a common migration foot-gun, and you can see it reflected in real-world admin threads when connect sync is still installed and partially running.

Also note: microsoft documents that some password hash sync failures on the first run can be expected behavior.
So don’t panic on day one. Validate with a small, repeatable test set.

5) use on-demand provisioning as a “lint tool” before going wide

One of cloud sync’s most operationally valuable features is on-demand provisioning, which allows you to test an object and see what would happen before you flip the whole directory into scope.

Treat this like a pre-merge check in software engineering:

You’re looking for mapping surprises early.

6) operational monitoring and troubleshooting

Start with microsoft’s troubleshooting guide when something is off. It covers agent connectivity, registration, proxy patterns, and other recurring failures.

Practical monitoring habits:

Cloud sync’s faq also helps set realistic expectations for sync intervals and explains some “why did it fail once?” behaviors.

Part 2: production setup for entra connect sync (classic) with resilience

Connect sync is mature and powerful. It also behaves like a classic enterprise sync engine: local rules, local database, local scheduler, local patching.

1) don’t run it as a single point of failure

Microsoft’s supported topology guidance is blunt: multiple active connect sync servers for the same tenant is not supported, except for a staging server.

So build it properly:

Microsoft documents staging mode operational tasks and the importance of ensuring only one active sync server at a time.

If you are already deep into connect sync, staging mode discipline is the difference between “planned maintenance” and “identity outage.”

2) password hash sync fundamentals still apply

If your hybrid auth depends on password hash sync, understand the mechanism. The connect sync password hash agent requests password hashes using directory replication protocols and re-hashes them before sending to entra.

When troubleshooting, microsoft’s dedicated guidance helps isolate “no passwords sync” vs “subset of users.”

This matters for comparison: cloud sync may simplify management, but the underlying ad replication realities still exist.

Part 3: migration and coexistence without breaking identities

If you are moving from connect sync to cloud sync, microsoft provides a migration guide and a pilot tutorial designed for safe transition.

The migration mindset should be:

Recommended high-level flow (conceptual, not every click):

  1. confirm cloud sync is a fit using microsoft’s decision guide (feature + scale).
  2. back up / export connect sync configuration (so you can compare and revert if needed).
  3. pilot cloud sync in a restricted scope while ensuring connect sync scope excludes those objects.
  4. validate provisioning, group behavior, and password hash sync using a test matrix.
  5. expand scope gradually.

Coexistence pattern: microsoft’s hybrid scenarios guidance supports running cloud sync and connect sync in parallel for different scoped objects, which can be ideal when you need connect sync for specific capabilities while cloud sync handles other forests or simpler identity populations.

Advanced comparisons that matter in the real world

Most “connect vs cloud sync” articles stop at feature tables. Useful, but not sufficient. Here are the deeper axes that experienced operators actually care about.

Change management and blast radius

The practical outcome: cloud sync often reduces the number of bespoke sync “snowflakes” you can create. That is good for standardization, but it may be limiting for edge-case enterprises.

Resilience and operational overhead

Cloud sync’s architecture is explicitly positioned to reduce single points of failure and on-prem management burden.
Connect sync can be resilient, but you must build that resilience (staging server, documented failover, disciplined upgrades).

Topology flexibility

Cloud sync supports disconnected forest scenarios that connect sync can’t do.
If your org does acquisitions, divestitures, or isolation-by-design networks, this alone can decide the outcome.

Scale constraints and group realities

Cloud sync’s documented limits (including large group membership constraints) are not academic. They affect licensing groups, app assignment groups, and role groups in real tenants.

If you have massive groups, you either:

Authentication strategy

Cloud sync pairs naturally with password hash sync. If your organization is still on pass-through authentication or deep ad fs dependencies, connect sync may remain in the picture, even if you move other pieces. Microsoft’s decision guide explicitly calls out differences here.

Key takeaways: what to remember when you leave this page

Exit mobile version