Connect, Cloud Sync, and writeback: The trust relationships of synchronization

1. Core mechanism

Synchronization is more than copying data: it connects two authority domains. The component operating the bridge needs permission to read from its source and, when writeback is enabled, permission to change its target. Sync servers, provisioning agents, and writeback service accounts therefore deserve protection proportional to the authority they carry. The synchronization product does not by itself determine how users authenticate; that is a separate design choice.

Interfaces and specifications

• Microsoft Entra Connect Sync is installed on-premises and runs synchronization orchestration there. When password hash synchronization (PHS) is configured, its AD DS connector account uses Replicate Directory Changes and Replicate Directory Changes All permissions to read the required password data. Cloud Sync can also enable PHS; the detailed Connect Sync derivation in12.02 is not a claim about Cloud Sync internals.
• Cloud Sync has two parts: the on-premises provisioning agent talks to AD DS; the cloud provisioning service owns configuration, scheduling and orchestration. The agent initiates its Service Bus connection outbound. The architecture page’s two-minute scheduler description does not guarantee that an object appears in Entra ID within two minutes.
• Cloud Sync uses SCIM requests over a persistent outbound Azure Service Bus connection. The agent queries Active Directory and applies configured scoping and attribute mappings; the cloud service processes the response and tracks incremental changes with a watermark.
• Cloud Sync supports multiple registered provisioning agents for high availability and automatic failover; this is not load balancing, and only one agent processes synchronization at a time. It can also synchronize multiple disconnected forests to one tenant.
• Password writeback sends a password change or reset from the cloud to on-premises AD DS in real time. It can be configured with Connect Sync or Cloud Sync. The operation is synchronous: AD DS password policy checks apply, and the user receives the result immediately.
• Writeback uses an Azure Service Bus relay and outbound communication over port 443, so it does not require an inbound firewall rule. The on-premises service account that processes writeback cannot change passwords for protected-group members.
• When Connect Sync and Cloud Sync are configured for the same domain, the Cloud Sync agent handles password writeback for users synchronized from that domain.

The direction of the bridge determines the direction of the privilege

The normal directory path copies users, groups and contacts from on-premises AD DS to Entra ID; PHS adds password-verification data in that direction. Provisioning objects from Entra ID to AD is a separate feature: on 3 October 2026 Microsoft Learn lists user provisioning as preview and group provisioning as generally available. Specify the object type and its source of authority separately.

Each direction requires its own authority: a read identity for the source and a write-capable identity for the target. If the enabled directions are not documented, the privilege inventory is incomplete. With writeback enabled, a cloud password-reset operation can change an on-premises password.

SSPR password writeback is a separate operation. Its documentation supports writeback through Connect Sync and Cloud Sync. The object-provisioning page’s note that password writeback is unavailable applies to that model; it does not remove general SSPR support.

The main difference between Connect Sync and Cloud Sync is the architecture

Cloud Sync's defining architectural difference is that provisioning orchestration runs in Microsoft’s cloud service. A lightweight agent remains on-premises as the bridge, while configuration and management are performed through the cloud service. This design supports synchronization from multiple disconnected forests without first consolidating them.

The architecture changes where synchronization rules are protected. Connect Sync stores and runs its rules on an on-premises server; Cloud Sync configuration is managed in the cloud. In both models, identify which principals can change the rules and scope.

Cloud Sync supports multiple registered agents for high availability and automatic failover, with one agent processing synchronization at a time. Connect Sync permits only one active server per tenant, but a staging-mode server can be kept current as a standby and promoted during failover. The two products therefore have different availability designs; neither should be described as active-active load balancing.

Writeback's limits are documented

Password writeback lets a user change or reset a password in the cloud and have that change applied to on-premises AD DS in real time. AD DS password policy is checked synchronously, so the user receives immediate feedback if the new password is rejected.

Two documented boundaries matter. The on-premises service account that handles writeback cannot change passwords for protected-group members. Also, writeback to on-premises AD is not supported for users included in a staged rollout group.

In a same-domain coexistence configuration, the Cloud Sync agent handles writeback for users synchronized from that domain. Record this ownership in the troubleshooting runbook so investigators start with the component that handles the request.

A cycle interval is not object visibility latency

The current Cloud Sync FAQ gives 2–5 minutes for PHS and approximately 10–20 minutes for user/group provisioning. The deep-dive page still describes a two-minute scheduler. These different descriptions are not a single latency SLA; name the workload and documentation scope.

An AD DS attribute change must pass scope checks, return through the agent and be written by the cloud service. Pending change volume can extend visibility latency. Writeback returns the result of its own synchronous request; it is not an object-copy operation waiting for the provisioning cycle.

State and data flow

1. When PHS is enabled with Connect Sync, the AD DS connector account uses its replication permissions to request password data from a domain controller; this is a privileged directory-read path.
2. The cloud provisioning service queues a request in Service Bus. The agent listening on its outbound connection receives the SCIM request, queries AD DS and returns the scoped/mapped response to the cloud service.
3. The provisioning service writes to Entra ID; the agent does not directly update the tenant directory. The service tracks incremental progress with a watermark. Cycle cadence and this object’s visibility latency are different measurements.
4. When a user resets a password in the cloud, the writeback request reaches the on-premises component over the Service Bus relay. AD DS policy is checked and the result is returned synchronously.
5. If the target account belongs to a protected group, the writeback service account cannot change its password. The recovery path for that account must be designed separately.

