Learn

Architecture

Entra Connect Sync is a server-side synchronization engine that maintains a consistent view of identity objects across on-premises Active Directory and Microsoft Entra ID. Understanding its internal architecture is essential for troubleshooting sync issues, writing custom sync rules, and planning topology changes.

The Big Picture

Connect Sync runs as a Windows service on a domain-joined server. It reads identity data from one or more AD forests, merges it into a unified internal store, and pushes the result to Entra ID. The same pipeline can also write back selected attributes (passwords, groups, devices) from the cloud to on-premises AD.

Unlike Cloud Sync (which uses a lightweight agent), Connect Sync is a full server application with its own SQL database, rule engine, and management UI.

architecture-beta
    group onprem(server)[On-Premises]
    group engine(server)[Sync Engine]
    group cloud(cloud)[Microsoft Cloud]

    service ad(server)[Active Directory] in onprem
    service cs_ad(database)[AD Connector Space] in engine
    service mv(database)[Metaverse] in engine
    service cs_aad(database)[Entra Connector Space] in engine
    service entra(server)[Entra ID] in cloud

    ad:R --> L:cs_ad
    cs_ad:R --> L:mv
    mv:R --> L:cs_aad
    cs_aad:R --> L:entra

Core Components

Connectors

A connector is the bridge between the sync engine and an external directory. Each connector is configured for a specific data source (an AD forest, Entra ID, or another LDAP/SQL store) and handles reading and writing objects in that source’s native protocol.

Every connector maintains its own connector space, a local staging area that holds a cached representation of the objects it manages. The sync engine never talks to the external directory directly during rule evaluation; it always works from the connector space.

Connector Spaces

The connector space is a per-connector staging database. When the engine imports objects from AD or Entra ID, it writes them into the corresponding connector space. When it exports changes, it stages them in the connector space first, then pushes them out.

Objects in a connector space have two key properties:

  • Anchor - an immutable identifier that ties the staged object back to its source (typically objectGUID for AD objects)
  • Distinguished Name (DN) - the object’s location in the source directory hierarchy

Connector space objects are either staging objects (real imported data) or placeholders (references to objects not yet imported, like a manager in a different OU).

The Metaverse

The metaverse is the central identity store. It holds a single, merged representation of each identity across all connected directories. A user who exists in two AD forests and Entra ID will have one metaverse object linked to three connector space objects.

The metaverse is where attribute merging, conflict resolution, and provisioning decisions happen. Sync rules determine which connector space object contributes which attributes to the metaverse, and which metaverse attributes flow back out to connector spaces.

Sync Rules

Sync rules are the declarative configuration that controls everything: which objects are in scope, how connector space objects join to metaverse objects, and how attributes flow in each direction. Rules have a precedence value (lower number wins) and can be either inbound (connector space to metaverse) or outbound (metaverse to connector space).

Connect Sync ships with a large set of default rules. Custom rules should be created alongside (not modify) the defaults, so upgrades do not break your configuration.

The Sync Pipeline

Every sync cycle runs three phases in sequence: import, synchronization, and export. Each phase operates on one connector at a time.

Import

The engine queries the connected data source for changes since the last cycle (delta import) or reads everything (full import). Changed objects are written into the connector space and flagged as pending import with a modification type: Add, Update, or Delete.

Synchronization

The engine processes pending imports through the rule pipeline:

  1. Scope evaluation - determines which sync rules apply to each object
  2. Join - links connector space objects to existing metaverse objects (or creates new ones via projection)
  3. Attribute flow - applies inbound rules to update metaverse attributes from connector space data

Then outbound synchronization runs:

  1. Provisioning - creates or removes connector space objects based on metaverse changes
  2. Attribute flow - applies outbound rules to push metaverse attributes into connector spaces
  3. Objects with pending changes are flagged as pending export

Export

The engine pushes pending export changes to the connected data source. After a successful export, the engine re-imports the affected objects to confirm the data source accepted the changes. This confirmation step clears the pending export flag.

Object Lifecycle in the Engine

A connector space object is either joined (linked to a metaverse object) or disjoined (not linked). The lifecycle follows a predictable pattern:

  1. Object is imported into the connector space as a disjoined staging object
  2. A join rule or projection rule links it to a metaverse object, making it joined
  3. Attribute flows update the metaverse and other connector spaces
  4. If the object is deleted from the source, the metaverse link is removed
  5. If no connector space objects remain linked, the metaverse object is deleted

Tip: A common troubleshooting pattern is checking whether an object is joined or disjoined in the Synchronization Service Manager. A disjoined object will not flow attributes and will not be exported.

The Scheduler

Connect Sync runs on a fixed-interval scheduler, defaulting to a 30-minute cycle. Each cycle performs delta imports and delta syncs on all connectors, followed by exports. Full imports and full syncs are more expensive and only run when explicitly triggered (after configuration changes or for troubleshooting).

You can control the scheduler via PowerShell:

# Check scheduler status
Get-ADSyncScheduler

# Disable the scheduler (before making config changes)
Set-ADSyncScheduler -SyncCycleEnabled $false

# Re-enable
Set-ADSyncScheduler -SyncCycleEnabled $true

Server Model vs. Agent Model

Connect Sync uses a server model: a full Windows service with its own SQL database, rule engine, and management UI running on a dedicated domain-joined machine. This gives operators direct access to the sync pipeline, a rich UI for troubleshooting, and the ability to write arbitrarily complex sync rules.

Cloud Sync, by contrast, uses an agent model: a lightweight provisioning agent installed on-premises that receives its configuration from the cloud. The agent has no local rule editor, no local database you manage, and no Synchronization Service Manager. The trade-off is simpler deployment and automatic updates, but less control over edge-case customization.

This architectural difference is why Connect Sync remains necessary for advanced scenarios - the server model provides capabilities (device writeback, Exchange hybrid writeback, complex multi-forest join logic) that the agent model does not yet support.

Where Connect Sync Fits

In a hybrid identity deployment, Connect Sync is the data plane component. It does not handle authentication directly. The authentication path depends on which method you configure:

  • Password Hash Sync (PHS) - Connect Sync extracts password hashes from AD and syncs them to Entra ID. Authentication happens in the cloud.
  • Pass-Through Authentication (PTA) - lightweight agents on-premises validate passwords against AD in real time. Connect Sync still syncs identity objects, but passwords stay on-premises.
  • Federation (AD FS) - authentication is fully handled by on-premises federation servers. Connect Sync syncs identity objects only.

Regardless of which authentication method is chosen, Connect Sync is always responsible for keeping identity objects and their attributes consistent between AD and Entra ID.