Mastering Groups

This section exists because of a study session. I was working through my SC-300 prep, following Ewelina's group type breakdown, and I started building test groups to validate what I was reading. Create an M365 group from the Admin Center. Create the same type from Entra. Compare.

They came back different. That was the thread that unravelled everything in this section.

Both groups are groupTypes: ["Unified"]. Both have mailEnabled: true. But the Entra-created group came back with securityEnabled: true, while the Admin Center version returned securityEnabled: false. That one difference cascades into real-world consequences across licensing, CA policy scoping, and more.

The reason this matters: creation is when group properties get set. Some of those properties are immutable after the fact. By the time you notice a gap, the fix is delete and recreate, not edit.

Once I had two groups with different securityEnabled values, the obvious next test was licensing. Can I assign a license to either of them?

Graph enforced the rule cleanly. securityEnabled: true gets licensed. securityEnabled: false gets a hard 400. Not a portal quirk. A Graph-level constraint.

Then I tried the Entra portal. The Licenses tab redirects you out entirely, telling you to use the Admin Center.

So Admin Center it is. Except when you search for an M365 group to assign a license, it does not show up. The picker only surfaces pure security groups.

The Admin Center picker is scoped to pure security groups. M365 Unified groups, even with securityEnabled: true, do not appear. If you want to assign a license to an M365 group, Graph is the only path.

Distribution groups and mail-enabled security groups surface another portal boundary. You can find them in Entra. You can view their properties. But the moment you try to manage membership or modify them, Entra points you elsewhere.

Mail-enabled security groups are Exchange-managed objects. Entra shows them because they have a presence in Entra ID, but write operations route back to Exchange Admin Center or the Microsoft 365 Admin Center. This is the read-only pattern.

After testing across portals, here is what it actually looks like.

As best I can tell at time of writing, all group types outside of dynamic distribution groups are at least visible inside both Entra and the Admin Center. Dynamic distribution groups are Exchange Admin Center only. They have no Entra presence at all.

Portal behavior across this section kept exposing the same pattern: things that appear settable are not, things that appear visible cannot be changed, and some things are only reachable through Graph at all. Collecting these in one place is useful.

The common thread is that these are creation-time properties the portals either hide during creation or do not surface for editing afterward. By the time you discover the gap, the group has to be deleted and recreated. That makes knowing these exist before you build more important than discovering them after.

Part 6 goes deeper into the protection layer: how to lock groups down, how administrative units and restricted management interact with membership and visibility, and how sensitivity labels fit into the picture.

At this point you know how groups work, how they nest, where they live, and how different portals surface them differently. The natural question is: how do you actually lock them down? Who can create them, who can modify them, and how do you prevent a group that matters from being tampered with?

That is what this section covers. The mechanisms are layered. None of them are complete solutions on their own. Together they give you intentional control.

The first question most admins ask is: "Can I just disable this setting so nobody can create groups?" The answer is: yes, partially, and it depends on which type of group you mean.

In Entra's User Settings panel, there is a single toggle for security group creation by regular users. When set to No, only admins can create security groups. This is the right starting point for any tenant that wants controlled, named, governed groups rather than group sprawl.

But that setting only covers security groups created through Azure portals, the API, and PowerShell. M365 Unified Groups have a separate control, and it lives elsewhere.

M365 group creation is governed through the Groups General settings in Entra. This panel also exposes controls for Self Service Group Management, the Microsoft 365 Groups toggle itself, and directory-wide group settings. The controls here cover group creation from Azure portals, the API, and PowerShell.

What the portal UI description says is "Azure portals, API, or PowerShell", and that phrasing is easy to misread as leaving Teams, SharePoint, and Outlook untouched. It does not. Because Entra ID is the directory of record for all M365 groups, the restriction enforces a tenant-wide check on any user-initiated group creation regardless of which workload initiates it. Block group creation in Entra and you block it in Teams, SharePoint, and Outlook too. What the UI description is actually telling you is the admin surfaces where the setting itself can be configured, not the scope of what it restricts.

What this means for the demo below is deliberate. The Azure portal is the surface that makes the restriction most visible to an infrastructure engineer. Severus Snape has Contributor rights on the subscription. He can deploy resources. He cannot create Entra objects. The Azure portal is where that wall is most likely to surprise someone who does not think of Azure RBAC and Entra permissions as separate planes.

