The road to cloud-only security groups

🌴The summer vacation is now over and after several weeks with more sun and less computer screen, and I hope you all enjoyed it as well. Anyway, I am back again so let us not waste any time and get straight into the next blog post: Security groups!

I assume most of you have a rather large Active Directory environment which takes a lot of time and effort to transition into Entra. Going cloud-only may seem like a enormous task, but now we can come one step further by converting our synchronized AD security groups into cloud-only Entra security groups.

👉 This feature is currently in public preview

Looking at Source of Authority (SOA)

The Source of Authority (SOA) is very simple: Which source is controlling the object? Is it controlled by on-premises AD or is it a cloud-only group managed by Entra?

When you synchronize a group from AD to Entra, by either Entra Connect Sync or Cloud Sync, the SOA is naturally your on-premises AD. The is where the group “belongs” and changes to the group in AD, is replicated and reflected in Entra, while you are unable to change most settings from Entra.

This should be very familiar if you’ve tried to make changes in Entra to a group which is synchronized from AD, as these groups must be managed from on-premises AD.

You can easily check the SOA in Entra by looking at the Source property, either “Windows Server AD” or “Cloud“.

Prepare to change a groups SOA

👉 Since this feature is in preview this is subject to change. Always check with Microsoft for the latest information. (Link)

• Microsoft recommends you to convert security groups to Universal if you want to provision a converted SOA group back to on-premises AD.
• Changing the SOA only applies to the specified group and this is not recursive. This means that if you have nested groups (group with other groups as members) then the other groups will not be affected. This is by design by Microsoft and you must explicitly change SOA to each group you want to convert.
• You need Entra Connect sync minimum version 2.5.76.0 or Cloud sync client minimum version 1.1.137.0
• To make the changes you need the API permission “Group-OnPremisesSyncBehavior.ReadWrite.All“
• Sign in to your tenant with the approporate API permissions and get the access token
  • You can use Graph Explorer if you don’t want to create an app registration for this purpose
• You need the group id for the group you wish to convert – the script below can assist you

Changing a security groups SOA from AD to Entra

Currently this option is not available in the Microsoft Graph modules as far as I know, so we have to use API calls for this. But don’t worry if you haven’t done that before, we can still use PowerShell for this task.

<#
.SYNOPSIS
    Microsoft Graph API script to manage Entra group sync behavior (cloud vs on-premises)

.DESCRIPTION
    This is a sample script to demonstrate how to:
    - List all Entra groups and their IDs
    - Check a group's sync behavior (cloud-managed vs AD-managed)
    - Change a group's sync behavior using Microsoft Graph API
    
    The script helps identify groups and modify their onPremisesSyncBehavior property.

.AUTHOR
    Per-Torben Sørensen, Senior Architect, Crayon AS

.NOTES
    WARNING: This is a sample script only, not meant for production use.
    This script is provided without any kind of warranty and must be used at your own risk.
    Feel free to copy and modify according to your needs.
    
    Requirements:
    - Valid Microsoft Graph API access token with appropriate permissions
    - Group.Read.All and Directory.ReadWrite.All permissions

.EXAMPLE
    1. Insert your access token in the designated variable
    2. Run the first part to list all groups and find your target group ID
    3. Insert the group ID in the designated variable
    4. Use the sample code to check and modify sync behavior
#>

$accessToken = [INSERT YOUR ACCESS TOKEN HERE]

# Header with Access token
$headers = @{
    'Authorization' = "Bearer $accessToken"
    'Content-Type' = 'application/json'
}

#region Find target group with group ID
$allgroupsUri = "https://graph.microsoft.com/beta/groups?`$select=displayName,id"
$restParams = @{
    Uri     = $allgroupsUri
    Headers = $headers
    Method  = 'Get'
}
$Targetgroups = Invoke-RestMethod @restParams
$Targetgroups.value = $Targetgroups.value | Sort-Object displayName

# List all groups by display name and id
Write-Host "All Groups:" -ForegroundColor Green
foreach ($group in $Targetgroups.value) {
    Write-Host "$($group.displayName) - " -NoNewline
    Write-Host $group.id -ForegroundColor Yellow
}
#endregion

#region Change group SOA
$groupid = [INSERT GROUP ID HERE]
$groupUri = "https://graph.microsoft.com/beta/groups/$groupid"
$syncUri = "https://graph.microsoft.com/beta/groups/$groupid/onPremisesSyncBehavior"

# Get group info
$restParams = @{
    Uri     = $groupUri
    Headers = $headers
    Method  = 'Get'
}
$groupData = Invoke-RestMethod @restParams
# Get group sync info
$restParams = @{
    Uri     = $syncUri
    Headers = $headers
    Method  = 'Get'
}
$SyncData = Invoke-RestMethod @restParams
Write-host "Group $($groupData.DisplayName) is cloud-managed: $($SyncData.isCloudManaged)" -ForegroundColor Yellow

# Set group to cloud-managed
$restParams = @{
    Uri     = $syncUri
    Headers = $headers
    Method  = 'Patch'
    Body    = (@{ isCloudManaged = $true } | ConvertTo-Json)
}
Invoke-RestMethod @restParams

# Revert group to AD-managed
$restParams = @{
    Uri     = $syncUri
    Headers = $headers
    Method  = 'Patch'
    Body    = (@{ isCloudManaged = $false } | ConvertTo-Json)
}
Invoke-RestMethod @restParams
#endregion

This script has 2 regions: The first is to help yo find your group and its ID, and the other lets you use the ID to check the status of the group and toggle it as either cloud-managed or revert to AD-managed. You should obviously run this on a test group first to get familiar and this script is without any warranties. Use at your own risk.

Testing the solution

I’m currently working with a test group named “Game of Thrones”, which is synchronized from my on-premises environment. Because of this synchronization, I’m unable to make changes to the group directly in Microsoft Entra, such as updating its name or modifying its properties.

I have the object Id of the group, so I simply insert it into the script and by running line 59-77 it confirms it is not cloud-managed.

Then simply run the lines 80-86 on the script above and it is set to cloud-managed, and re-run the check

🥳 The last step is to run a sync with Entra Connect (or Cloud sync) and I can now change the properties of the group in Entra because it is cloud managed.

The fine print… 😱

The information whether the group is synced or converted to cloud-only is written to the group object in Entra, in an attribute named “blockOnPremisesSync“. False = synced, True = SOA changed to Entra.

This means that on-premises AD does NOT know that this group is now a cloud-only group. Which again has the following consequence:

You can still make changes to the group in your on-premises AD, but these changes will NOT be synchronized to Entra anymore. Likewise any changes made to the group in Entra will NOT be synchronized to your on-premises AD.

This can obviously lead to confusion and configuration errors since the group can be changed in two places now without synchronization in between. So I advice you to have a solid plan on either mark the groups clearly in AD after they have been converted to cloud-only, and/or change the permissions on the group in AD to make it read-only. This must of course be clearly communicated to everyone involved and management routines must be updated accordingly.

Also if you delete the group in Entra, and it still remains in the sync-scope from you AD, then the group will be synchronized again from AD just like it was before you changed its SOA.

Wrapping up

The shift to cloud-only security groups in Entra is not only a technical tweak, but also a strategic step toward a cleaner, leaner identity management in Entra. This preview feature can potentially bring you a large step towards going cloud-only, but like all things in IT, caution and testing are your best friends.

Until next time, happy syncing!