Entra ID Enables Blocking for Nested Security Groups

New disableNesting Property Gives Administrators Greater Control Over Security Groups

I’ve never been a big fan of nested groups. I know that some people love the concept and happily build complex hierarchies of nested groups, but it seems like nested groups create a level of complexity when managing permissions that most Microsoft 365 tenants could do without. Distribution groups also support nesting, but the argument is different because the outcome is email addressing rather than granting permissions to what could be highly confidential data. And it’s not just Entra ID that plays in this game. The value of nested groups depends on workload support, and the simple fact is that support across Microsoft 365 is often inconsistent or incomplete.

Microsoft has reignited the argument by adding a disableNesting property for security groups. The default value is false, meaning that security groups support nesting as they do today. If set to true for a security group, Entra ID blocks the addition of other groups as group members. The feature is still under development, so the Entra admin center doesn’t yet support the feature. If you want to create a new security group with nested disabled, you’ll have to do so through the Graph API.

Here’s an example:

$RequestBody = @{}
$RequestBody.Add("displayName","Finance Auditors")
$RequestBody.Add("securityEnabled", $true)
$RequestBody.Add("disableNesting", $true)
$RequestBody.Add("mailEnabled", $false)
$RequestBody.Add("mailNickname", "Finance.Auditors")
$RequestBody.Add("description", "A security group for financial auditors. Nesting is disabled for this group")

$Uri = "https://graph.microsoft.com/V1.0/groups"
Try {
   $NewGroup = Invoke-MgGraphRequest -Uri $Uri -Method Post -Body $RequestBody -ErrorAction Stop
   Write-Host ("Created group: {0}" -f $NewGroup.DisplayName)
} Catch {
   Write-Host "Failed to create group"
}

Alternatively, you can replace the Invoke-MgGraphRequest cmdlet with the New-MgGroup cmdlet from the Microsoft Graph PowerShell SDK (I used version 2.38.1):

$NewGroup = New-MgGroup -BodyParameter $RequestBody -ErrorAction Stop

It’s interesting that the V1.0 (production) endpoint accepts the disableNesting property when creating a group. Most of the time, new Entra features surface through the beta endpoint.

Similar to the way that a container management label can only be assigned to a security group on creation, based on current testing it seems like the disableNesting property can only be set when a group is created. Subsequent attempts to change the value fail:

$UpdateBody = @{}
$UpdateBody.Add("disableNesting", $false)
Update-MgGroup -GroupId $Group.Id -BodyParameter $UpdateBody

Update-MgGroup_Update: Unexpected request made to property 'disableNesting' of resource 'Group'.
Status: 400 (BadRequest)

Filtering Against the disableNesting Property

The Graph Groups API supports filtering for the disableNesting property against either the V1.0 or beta endpoint. For example, this code fetches security-enabled groups that are not mail-enabled and disable nesting:

[array]$Data = Get-MgGroup -Filter "securityEnabled eq true and mailEnabled eq false and disableNesting eq true" -All

The equivalent Graph API request is:

$Uri = "https://graph.microsoft.com/V1.0/groups/?`$filter=securityEnabled eq true and mailEnabled eq false and disableNesting eq true&`$Select=id,displayname,disableNesting"
[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject | Select-Object -ExpandProperty Value

You can also retrieve the value of disableNesting on a per-group basis. Because the property is not one of the default property set for group objects retrieved by the Graph, you must explicitly request the property:

$Uri = ("https://graph.microsoft.com/V1.0/groups/{0}?`Select=id,displayname,disableNesting" -f $NewGroup.Id)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject
$Data | Format-List

@odata.context : https://graph.microsoft.com/v1.0/$metadata#groups(id,displayName,disableNesting)/$entity
id             : 778818b5-7e68-4bc2-b667-0aa996c80280
displayName    : Finance Auditors
disableNesting : True

Neither the Get-MgGroup nor Get-MgBetaGroup cmdlet returns a value for the disableNesting property. An update to the Graph schema followed by the generation of a new release for the Microsoft Graph PowerShell SDK is needed to add the property to the set available to these cmdlets.

Blocking Attempts to Create Nested Groups

If you try to add a group to a group with nesting disabled, the New-MgGroupMember cmdlet (or its underlying Graph request) signals an error:

$GroupId = '9b5f3d2c-6c9f-4132-aa3d-88d903891206'
New-MgGroupMember -GroupId $GroupId -DirectoryObjectId $NewGroup.Id

New-MgGroupMember_CreateExpanded: Cannot add group '778818b5-7e68-4bc2-b667-0aa996c80280' as a member to group '9b5f3d2c-6c9f-4132-aa3d-88d903891206' because nesting is disabled on one or both groups. paramName: Members, paramValue: , objectType: Microsoft.Online.DirectoryServices.Group

The error message reveals an interesting implementation detail. Nesting is blocked if either the target group or the prospective member group has disableNesting set to true. In other words, a group that blocks nesting cannot participate in a nested relationship on either side.

Some quick tests confirm that this is true, including attempts to add groups to groups which block nesting via the Entra admin center. The error displayed by the cmdlet is more informative than the one displayed by the Entra admin center (Figure 1). It’s likely that Microsoft will improve this situation when they introduce the necessary UX in the admin center to allow administrators to disable or reenable nesting.

To set the disableNesting property when creating a security group, the signed in account needs the Group.ReadWrite.All permission. Interestingly, Microsoft has created the more granular Group-NestingSupport.ReadWrite.All permission (Figure 2), which can also be used. I don’t know if the need exists for a dedicated permission to disable nesting when creating security groups, but it’s good to have it.

Potential Uses

Disabling nesting for security groups is a good idea. I think disabled nesting will be used for many purposes, including:

• Privileged access groups used for administrative role assignments.
• Groups used to control access to sensitive applications.
• Executive access.
• Regulatory or compliance-controlled resources.
• Groups subject to regular access reviews.

In short, although the feature is still not fully implemented, the ability to disable nesting for security groups helps administrators create security groups with explicit, auditable membership. For access control scenarios, knowing exactly who has access is always preferable to tracing permissions through layers of nested groups. Sometimes the simplest approach is the best one.

---

Microsoft 365 for IT Pros is a trusted source of technical insight that helps tenant administrators stay informed and productive. We update the content every month to reflect changes across Microsoft 365, and monthly update #134 is available now. Get your copy from Gumroad.com and stay up to date with the information that matters most for keeping your tenant secure, compliant, and running efficiently.