Severus Snape is a Contributor on the Azure subscription. He can deploy infrastructure. He cannot create groups. When settings are correctly configured, he hits the wall even in the Azure portal.

Two interesting things visible in the test. First, the Group type dropdown shows Microsoft 365 as the only available option. This is because the security group creation toggle was set to No in User Settings, which blocks that pathway but does not suppress the M365 option in the Azure portal UI. Second, the creation attempt fails regardless, because the Groups General setting also blocks M365 group creation.

This matters. Azure RBAC and Entra group controls are separate authorization planes. A Contributor can deploy resources. They cannot create Entra objects unless granted that permission explicitly.

The M365 group creation control is a CIS benchmark check. Inforcer surfaces this directly. When the setting is correctly configured you see a pass. Microsoft's reference for managing who can create M365 groups is documented here: Manage who can create Microsoft 365 Groups.

The underlying setting lives in the Group.Unified directory settings object via Graph. The two key values are EnableGroupCreation and GroupCreationAllowedGroupId. The second one matters more than it looks: it scopes creation rights to a specific group, which means you can allow a governed set of users to create M365 groups without opening creation to everyone.

Sensitivity labels are one of the clearest signals that identity administration and data governance are becoming the same job. I wrote about this after Ignite and built this image to capture the core idea:

M365 Groups have supported sensitivity labels for some time. When a label is applied to a group, it enforces settings on the group as a container: privacy configuration, external user access, external sharing from connected SharePoint sites, and Conditional Access controls for labeled SharePoint sites. The label overrides whatever privacy setting was on the group. Apply a Confidential label that enforces Private, and the group becomes Private regardless of what it was before.

The practical use case I tested before building this series: restricting guests from being added to a group that handles internal-only documentation. A sensitivity label that blocks external user access enforces that at the group level, not at the admin's discretion on any given day.

Reference: Microsoft's InsideTrack article on sensitivity labels and Entra. Also a walkthrough video I recorded: YouTube walkthrough.

For Entra security groups, sensitivity label support is currently in preview. The same labels you publish in Purview apply to cloud security groups with no separate label configuration required. Limitations: dynamic membership groups, synced groups, and Exchange-managed groups are excluded. Flag this as preview behavior before writing it into any production documentation.

One mechanism to limit internal visibility is HiddenMembership on M365 Unified Groups. This is a soft protection. Think of the guest enumeration scenario covered in Section 05. The idea is similar but points inward: limiting what users inside the organization can see about group membership.

When visibility: HiddenMembership is set on an M365 group, non-members cannot see who is in the group. Members can still see each other. Owners and admins retain full visibility regardless. This is not a security boundary. Admins, PowerShell cmdlets, and Graph with sufficient permissions bypass it. It is a guardrail against casual enumeration, not a defense against determined insiders or malicious actors with admin access.

Combined with HiddenFromAddressListsEnabled, these are your primary tools for limiting how much of a group's identity is visible to users who aren't members. Neither replaces proper access control. They reduce surface area.

From soft membership visibility controls to the hardest protection available: Administrative Units, and specifically Restricted Management Administrative Units.

I covered this in depth in a separate article: AU vs RMAU on conditionalaccess.tech. The section here focuses specifically on how AUs and RMAUs interact with group protection.

One of my favorite articles on this topic is by cybersecurity researcher Jay Kerai: The main reason you shouldn't exclude break-glass groups from access. Jay's argument is that groups are too easily modified by too many roles, and the safer path is to not use groups for break-glass CA exclusions at all.

I think both positions have merit. The graphic below captures where Jay and I land:

Jay's core concern: many roles can modify or create groups in ways you might not expect. The blast radius of a misconfigured or compromised group containing a break-glass exclusion is significant. He is right. The answer is not to abandon groups. The answer is to lock the groups down with the right mechanism: RMAUs.

An RMAU places the group under restricted management. Only scoped administrators explicitly assigned to that RMAU can modify the objects inside it. Global Admin cannot touch them unless granted that scoped role. This is the correct protection model for break-glass exclusion groups, CA exclusion groups, and any group that if modified would create a security incident.

This is the feature most people have never heard of. An RMAU can also have visibility: HiddenMembership. This means non-members cannot see who is in the AU. Only users with specific privileged roles, or users who are members of the AU, can see membership. Jay Kerai mentioned this in a presentation. Katie Knowles documented how it can be abused for persistence: Abusing Entra ID Administrative Units.

