Architecture

Entra Cloud Sync is a cloud-managed provisioning service that synchronizes identities between on-premises Active Directory and Microsoft Entra ID. It replaces Connect Sync’s heavyweight server model with a lightweight provisioning agent plus cloud-side orchestration, shifting all configuration and sync logic into the cloud.

The Big Picture

Cloud Sync’s architecture has two parts: a thin on-premises agent and a cloud-based provisioning service. The agent handles communication with Active Directory. The provisioning service in Entra ID handles everything else: configuration storage, scheduling, attribute mapping, scoping filters, and change processing.

This split is intentional. The agent is a relay, not a decision-maker. It receives SCIM requests from the cloud, queries AD, and returns results. All sync logic runs in the cloud.

architecture-beta
    group onprem(server)[On-Premises]
    group azure(cloud)[Microsoft Cloud]

    service ad(database)[Active Directory] in onprem
    service agent1(server)[Provisioning Agent] in onprem
    service agent2(server)[Provisioning Agent 2] in onprem
    service bus(server)[Azure Service Bus] in azure
    service provisioning(server)[Provisioning Service] in azure
    service entra(database)[Entra ID] in azure

    ad:R --> L:agent1
    ad:R --> L:agent2
    agent1:R --> L:bus
    agent2:R --> L:bus
    bus:R --> L:provisioning
    provisioning:R --> L:entra

Compare this with Connect Sync’s architecture, where a full sync engine with its own SQL database, metaverse, connector spaces, and rule editor runs on a dedicated on-premises server. Cloud Sync deliberately avoids all of that complexity.

The Provisioning Agent

The provisioning agent is a Windows service installed on a domain-joined server (or directly on a domain controller). It uses the same underlying technology as Microsoft Entra Application Proxy and Pass-Through Authentication agents.

Key properties:

• Outbound-only connections. The agent initiates outbound connections to Azure Service Bus. No inbound firewall rules are needed. Required ports are 80 (CRL checks) and 443 (HTTPS communication).
• GMSA for AD access. The agent uses a Group Managed Service Account (gMSA) to read from and write to Active Directory, avoiding stored credentials.
• Automatic updates. Microsoft pushes agent updates through the cloud. No manual patching cycle.
• Lightweight footprint. The agent has no local database, no rule editor, no management UI. It can run on existing infrastructure without dedicated hardware.

Multi-Agent High Availability

You can install multiple agents pointing at the same AD forest. If one agent goes down, others continue processing sync requests automatically. There is no “staging server” concept like Connect Sync; all agents are active.

This is a significant operational improvement. With Connect Sync, failover requires either promoting a staging server or rebuilding from scratch. With Cloud Sync, you install a second agent and HA is automatic.

Cloud-Side Orchestration

All sync intelligence lives in the Entra ID provisioning service:

• Configuration. Scoping filters, attribute mappings, and sync rules are stored in the cloud and managed through the Entra admin center or MS Graph API.
• Scheduling. The sync engine runs on a 2-minute interval (compared to Connect Sync’s default 30-minute cycle). This is not configurable but provides near-real-time synchronization.
• Change tracking. The provisioning service uses watermark-based tracking to process only changed objects on each cycle.
• SCIM protocol. Communication between the cloud service and agents uses the System for Cross-domain Identity Management (SCIM) standard.

Sync Flow

A typical sync cycle works like this:

1. The provisioning service identifies objects that need synchronization (based on watermarks and change detection).
2. It sends SCIM requests to the agent through Azure Service Bus.
3. The agent queries Active Directory for the requested objects.
4. The agent applies configured scoping rules and returns filtered results.
5. The provisioning service processes attribute mappings and transformations.
6. Changes are committed to Entra ID.

For cloud-to-AD provisioning (group writeback), the flow reverses: the provisioning service sends SCIM write requests to the agent, which creates or updates objects in AD.

Supported Topologies

Cloud Sync handles several topology patterns:

• Single forest, single tenant. The simplest case. One or more agents in a single AD forest sync to one Entra ID tenant.
• Multi-forest, single tenant. Multiple AD forests (connected or disconnected) sync to one tenant. Each forest gets its own agent(s).
• Disconnected forests. Forests that have no network connectivity to each other. Each forest has local agents, and the cloud service merges identities by matching attributes (typically mail). This is a scenario Connect Sync cannot handle without complex workarounds.
• Coexistence with Connect Sync. Cloud Sync and Connect Sync can run side by side in the same forest, with different OUs scoped to each engine. This enables phased migration.

What Cloud Sync Does Not Have

Understanding what is absent is as important as understanding what is present:

• No metaverse. There is no central identity store with connector spaces. The cloud service handles identity merging directly.
• No local rule editor. Attribute mappings and expressions are configured in the cloud portal or via MS Graph API. The agent has no local configuration UI.
• No Synchronization Service Manager. You cannot inspect individual object join states, pending imports, or pending exports on the agent itself. Troubleshooting uses the cloud provisioning logs instead.
• No arbitrary sync rule precedence. Cloud Sync’s expression builder supports attribute transformations, but it does not have Connect Sync’s full declarative provisioning engine with numbered precedence rules.

These trade-offs are deliberate. The simplified model covers the majority of sync scenarios while making deployment, updates, and troubleshooting significantly easier. For scenarios that need the missing capabilities, Connect Sync remains the tool. See When Connect Sync still wins.

Object and Scale Limits

Current limits to be aware of:

These limits are lower than Connect Sync’s (which has no hard object cap and supports groups up to 250,000 members). For most organizations they are not a constraint, but large enterprises should verify their object counts before migrating.

Where Cloud Sync Fits

Like Connect Sync, Cloud Sync is the data plane for hybrid identity. It does not handle authentication directly. The authentication method (Password Hash Sync, Pass-Through Authentication, or Federation) is configured separately. Cloud Sync always handles identity object synchronization; PHS can optionally be enabled alongside it for cloud-based password validation.

Cloud Sync is Microsoft’s strategic direction for hybrid identity. New features (group provisioning to AD, source of authority management, cloud-native identity scenarios) are being built exclusively on the Cloud Sync platform.