Microsoft Entra Cloud Sync — Cross-domain group membership not syncing when users are managed by Entra Connect Sync

Serhii Zahuba 0 Reputation points
2026-11-05T10:05:04.78+00:00

Microsoft Entra Cloud Sync — Cross-domain group membership not syncing when users are managed by Entra Connect Sync

Hello,

We are testing a gradual migration from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync in a multi-domain Active Directory forest.

We encountered an issue where groups are successfully synchronized to Microsoft Entra ID, but members from another AD domain are not added, even though those users already exist in Entra ID and are synchronized by Entra Connect Sync.

Environment

We have a single Active Directory forest with multiple child domains:

example.com — forest root domain

ua.example.com — child domain A

rs.example.com — child domain B

Additional child domains

Microsoft Entra Connect Sync currently synchronizes production users across these domains.

We are testing Cloud Sync with a small, isolated OU in the forest root domain.

Test configuration

We created a Universal Distribution Group:

Group DN: CN=test_cloud_group,OU=test_cloud,DC=example,DC=com

Group email: [email protected]

The group contains two members:

Member 1 — test_user

AD domain: example.com

DN: CN=test_user,OU=test_cloud,DC=example,DC=com

Synchronized by Microsoft Entra Cloud Sync

Cloud UPN: [email protected]

Successfully appears as a group member in Exchange Online

Member 2 — user_from_child_domain

AD domain: ua.example.com

DN: CN=user_from_child_domain,OU=IT,OU=Office,DC=ua,DC=example,DC=com

Synchronized by Microsoft Entra Connect Sync

Cloud UPN: [email protected]

Already exists in Microsoft Entra ID

onPremisesSyncEnabled = True

Does not appear as a member of the synchronized group

We confirmed that Member 2 has matching AD ObjectGUID / Entra OnPremisesImmutableId and matching on-premises / cloud security identifiers.

Error in Cloud Sync provisioning logs

The following error occurs when provisioning the group (identifiers anonymized):

We were unable to assign <USER_OBJECT_GUID> as the Member of <GROUP_OBJECT_GUID>.

In order to ensure that the references are updated properly, you have two options.

First, ensure that <USER_OBJECT_GUID> is in scope for provisioning.
Provision <USER_OBJECT_GUID> on-demand and then provision
<GROUP_OBJECT_GUID> on-demand.

Alternatively, you can restart provisioning after ensuring that
<USER_OBJECT_GUID> is in scope for provisioning.

The first GUID corresponds to the on-premises AD ObjectGUID of the affected user in the child domain.

Troubleshooting performed

Verified the group membership in on-premises Active Directory. Both users are present.

Confirmed that the Cloud Sync-managed user appears as a member of the group in Exchange Online.

Confirmed that the user from the child domain already exists in Microsoft Entra ID and is synchronized by Entra Connect Sync.

Verified matching ObjectGUID/ImmutableId and SID values for the affected user.

Added OU=test_cloud,DC=ua,DC=example,DC=com to the same Cloud Sync configuration's scoping filters. This did not resolve the issue.

Confirmed that the Exchange Online Distribution Group contains only the locally scoped Cloud Sync test user.

Production users in the child domain remain synchronized by Entra Connect Sync.

Questions

Does Microsoft Entra Cloud Sync support group memberships across different AD domains within the same forest?

Can Cloud Sync resolve members who already exist in Microsoft Entra ID but are managed by Entra Connect Sync?

Must each child domain have its own Cloud Sync configuration to resolve group membership references?

Is it supported to include an OU from a child domain in a Cloud Sync configuration associated with the forest root domain?

Is this behavior caused by provisioning scope, coexistence with Entra Connect Sync, or a current product limitation?

What is the recommended approach for gradually migrating groups when their members remain synchronized by Entra Connect Sync?

Our goal is to migrate gradually, without changing existing user UPNs, creating duplicate objects, or disrupting production group memberships.

