Entra Connect Sync 2.5.76.0 was released on 2025-07-31, and the release notes included a cool new feature:
Group Source of Authority conversion feature allowing administrators to transfer on-premises Active Directory groups to become cloud only groups managed through Microsoft Entra ID (Public Preview).
Now, the “cloud only” bit in that sentence may be a typo, have no fear, as this feature will in fact take a group that is synced to Entra via Connect Sync, with the SOA being AD, and turn it into a group synced via Cloud Sync, moving the SOA to Entra, and retaining the same group in AD with the same SID in the process!
Why would you want to do this? This is nice as more and more provisioning processes shift to the cloud, and you can utilize things such as access packages in Entra to provide access to existing on-premises services utilizing existing groups.
Requirements and Assumptions
- Entra Connect Sync 2.5.76.0 installed and configured
- Entra Cloud Sync 1.1.1370.0 or later installed and configured
- As of 2024-05-13, version 1.1.1586.0 is the latest
- Be sure that Connect Sync and Cloud Sync are NOT syncing the same objects!
- Existing AD group(s) being synced to Entra via Entra Connect Sync
- These groups MUST be Universal in scope!
Docs
Credits
Lots of credit must be given here to Martin Himken as he was in WinAdmins Discord voice testing this out a bit, but ran into an issue (damn group scope!), and then I decided to test it out after hopping on. He also helped me out with the PowerShell to change the SOA, and my understanding of how to connect to Graph. He’s a pretty cool dude, and you should go follow him!
Let’s Do It!
First I’ll make a new group in the OU I have configured to sync via Connect Sync, add a member, and trigger a delta sync:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
New-ADGroup -Name 'Cloud Sync Test' -Path 'OU=Groups-Synced,OU=AJF-ONE,DC=ad,DC=ajf,DC=one' -GroupCategory Security -GroupScope Universal Get-ADGroup -Identity 'Cloud Sync Test' DistinguishedName : CN=Cloud Sync Test,OU=Groups-Synced,OU=AJF-ONE,DC=ad,DC=ajf,DC=one GroupCategory : Security GroupScope : Universal Name : Cloud Sync Test ObjectClass : group ObjectGUID : cc79e6ea-8fa4-42e1-a0ef-c5f888bb1eb9 SamAccountName : Cloud Sync Test SID : S-1-5-21-1730572994-3387147435-2638140007-3143 Add-ADGroupMember -Identity 'Cloud Sync Test' -Members 'ajf' Start-ADSyncSyncCycle -PolicyType Delta |
Once the delta sync is complete, let’s check the group in Entra, and confirm the source is AD and the membership is correct:
Next, let’s change the SOA using Graph:
|
1 2 3 4 5 6 7 8 9 10 11 |
Connect-MgGraph -Scopes 'Group.Read.All', 'Group-OnPremisesSyncBehavior.ReadWrite.All' $GroupID = 'daa94b20-6bbb-4fcd-abbb-c3d715dfbbde' $isCloudManaged = @{ isCloudManaged = $true } $JSONisCloudManaged = $isCloudManaged | ConvertTo-Json -Depth 10 Invoke-MgGraphRequest -Uri "https://graph.microsoft.com/beta/groups/$GroupID/onPremisesSyncBehavior" -Method PATCH -Body $JSONisCloudManaged -ContentType 'application/json' |
Now, if we go back to Entra and refresh, we’ll see the SOA has changed:
At this point, the existing sync via Connect Sync will be broken. By drilling down to the metaverse object properties in Connect Sync (follow the steps listed here), we” see that the attribute “blockOnPremiseSync” is set to “true”:
Finally, let’s add this group to the Entra -> AD Cloud Sync configuration. Under Scoping Filters, select the group and hit Save:
In my example, I have configured the target container to be a different OU than what Connect Sync is currently syncing, which I would recommend, to ensure you have no conflicts between the two sync methods. To speed up this initial process, I’ll trigger an on-demand provision of the group in Entra:
Now let’s look at the group in AD and see what changed:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# Before SOA Change Get-ADGroup -Identity 'Cloud Sync Test' DistinguishedName : CN=Cloud Sync Test,OU=Groups-Synced,OU=AJF-ONE,DC=ad,DC=ajf,DC=one GroupCategory : Security GroupScope : Universal Name : Cloud Sync Test ObjectClass : group ObjectGUID : cc79e6ea-8fa4-42e1-a0ef-c5f888bb1eb9 SamAccountName : Cloud Sync Test SID : S-1-5-21-1730572994-3387147435-2638140007-3143 # After SOA Change Get-ADGroup -Identity 'Cloud Sync Test' DistinguishedName : CN=Cloud Sync Test_c3d715dfbbde,OU=Groups,OU=TEST,DC=ad,DC=ajf,DC=one GroupCategory : Security GroupScope : Universal Name : Cloud Sync Test_c3d715dfbbde ObjectClass : group ObjectGUID : cc79e6ea-8fa4-42e1-a0ef-c5f888bb1eb9 SamAccountName : Cloud Sync Test SID : S-1-5-21-1730572994-3387147435-2638140007-3143 |
Sweet! The group was moved to the new OU, the SID is the same, and you’ll see that the Name attribute was changed; the string added to the end of the group name will match the last section of the object ID of the group in Entra. We did it!
Bonus Feature – Doing It All With Entra Cloud Sync!
After getting all of this working, I realized that this can be done entirely with Cloud Sync as well. The new feature and docs are targeted to folks that are currently already syncing group to Entra via Connect Sync, but if you’re like one of the crazy cats out there like Johannes (also a pretty cool dude that you should go follow), you’ve already gotten rid of Connect Sync.
If that’s the case, the first part of the process is to instead add your existing groups to the AD -> Entra Cloud Sync configuration, either by OU DN or adding specific groups. Once they are synced up to Entra, make the same change to the “isCloudManaged” attribute using the same PowerShell above, and then add the groups to the Entra -> AD Cloud Sync configuration, same as the second half of the above steps.
With the Entra -> AD configuration set up to use a different OU, we’ll ensure that the groups are moved between OUs in the process, and never have to worry about any sync conflicts, like I mentioned earlier. Pretty neat!