2. Exploitation

Broken trust assumption

The assumption is that “synchronization is just a background process that copies data; the sync server and agents are ordinary application servers, and writeback is just a user convenience.”

Technical prerequisites

• The identities used by Sync components are not authorized; When PHS is enabled, the connector account's replication permissions do not appear in the privilege inventory.
• It is not included as a separate line in the authorization model where writeback is turned on and a password reset on the cloud side is written to the on-premises directory.
• Sync server and provisioning agent servers are not classified as tier 0 assets; Administrator access to these servers is open to a large team.

Exploitation mechanism

This assumption obscures where the identity boundary actually ends. The component operating the synchronization bridge carries the permission to read from the source directory; When PHS is enabled, this authority is an authority that can read sensitive data through replication. When writeback is on, the bridge also has a way to change the password on the target. Therefore, a person with administrative access to the sync server or agent server stands at the intersection of two domains: directory data on one side, and the cloud management surface on the other. If this component is managed like a regular application server, the identity boundary is effectively moved to a weaker server, even if the domain controllers are hardened. The same logic applies to the cloud side: Since the rules in Cloud Sync are kept in the cloud, those with the relevant cloud management roles can change the synchronization scope and transformations.

The bridge is only as strong as its weakest end

If an organization meticulously protects its domain controllers but keeps its sync server in a standard server pool, the identity limit effectively comes down to that pool. In the PHS flow documented by Microsoft, replication permissions for the connector account are granted by default at installation; The existence of these permissions is part of the design, not an anomaly. What is abnormal is that the component carrying this authority operates at a low trust level.

This lesson does not include steps to execute an attack. The defensive implication is clear: sync servers and provisioning agent servers should be treated in the same class as domain controllers in terms of administrative access, login restriction, patching, application whitelisting, and monitoring.

Writeback turns cloud decision into on-premises effect

While writeback is on, a password reset on the cloud side changes the password of the on-premises account. This is a great convenience for help desk processes; It also means that cloud management privileges have an on-premises effect. If the authorization model does not specify this impact, a role defined as 'cloud administrator only' may actually affect on-premises accounts.

The documented limit provides a critical balance here: the writeback service account cannot change the passwords of protected group members. This limit is the safety side of the design and should not be attempted to be removed; The recovery path for privileged accounts is designed as a separate, controlled, on-premises process.

3. Defense & Detection

Telemetry scope

• Keep which bridges are open in a single table: Connect Sync, Cloud Sync, PHS, password writeback, and cloud-to-AD provisioning if applicable. Direction, ID used and scope should be written on each line.
• Regularly verify the authorization of Sync identities; Especially monitor accounts with replication permissions in a separate tier 0 list.
• Maintain a provisioning-agent inventory: host, forest, number of registered agents, and which agent is currently processing synchronization. Multiple registered Cloud Sync agents support failover; a single-agent deployment is a single point of failure.
• If Writeback is on, record which domains are processed by which component; When Connect Sync and Cloud Sync are configured together for the same domain, the Cloud Sync agent processes the writeback.
• Write the password recovery path separately for protected group members; These accounts cannot be reset with writeback.

Events and relevant fields

• A read using replication permissions is the expected behavior for sync identity in a PHS-enabled environment; If the same access pattern comes from a different identity or a different source, it should be evaluated separately.
• For a late object, identify the workload: the Cloud Sync FAQ gives PHS a 2–5-minute cadence and user/group provisioning approximately 10–20 minutes. Change volume affects actual latency; two elapsed minutes prove neither completion nor failure.
• Just because an object is not visible in the cloud does not mean it is deleted; It may be out of scope due to scoping rules or attribute mapping.
• A failed writeback operation is not always a connection problem; If the target account is a member of the protected group, this result is a documented limit.
• Since agents use only outbound connections, network analysis performed in anticipation of inbound rules may be misleading; writeback communication is outbound via 443.

Sync scope is a security decision

Scoping rules and attribute mapping are often viewed as an operational setting, whereas they are security decisions that determine which objects and which fields are moved to the cloud. When the scope is wider than necessary, information kept limited in on-premises becomes accessible on the cloud surface; When the scope is narrower than necessary, access decisions made with missing identity data on the cloud side produce incorrect results.

Therefore, scope changes must go through change management and clearly define who can change. Keeping the configuration in the cloud in Cloud Sync makes this question even more important: rules can now be changed without access to the on-premises server.

Choose the right component in troubleshooting

A significant portion of hybrid identity incidents are prolonged because they are investigated in the wrong component. If an attribute is not updated in the cloud, the problem may be in the scope of synchronization or mapping; If a password reset does not reach on-premises, the problem may be in the writeback path or the target account's membership in the protected group; If cloud sign-in fails, the problem may be on a completely separate axis, the sign-in method.