Any guidance or references to official Microsoft documentation would be appreciated.

Thank you.

Microsoft Entra Cloud Sync — Cross-domain group membership not syncing when users are managed by Entra Connect Sync

Hello,

We are testing a gradual migration from Microsoft Entra Connect Sync to Microsoft Entra Cloud Sync in a multi-domain Active Directory forest.

We encountered an issue where groups are successfully synchronized to Microsoft Entra ID, but members from another AD domain are not added, even though those users already exist in Entra ID and are synchronized by Entra Connect Sync.

Environment

We have a single Active Directory forest with multiple child domains:

example.com — forest root domain

ua.example.com — child domain A

rs.example.com — child domain B

Additional child domains

Microsoft Entra Connect Sync currently synchronizes production users across these domains.

We are testing Cloud Sync with a small, isolated OU in the forest root domain.

Test configuration

We created a Universal Distribution Group:

Group DN:
CN=test_cloud_group,OU=test_cloud,DC=example,DC=com

Group email:
[email protected]

The group contains two members:

Member 1 — test_user

AD domain: example.com

DN: CN=test_user,OU=test_cloud,DC=example,DC=com

Synchronized by Microsoft Entra Cloud Sync

Cloud UPN: [email protected]

Successfully appears as a group member in Exchange Online

Member 2 — user_from_child_domain

AD domain: ua.example.com

DN: CN=user_from_child_domain,OU=IT,OU=Office,DC=ua,DC=example,DC=com

Synchronized by Microsoft Entra Connect Sync

Cloud UPN: [email protected]

Already exists in Microsoft Entra ID

onPremisesSyncEnabled = True

Does not appear as a member of the synchronized group

We confirmed that Member 2 has matching AD ObjectGUID / Entra OnPremisesImmutableId and matching on-premises / cloud security identifiers.

Error in Cloud Sync provisioning logs

The following error occurs when provisioning the group (identifiers anonymized):

We were unable to assign <USER_OBJECT_GUID> as the Member of <GROUP_OBJECT_GUID>.

In order to ensure that the references are updated properly, you have two options.

First, ensure that <USER_OBJECT_GUID> is in scope for provisioning.
Provision <USER_OBJECT_GUID> on-demand and then provision
<GROUP_OBJECT_GUID> on-demand.

Alternatively, you can restart provisioning after ensuring that
<USER_OBJECT_GUID> is in scope for provisioning.

The first GUID corresponds to the on-premises AD ObjectGUID of the affected user in the child domain.

Troubleshooting performed

Verified the group membership in on-premises Active Directory. Both users are present.

Confirmed that the Cloud Sync-managed user appears as a member of the group in Exchange Online.

Confirmed that the user from the child domain already exists in Microsoft Entra ID and is synchronized by Entra Connect Sync.

Verified matching ObjectGUID/ImmutableId and SID values for the affected user.

Added OU=test_cloud,DC=ua,DC=example,DC=com to the same Cloud Sync configuration's scoping filters. This did not resolve the issue.

Confirmed that the Exchange Online Distribution Group contains only the locally scoped Cloud Sync test user.

Production users in the child domain remain synchronized by Entra Connect Sync.

Questions

Does Microsoft Entra Cloud Sync support group memberships across different AD domains within the same forest?

Can Cloud Sync resolve members who already exist in Microsoft Entra ID but are managed by Entra Connect Sync?

Must each child domain have its own Cloud Sync configuration to resolve group membership references?

Is it supported to include an OU from a child domain in a Cloud Sync configuration associated with the forest root domain?

Is this behavior caused by provisioning scope, coexistence with Entra Connect Sync, or a current product limitation?

What is the recommended approach for gradually migrating groups when their members remain synchronized by Entra Connect Sync?

Our goal is to migrate gradually, without changing existing user UPNs, creating duplicate objects, or disrupting production group memberships.

Any guidance or references to official Microsoft documentation would be appreciated.