Worth knowing it exists for two reasons. First, so you can use it intentionally to limit visibility of your most sensitive administrative scopes. Second, so during post-incident reconnaissance you do not overlook AUs or RMAUs that an attacker may have created. Hidden membership means they do not show up in standard directory browsing.

At time of writing, HiddenMembership on an RMAU can only be set at creation via Graph Explorer, using the beta endpoint:

To demonstrate the effect: Snape, who is a member of the RMAU, can see its members when viewing it in the portal.

Dolores Umbridge, who is not a member and holds no scoped role over the RMAU, sees nothing:

Is this overkill for most MSPs? Probably. The AU and RMAU post on conditionalaccess.tech covers the reality that most MSPs are not using AUs at all today. That should change. The hidden membership layer on top of an RMAU is the far end of the intentionality spectrum, but it is a real tool and it is worth understanding what it does.

If you are using hidden membership RMAUs or AUs in production, reach out. I would love to hear the specific use case that drove the decision.

Part 8 covers the key gotchas, the things that catch people regardless of how much they know.

Everything covered so far in this series assumes you know what you have and why it exists. In most tenants that assumption fails the moment you look closely. Groups accumulate. Names drift. Purposes get blurry. And without a consistent structure from the start, every admin after you is reading tea leaves trying to figure out what a group does and whether they can touch it.

Governance does not begin at the expiration policy or the access review. It begins at the name.

Entra has two native mechanisms under Groups, Naming Policy. The first is prefix and suffix enforcement for M365 groups. You define a string that gets prepended or appended to any group name a user creates. The second is a blocked words list, where specific terms are rejected outright. Neither of these is a complete naming system. But they are a signal to the org that naming is intentional, and they catch the worst drift at creation time.

The limitation is scope. The Entra naming policy only applies to M365 groups created by users. It does not cover security groups. It does not apply when admins create groups. And it does not tell anyone what the name means or how it maps to a purpose. That requires a standard.

Back in Section 2 I referenced my naming convention and the scripts behind it. The idea is not complicated. Every group should be readable at a glance. The name tells you the type, the scope, the purpose, and the membership model. Without that, you end up with groups named "Marketing Team" sitting next to "Mktg-Team-Old" and nobody willing to delete either because nobody knows if they are the same thing.

I learned this the hard way. At my previous company I built a naming convention that worked well at first and ran out of runway as the use of groups grew. New use cases arrived that the original names did not anticipate. GDAP relationships, SPO governance groups, Purview DLP scopes, all required naming that the original system could not cleanly accommodate. Retrofitting it was painful. That experience drove me to build something that was designed to scale rather than something that had to be extended after the fact.

The full standard lives in my GitHub repo: Jhope188/LearnGraphAPI, Baseline/Entra. The infographic below captures the core logic.

The naming document does more than define prefixes. It explains why each group exists, what the type codes mean, how the scope segment maps to the actual workload, and what the membership model implies. AUG means assigned user group, where an admin assigns members manually. DUG means dynamic user group, where a dynamic rule evaluates attributes to determine membership. That distinction matters for CA policy scoping, licensing, and governance reviews.

One deliberate decision baked into the standard: any script that creates groups automatically adds the user running it as a group owner. If you are going to provision a set of groups, you should carry accountability for them. Ideally, a second owner with domain knowledge is added afterward. The Intune admin should own SG-Intune groups. The department manager should own the DG-SPO groups for their team.

Each group category has its own provisioning script. Security groups, Intune device groups, GDAP admin groups, SPO governance groups, Purview governance groups, AI agent groups, and the RMAU with hidden membership covered in Section 6. The scripts handle creation, naming, owner assignment, and in some cases the properties that have to be set at creation time.

The repo also includes the DisableM365GroupCreation script with the option to pass in a single group as the creation-allowed group, which maps directly to the Group.Unified GroupCreationAllowedGroupId setting covered in Section 6.

My hope is that this gives someone a starting point. Not a prescription. The standard I use reflects my environment and the use cases I have built against. Your org will have different pillars, different workloads, different constraints. The value is not copying the convention. The value is having one, documenting it, and building scripts that enforce it so the standard outlasts the person who created it.