Entra ID: Blocking Nested Security Groups

Why nested groups pose problems in access management

Nested groups (groups added as members of other groups) are convenient for organizing authorization hierarchies, but they seriously complicate access auditing. Knowing who actually has access to a sensitive resource becomes an exercise in traceability through multiple levels of groups, with sometimes inconsistent support across Microsoft 365 workloads. Distribution groups tolerate this model better, since the stakes are limited to email routing rather than granting permissions on confidential data.

Microsoft has just added a new property named disableNesting to group objects in Microsoft Graph, allowing you to explicitly lock this nesting possibility at the level of a given security group.

Understanding the disableNesting property

By default, disableNesting is false: the current behavior of security groups is unchanged, nesting remains possible. When set to true on a security group, Entra ID refuses any attempt to add another group as a member of that group.

A notable point for architects: the property is available directly on the production endpoint V1.0, whereas most Entra features transit first through the beta endpoint before being promoted. This suggests a feature deemed stable enough by Microsoft for direct production deployment, even though the associated user experience (UX) in the portal has not yet followed.

Creating a security group with nesting disabled

Creation is done via the Graph API, passing disableNesting to true in the request body. There is currently no equivalent option in the portal.

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

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

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

Here is the error returned when attempting a post-hoc update:

1$UpdateBody = @{}
2$UpdateBody.Add("disableNesting", $false)
3Update-MgGroup -GroupId $Group.Id -BodyParameter $UpdateBody
4 
5Update-MgGroup_Update: Unexpected request made to property 'disableNesting' of resource 'Group'.
6Status: 400 (BadRequest)

Practical consequence for planning: if an existing group needs to switch to a "nesting forbidden" mode, it will need to be recreated and its members migrated, not simply patched with the property.

Filtering and querying the disableNesting property

The Groups endpoint of Graph API supports filtering on disableNesting, on both V1.0 and beta. Example to find all security groups (non-mail-enabled) that block nesting:

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

The equivalent raw Graph request:

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

To query a specific group, you must explicitly request the property, as it is not part of the default property set returned:

1$Uri = ("https://graph.microsoft.com/V1.0/groups/{0}?`Select=id,displayname,disableNesting" -f $NewGroup.Id)
2$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PsObject
3$Data | Format-List
4 
5@odata.context : https://graph.microsoft.com/v1.0/$metadata#groups(id,displayName,disableNesting)/$entity
6id             : 778818b5-7e68-4bc2-b667-0aa996c80280
7displayName    : Finance Auditors
8disableNesting : True

Behavior when adding a nested member

If you try to add a group as a member of a group that blocks nesting, New-MgGroupMember (or the underlying Graph request) returns an explicit error:

1$GroupId = '9b5f3d2c-6c9f-4132-aa3d-88d903891206'
2New-MgGroupMember -GroupId $GroupId -DirectoryObjectId $NewGroup.Id
3 
4New-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 important detail is in the error message: blocking applies if either of the two groups has disableNesting set to true, whether it is the target group or the group candidate for nesting. In other words, a locked group cannot participate in any nesting relationship, neither as a container nor as a member.

Tests via the Entra Admin Center confirm this behavior: the attempt to add also fails from the portal, but with a much less explicit message than the one returned by the cmdlet. It is likely that Microsoft will harmonize this once the UX for managing disableNesting is available in the portal.

Required permissions: applying least privilege

To set disableNesting when creating a security group, the account used must have the Group.ReadWrite.All permission. Microsoft has however introduced a more granular permission, Group-NestingSupport.ReadWrite.All, which is also sufficient for the operation.

On the engineering side, it is reasonable to reserve Group-NestingSupport.ReadWrite.All for applications or runbooks dedicated to the governance of high-risk groups, rather than granting Group.ReadWrite.All broadly to a service principal that only needs to lock this property.

Known pitfalls and points of caution

• No graphical interface: all automation must go through Graph API or the PowerShell SDK, not through the Entra Admin Center for now.
• Property not modifiable after creation: plan the design of sensitive groups before production deployment, as a policy change requires recreation.
• Incomplete Get cmdlets: do not rely on Get-MgGroup or Get-MgBetaGroup to audit this property until the SDK schema is updated; use Invoke-MgGraphRequest with $Select.
• Bidirectional blocking: a locked group can neither receive a group member nor be added itself as a member of another group.
• Unequal error messages: the Entra portal is less verbose than PowerShell cmdlets in explaining a refusal to add; prefer scripts for precise diagnostics in production environment.

Recommended use cases in access governance

This feature makes full sense when you need to guarantee explicit and auditable group composition, namely for:

• privileged access groups used in administrative role assignments;
• access control to sensitive applications;
• dedicated access for executive accounts;
• resources subject to regulatory or compliance requirements;
• groups subject to regular access reviews.

For these scenarios, knowing precisely who has access to a resource is always better than having to trace back through a chain of nested groups during an audit or security incident.

Key takeaways

• disableNesting is a new Graph property of security groups that prohibits adding groups as members.
• It is defined only at group creation, via the V1.0 API or PowerShell SDK (New-MgGroup, tested in version 2.38.1).
• Blocking applies as soon as either of the two groups involved in the relationship has the property enabled.
• The Group.ReadWrite.All permissions or the granular Group-NestingSupport.ReadWrite.All permission are sufficient to create this type of group.
• The Entra Admin Center and Get-MgGroup / Get-MgBetaGroup cmdlets do not yet fully expose this property: expect future updates to the Graph schema and SDK.

Pending the arrival of the corresponding UX in the portal, security teams would be well advised to document from now on their sensitive groups that are candidates for this lockdown, so they can be recreated with disableNesting enabled during the next access governance review.