top of page

Understanding Microsoft's Group Types: Definitions, Features & Group Nesting - part 2

*In the spirit of the upcoming Easter festivities, I thought it'd be quite fitting to envision our Microsoft groups as eggs nestled snugly within bird nests, mirroring the concept of group nesting we're exploring.


Welcome back to the Group Nesting Series! If you're new here, don't worry. You've arrived at the perfect spot to understand the ins and outs of group types and group nesting in Microsoft's world. In our first adventure, we learned all about different kinds of groups and what they can do. Now, we're diving even deeper into the maze of nested groups. Get ready for a journey through Microsoft 365's twists and turns! If you missed the first part, don't fret. You can catch up right here. Let's keep exploring!

Table of contents

1.Microsoft Entra group limits and restrictions

Microsoft Entra groups streamline the management of user access and permissions to resources, including potentially restricted apps and services. Rather than assigning special permissions to each user individually, you can create a group that automatically applies these permissions to all its members uniformly.

However, nothing in life is ever straightforward, and there are certain limits and restrictions that apply to Microsoft Entra groups. Here they are:

  • A Microsoft Entra organisation can have a maximum of 5,000 dynamic groups and dynamic administrative units combined.

  • A non-admin user can create a maximum of 250 groups in a Microsoft Entra organisation. However, any Microsoft Entra admin who can manage groups in the organisation can also create an unlimited number of groups (up to the Microsoft Entra object limit). If you assign a role to a user to remove the limit for that user, consider assigning a less privileged, built-in role such as User Administrator or Groups Administrator.

  • In a single Microsoft Entra organisation (tenant), you can create up to 500 role-assignable groups.

  • There's no limit to the number of Microsoft Entra resources that can be members of a single group.

  • Each group can have a maximum of 100 users as owners in a single Microsoft Entra organisation.

  • When selecting a list of groups, you can assign a group expiration policy to a maximum of 500 Microsoft 365 groups. There is no limit when the policy is applied to all Microsoft 365 groups.

  • Starting with Microsoft Entra Connect v2.0, the V2 endpoint is the default API. The number of members in a group that you can synchronise from your on-premises Active Directory to Microsoft Entra ID by using Microsoft Entra Connect is limited to 250,000 members.

  • Users can belong to any number of groups. When utilising security groups alongside SharePoint Online, a user's membership is limited to a total of 2,049 security groups, encompassing both direct and indirect memberships. NOTE: Be careful though as exceeding this limit may lead to unpredictable authentication and search results.

2. Group nesting limitations

Just as a reminder, group nesting involved placing one group inside another, creating a hierarchical structure. This arrangement aids in managing permissions and communication within an organisation effectively.

Figure 1 - Nested group structure example

Nested groups support various scenarios, including:

  • achieving group nesting by adding one group as a member of another,

  • conditional access policies with a group scope,

  • group membership claims, where an application is set up to receive group membership claims within the token, it encompasses nested groups where the signed-in user holds membership,

  • limiting users able to join and register devices to Entra ID,

  • restricting access to self-serve password reset.

However, nested groups do not support:

  • Microsoft 365 Groups,

  • adding security groups to Microsoft 365 groups,

  • app role assignment, whether for access or provisioning. While assigning groups to an app is possible, any nested groups within the directly assigned group won't inherit access,

  • adding groups to an on-premises Active Directory synced group,

  • group-based licensing that automatically assigns licenses to all group members,

  • adding groups as members of a role-assignable group,

  • applying licenses to nested security groups,

  • assigned membership for nested security groups to shared resources and apps,

  • including Microsoft 365 groups in security groups or other Microsoft 365 groups,

  • adding security groups as members of mail-enabled security groups.

Additionally, a group cannot serve as a group owner.

*** *** ***

Personally, I'm not a fan of using nested groups because there are so many intricacies involved that it's hard to remember how things will function when a nested group is involved. While nested groups present challenges, I also think they were intentionally designed to prevent replicating on-premises errors in the cloud. Workarounds such as dynamic groups exist but have limitations too.