Thank you.

Microsoft Security | Microsoft Entra | Microsoft Entra ID
0 comments

2 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Jose Benjamin Solis Nolasco 12,941 Reputation points Volunteer Moderator
    2026-11-05T12:16:26.4233333+00:00

    Welcome to Microsoft Q&A

    Hello @Serhii Zahuba I hope you are doing well today,

    Based on the provisioning error:

    "We were unable to assign <USER_OBJECT_GUID> as the Member of <GROUP_OBJECT_GUID>"

    the key observation is that Cloud Sync is unable to resolve the referenced member as an in-scope object for the provisioning configuration that is processing the group.

    A few points that may help answer your specific questions:

    1. Are cross-domain group memberships supported?

    Yes. Microsoft Entra Cloud Sync supports multi-domain and multi-forest topologies, and cross-domain group memberships within the same forest are supported scenarios.

    2. Can Cloud Sync resolve members that already exist in Entra ID but are synchronized by Entra Connect Sync?

    This is the area that deserves closer examination.

    Although the user already exists in Microsoft Entra ID and has:

    onPremisesSyncEnabled = True

    the provisioning error suggests Cloud Sync isn't resolving the corresponding on-premises object as part of its synchronization scope. Existing Entra ID presence alone doesn't appear to be sufficient for Cloud Sync to establish the membership reference.

    3. Does each child domain require its own Cloud Sync configuration?

    Potentially yes.

    One detail I'd verify is how the provisioning configuration was created.

    Cloud Sync configurations are associated with specific AD domains. Simply adding a child-domain OU to the scoping filter doesn't necessarily mean objects from that child domain are being processed by the same configuration.

    To isolate whether this is a scope issue or a coexistence issue:

    1. Verify that the child-domain user is included in the Cloud Sync provisioning scope.
    2. Use Provision on demand against the affected child-domain user.
    3. Confirm whether Cloud Sync can successfully locate and provision that object.
    4. After the user provisions successfully, rerun Provision on demand for the group.
    5. Review whether the membership is then correctly created.

    The provisioning error itself specifically references ensuring the user is "in scope for provisioning," which makes scope validation the first thing I would investigate.

    5. Migration approach

    For gradual migration scenarios, I would recommend keeping related objects together where possible:

    • Users
    • Groups
    • Contacts
    • Membership references

    Mixing a Cloud Sync-managed group with members that are only visible through Entra Connect Sync can introduce reference-resolution challenges during coexistence testing.

    References

    Migrate from Microsoft Entra Connect Sync to Cloud Sync: decision guide

    Provision Active Directory to Microsoft Entra ID - Configuration

    Microsoft Entra Cloud Sync supported topologies and scenarios

    One additional question: if you run Provision on demand against the child-domain user (user_from_child_domain), does Cloud Sync report that the user is in scope and provisioned successfully, or does it report that the object is out of scope? That result would help determine whether this is primarily a provisioning-scope issue or a coexistence limitation.

    If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find similar solutions. Thanks!

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-11-05T10:07:25.72+00:00

    Keep the pilot group and all referenced members in Microsoft Entra Connect Sync scope, apply the documented cloudNoFlow/JoinNoFlow coexistence rules only to the objects being migrated, and let Connect Sync continue exporting reference attributes such as member until the entire cross-domain reference set is ready for cutover.^1^

    The provisioning error indicates that Cloud Sync cannot resolve the child-domain member as an in-scope source reference in the root-domain configuration. Matching ObjectGUID, ImmutableId, and SID does not by itself put that AD object in the configuration’s provisioning scope.

    Correct the pilot configuration

    Prerequisites are administrative access to the Connect Sync server and at least Hybrid Identity Administrator for Cloud Sync administration.

    1. Check guided-migration eligibility first.
      If the guided migration option is available and its readiness review succeeds, use it. Otherwise, use the advanced manual coexistence procedure below.^2^
    2. Back up the Connect Sync configuration.
    3. Ensure the pilot group, test_user, and the referenced child-domain user remain in Connect Sync scope.
      If the root pilot OU was already excluded from Connect Sync, add it back before continuing. Both sides of the membership reference must remain represented in the Connect connector space and metaverse during coexistence.
    4. Check the source anchors for pilot objects.
      The documented migration procedure requires ms-DS-ConsistencyGuid on pilot objects so Cloud Sync can hard-match them. Connect Sync does not populate this attribute by default for groups, so check the group specifically; matching ObjectGUID and ImmutableId alone does not complete this migration prerequisite.^1^
    5. Stop the Connect Sync scheduler before changing its rules: 
         Stop-ADSyncSyncCycle
   Set-ADSyncScheduler -SyncCycleEnabled $false
    6. Create the documented inbound rule for each pilot object type—user, group, and contact where applicable:
      • Synchronization Rules Editor → Direction: Inbound → Add new rule
      • Connected system: the applicable AD connector
      • Connected system object type: user, group, or contact
      • Metaverse object type: corresponding metaverse type
      • Link type: Join
      • Precedence: a unique value
      • Scoping filter: pilot OU using DN ENDSWITH <pilot-OU-DN>, or the documented pilot-group filter
      • Transformation: constant True → cloudNoFlow
    7. Create the matching outbound rule for each applicable object type:
      • Direction: Outbound → Add rule
      • Connected system: Microsoft Entra connector
      • Link type: JoinNoFlow
      • Precedence: a unique value
      • Scoping filter: cloudNoFlow = True
      • No attribute transformations
      Follow the tutorial fields exactly. These rules suppress object adds, deletes, and non-reference attribute exports from Connect Sync, while allowing member and manager references to continue flowing.^1^
    8. Restart the Connect scheduler: 
         Set-ADSyncScheduler -SyncCycleEnabled $true
   Start-ADSyncSyncCycle
    9. Run Cloud Sync after the scope and coexistence model are correct:
      Microsoft Entra admin center → Entra ID → Entra Connect → Cloud sync → select the root-domain configuration → Restart sync.^3^
    10. Verify the group membership in Entra ID/Exchange Online before removing anything from Connect Sync scope.

    Answers to the topology questions

    • Cross-domain membership: Supported. Cloud Sync supports cross-domain user references, and a single-forest topology can contain multiple domains.^4^^5^
    • Members managed by Connect Sync: Coexistence is supported, but an existing Entra object is not automatically an in-scope Cloud Sync source object. During migration, Connect Sync can continue maintaining reference attributes while Cloud Sync takes authority for the intended pilot objects.
    • Configuration per child domain: Create/select a configuration for the child domain when Cloud Sync is intended to provision that domain’s objects. Adding a child-domain OU DN to a configuration created by selecting the root domain does not move that child domain into the root-domain configuration. Cloud Sync configuration creation explicitly requires selecting the AD domain.^3^
    • Current case: This is not evidence of a general cross-domain limitation. It is consistent with an unresolved, out-of-scope source reference combined with an incomplete coexistence arrangement.

    If objects were already removed from Connect Sync scope

    Re-add the affected group and members to Connect Sync scope and run a full synchronization to rebuild connector-space, metaverse, and membership references. Then apply the no-flow rules and retest. Removing objects too early can export reference deletions and remove group memberships.^1^

    Do not cut over a domain or OU until all related users, groups, contacts, managers, and memberships have been migrated and reference validation succeeds.

    References

    1. Tutorial: Migrate to Microsoft Entra Cloud Sync for a synced Active Directory forest
    2. Migrating from Microsoft Entra Connect to Microsoft Entra Cloud Sync
    3. Provision Active Directory to Microsoft Entra ID - Configuration
    4. Migrate from Microsoft Entra Connect Sync to Cloud Sync: decision guide
    5. Microsoft Entra Cloud Sync supported topologies and scenarios
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.