Hybrid identity: choosing between Entra Connect Sync and Cloud Sync, and scoping what gets synchronised
Synchronisation between Active Directory and Entra ID is often installed once, with default options, and then forgotten. Yet it decides which accounts exist in the cloud, who owns them and what an attacker can do by moving from one world to the other. These are the design choices worth revisiting properly.
Two engines, two philosophies
Entra Connect Sync is the historical engine: a Windows server installed on premises, with its own database, rules engine and a wide range of features (device writeback, Exchange hybrid attributes, custom synchronisation rules, large volumes). It is powerful, but it is a heavy server that must be kept up to date and protected as a Tier 0 asset, since it holds high privileges in the directory and secrets that allow it to write to Entra ID.
Entra Cloud Sync relies on lightweight agents installed on premises, with the configuration and synchronisation engine hosted in the cloud. Several agents can be deployed for high availability, and the tool handles forests that are disconnected from each other well, for instance after an acquisition. Microsoft is clearly directing its investment towards Cloud Sync, but not every Connect Sync feature is available there yet.
Before you choose. The feature comparison between the two engines changes every quarter. Check the official matrix at the time of the project, particularly for Exchange writeback, devices and custom rules.
Topologies: keep it simple
A few rules underpin every topology:
- an object must be synchronised by one engine only; Connect Sync and Cloud Sync can coexist, but on separate scopes;
- an active Connect Sync server synchronises to a single tenant only;
- several forests can feed the same tenant, provided duplicate identities (the same user present in two forests) are matched correctly;
- any unusual topology must be checked against Microsoft's list of supported topologies.
In practice we often find architectures that are more complex than they need to be, inherited from successive projects. Simplification is a security measure in its own right.
The staging server
With Connect Sync, resilience comes from a second server in staging mode: it imports and calculates changes but exports nothing. It allows a quick failover if the active server fails and, above all, lets you preview the effect of a rule change or upgrade before making it live. This server holds the same secrets as the active one: it is also Tier 0 and must be patched at the same pace.
What to synchronise, and what not to
Synchronising "the whole directory" is the most common configuration, and the riskiest. Filtering must be explicit:
- OU filtering: only synchronise the OUs containing users, groups and devices that actually use cloud services.
- Exclude AD privileged accounts: domain administrators, service accounts and Tier 0 accounts have no business in Entra ID.
- Cloud-only admin accounts: privileged Entra ID roles must be assigned to accounts created directly in the cloud, never to synchronised accounts. Otherwise, compromising AD automatically hands over the tenant.
- Attributes: limit synchronised attributes to those actually used.
Authentication method and source of authority
Password hash synchronisation remains the most resilient method: it does not depend on any on-premises infrastructure at sign-in time and enables leaked credential detection. Pass-through authentication or federation add dependencies and components to protect. When federation is no longer justified, removing it simplifies the architecture.
The source of authority is the directory where an object is managed. For a synchronised object it is AD: any change made in Entra ID will be overwritten. Microsoft is gradually introducing ways to transfer the source of authority of some objects to the cloud; check their availability and limits before building a migration plan on them. For many organisations, the long-term goal is to reduce reliance on AD for objects that no longer need it.
What an audit checks
- The version and patch level of synchronisation servers or agents.
- Classification of the active and staging Connect Sync servers as Tier 0, and their hardening.
- The synchronisation scope: OUs, filters, absence of AD privileged accounts.
- No synchronised account holding a privileged Entra ID role.
- The permissions of the synchronisation service account in AD.
- The authentication method and the justification for any remaining federation.