Let me show you a few scenarios where nested groups might become problematic.

Scenario 1:

For instance, if we look at an example of group based licensing where nested groups are not supported, there are many organisation types that suffer because of this limitation.

If we examine an educational institution that manages a mixture of licenses, eg. A3 and A1, assigning licenses based on job titles or departments faces hurdles due to:

  • Entra ID P1 feature requirements for dynamic group membership,

  • inability to exclude groups in dynamic group queries,

  • you cannot apply conflicting A1 and A3 licenses to the same user.

Scenario 2:

Another example of important limitations are Authentication method policies. Microsoft Entra ID offers a diverse array of authentication methods to accommodate various sign-in scenarios, allowing administrators to tailor each method to their desired balance of user experience and security. However, it's crucial to note that nested groups are not supported within the scope of authentication method policies. This means that configurations applied within the policy will only affect direct members of the group within the specified scope, and not users who are part of a group that has been nested inside another group.

Figure 2 - Authentication methods | Policies

Figure 3 - FIDO2 security key settings

Scenario 3:

However, if you wish to mandate the use of a particular authentication strength, such as built-in or custom authentication methods like phishing resistant FIDO2, you can employ a conditional access policy to accomplish this. Interestingly, group nesting is supported for conditional access group scopes, allowing for more flexible enforcement of authentication requirements.

Figure 4 - Example of a conditional access policy's group scope

Figure 5 - Members of my nested groups used within the group scope of my conditional access policy

Figure 6 - Conditional Access policy - Require authentication strength setting

Additionally, I wouldn't be myself if I didn't discuss some of the Microsoft Purview solutions :)

Scenario 4:

In one of the Microsoft docs, we can also read, that Microsoft "We currently don't support: (...) Adding distribution groups in nesting scenarios.(...)", which is not entirely true.

For instance, in Information Protection, nested groups can be utilised for publishing sensitivity labels, but only within two specific scenarios. As many are aware, when assigning permissions to specific groups on the Access control settings page within sensitivity label settings, only mail-enabled groups can be utilised.

Figure 7 - Access control settings within a sensitivity label

This restriction also applies to label policies.

Figure 8 - Group scope for a sensitivity label policy to which my sensitivity label is being published to

Nested groups can be deployed within Information Protection, as long as a distribution list is nested within another distribution list, and a mail-enabled security group is nested within another mail-enabled security group (Microsoft 365 groups cannot be nested in any scenario).

Visual representation of what that nesting structure may look like below:

Figure 9 - Example of a nested group's structure/ hierarchy

3. Key takeaways

  • Microsoft Entra groups streamline user access and permissions to resources, reducing the need for individual permissions assignments.

  • Various limits and restrictions apply to Microsoft Entra groups, including maximum group creation, ownership limits, and group expiration policies.

  • Nested groups support certain scenarios like achieving group nesting and conditional access policies, but have limitations such as no support for Microsoft 365 Groups or group-based licensing.

  • While nested groups present challenges, they prevent on-premises errors in the cloud, and workarounds like dynamic groups exist (with some limitations).

  • Authentication Method policies in Microsoft Entra ID offer diverse options but do not support nested groups, whereas conditional access policies allow, for example, authentication strength enforcement and support group nesting.

  • Additionally, nested groups can be used in Microsoft Purview solutions like Information Protection, albeit with limitations in certain scenarios.

To download a printable nested group matrix, please refer to part 1 of the group nesting series ->

Figure 10 - Nested groups matrix

4. Summary

In this tech blog post, we've delved into the intricate world of group nesting within Microsoft Entra. From understanding the supported scenarios to navigating the limitations, we've explored the complexities involved in managing nested groups effectively. While nested groups offer a streamlined approach to user access and permissions, they also come with their fair share of challenges. I'm eager to hear your thoughts on this topic! Feel free to leave your feedback in the comments below or DM me directly. And don't hesitate to connect with me on LinkedIn—I'm always open to engaging with fellow tech enthusiasts. Looking forward to hearing from you all!

Wishing a joyful Easter to all who celebrate!


bottom of page