Having a single decision tree in the runbook separating these three axes significantly shortens the average solution time. The first question of the decision tree is always: in which direction is the indication, in the read direction, in the write direction, or in the verification direction?

Detection logic · KQL

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4662
| where Properties contains "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
| summarize operations = count() by Account, Computer, bin(TimeGenerated, 1h)
| order by TimeGenerated asc

Query assumptions

• This example targets the Azure Monitor SecurityEvent table, where Properties is documented as a string and may be empty. Verify how the collector maps 4662 properties to this column. The query has not been run in a real workspace.
• Generation of the 4662 record depends on appropriate audit policy and object SACL configuration; Just because the query doesn't return results doesn't mean there is no access.
• contains searches the hyphenated GUID as a case-insensitive substring; has searches alphanumeric terms. This is only a candidate-row filter, and a longer string containing the GUID can also match. Read ObjectName, ObjectType, AccessMask, outcome and identity/source context before drawing conclusions about replication or intent.

False positives

• In a PHS-enabled environment, regular replication access of the sync identity is expected behavior; The existence of these records does not in itself indicate bad faith.
• Backup, monitoring, or directory auditing tools can also produce similar access patterns; identity and resource server should be considered together.
• Negative example: if the audit policy is missing, no actual replication access is recorded at all; Returning empty is not proof of security.

Hardening

• Classify sync server and provisioning agent servers as tier 0 entities; Bind admin access to a separate, monitored path.
• Include cloud roles that can change synchronization rules in privileged access review; In Cloud Sync, the configuration is kept in the cloud.
• Limit the writeback scope to only the needed domains and user groups; Keep the coverage decision with a written justification.
• Define a non-writeback, controlled on-premises password recovery procedure for protected group members.
• Deploy multiple agents for high availability in Cloud Sync; Save single-agent installations as an availability risk.
• In coexistence scenarios, document which component handles the writeback; point to the correct log source in the troubleshooting runbook.

Read the examples

O:DAG:DAD:P(OA;CI;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-4071847660-1138144873-2902452632-1181)(OA;CI;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-4071847660-1138144873-2902452632-1181)(A;;RPLCLORC;;;AU)

Two reality checks

Assumption: Synchronization is one-way: data flows only from on-premises Active Directory to Microsoft Entra ID.

In fact: Directions are configured separately. SSPR writeback can send a cloud password operation to AD DS, which applies its password policy. Entra ID→AD object provisioning is another feature: current documentation lists users as preview and groups as GA. Enabling one does not enable the other or general bidirectional synchronization.

Assumption: If password writeback is turned on, the password of each account can be reset from the cloud.

In fact: No. The on-premises service account that handles writeback cannot change passwords for protected-group members. Those users may change their own passwords in the cloud, but writeback cannot reset a forgotten on-premises password for them. Writeback to on-premises AD is also unsupported for users included in a staged rollout group.

Sources

• Microsoft · What is Microsoft Entra Cloud sync?
  Cloud Sync components, cloud orchestration and high availability. Timing and SCIM ownership are linked separately to FAQ and deep-dive references.
• Microsoft · On-premises password writeback with self-service password reset
  Writeback working in real time with Entra Connect or cloud sync; on-premises AD DS policy checks; synchronous operation and immediate feedback; 443 outbound over Azure Service Bus relay; service account boundary for protected group members; staged rollout note; in coexistence within the same domain, writeback being handled by the Cloud Sync agent.
• Microsoft · Implement password hash synchronization with Microsoft Entra Connect Sync
  Replicate Directory Changes and Replicate Directory Changes All permissions of the ADDS Connector account; unicodePwd request with the MS-DRSR replication protocol; two-minute synchronization cycle.
• Microsoft · Active Directory extended rights: DS-Replication-Get-Changes-All
  The rightsGuid value 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 of the control access right and its definition for reading directory changes in their full scope.
• Microsoft · DS-Replication-Get-Changes extended right (AD Schema)
  CN DS-Replication-Get-Changes, Display-Name Replicating Directory Changes, Rights-GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2; the extended right required to replicate changes from a naming context.
• Microsoft · 4662(S, F) An operation was performed on an object
  Event XML and Field Descriptions; ObjectServer=DS, Properties GUID field, and AccessMask; the event being generated only when the relevant object has a SACL.
• Microsoft · Microsoft Entra Connect Sync: staging server and disaster recovery
  Connect Sync uses an active-passive model: only one server actively exports, while a staging-mode server imports and synchronizes without exports and can be promoted during failover. Cloud Sync's multiple registered agents provide high availability/automatic failover; only one processes synchronization at a time.
• Microsoft · Cloud Sync deep dive
  SCIM request/response through Service Bus and agent; service writes Entra ID; two-minute architecture description contrasted with current FAQ.
• Microsoft · Cloud Sync FAQ
  How often does cloud sync run?; one active agent
• Microsoft · Provision Entra ID objects to AD
  User preview / group GA; password writeback note scoped to object provisioning
• Microsoft · Kusto string operators
  Alphanumeric term boundaries; contains is case-insensitive substring scanning
• Microsoft · SecurityEvent table
  Properties string; EventID int; object-specific event population