Groups are how most access is actually granted, and in most directories nobody can say who owns half of them, why they exist, or what a member of a nested group can really reach. Active Directory estates accumulate thousands of security groups over decades; Microsoft Entra ID and Microsoft 365 add self-service groups, Teams and dynamic membership rules on top. The result is access that is invisible to reviews, groups that outlive their purpose, and nesting chains that hand privilege to people nobody intended. This guide covers group ownership, expiry and lifecycle, the specific risks of dynamic groups, how nesting works in AD and Entra ID, how to calculate effective access through nesting, and a safe clean-up method. It is for directory engineers, IAM and IGA teams. User access certification itself is covered in the Access Reviews Guide; this page focuses on the group layer underneath.
Key takeaways
- Every group needs an owner and a reason. A group without a named owner and a purpose cannot be reviewed, renewed or safely deleted, and becomes permanent by default.
- Nesting hides access. Reviewing direct members of a group misses everyone who holds it through a chain; effective access must be calculated transitively, for example with LDAP_MATCHING_RULE_IN_CHAIN in AD or transitive membership queries in Entra ID.
- Entra ID nesting is deliberately limited. Nested security groups do not inherit app assignments or licences from the parent, cannot be nested into role-assignable groups, and Microsoft 365 groups cannot be nested at all, so AD habits do not transfer.
- Dynamic groups are only as safe as their attributes. Microsoft warns that if users can write an attribute used in a rule, including through self-write in on-premises AD, they can add themselves to the group and to whatever it grants.
- Expire, then delete, in stages. Use the Microsoft 365 group expiration policy and its 30-day restore window, and for security groups remove access in reversible steps rather than deleting on day one.
Why group sprawl is a security problem
Group sprawl is not just clutter. Each unowned or misunderstood group is an unreviewed access path.
- Invisible privilege: a help desk group nested into a server admin group, or a project group nested into a group that controls a finance share, grants access that never appears on a review of the person.
- Attack paths: attackers enumerate cloud and domain groups (ATT&CK T1069.003 Cloud Groups and T1069.002 Domain Groups) precisely to find nesting that leads to administrative rights, and adding an account to a privileged group is a classic persistence move under T1098 Account Manipulation.
- Review fatigue: certification campaigns over thousands of groups with no descriptions produce rubber-stamp approvals.
- Operational fragility: nobody dares delete a group because nobody knows what depends on it, so the count only grows.
- Token and performance limits: in AD, users in very large numbers of groups (including through nesting) carry large Kerberos tokens, which can cause authentication failures and is a practical sign of runaway nesting.
How nesting works in Active Directory and Entra ID
The two directories handle nesting very differently, and hybrid estates have both.
| Aspect | Active Directory | Microsoft Entra ID |
|---|---|---|
| Group scopes and types | Security and distribution types; Universal, Global and Domain Local scopes, plus Builtin Local | Security groups and Microsoft 365 groups; assigned or dynamic membership |
| What can nest | Global groups hold accounts and Global groups from the same domain; Universal groups hold accounts, Global and Universal groups from the forest; Domain Local groups hold almost anything, and permissions granted to them apply only within their domain | Security groups can contain security groups; Microsoft 365 groups cannot contain or be contained by other groups |
| Does access inherit through nesting | Yes: membership is transitive for permissions in access control lists and user rights | For membership and Conditional Access scopes, yes; for apps and shared resources assigned to the parent, and for group-based licensing, no |
| Privileged groups | Protected groups (Administrators, Account Operators, Backup Operators, Domain Admins and others) are governed by AdminSDHolder | Role-assignable groups cannot contain other groups and must use assigned membership |
| Synced groups | Source of truth | Groups synchronised from on-premises AD are managed on-premises and are not supported for Entra-side nesting |
The common AD design pattern places accounts in Global "role" groups, nests those in Domain Local "resource" groups, and grants permissions only to the resource groups (often called AGDLP). It is a sound pattern when kept to two levels. Problems arise when groups are nested arbitrarily, permissions are granted to role groups directly, or circular nesting creeps in. For the privileged side, see the AdminSDHolder, SDProp and Protected Groups Guide and the Active Directory ACL and Delegation Hygiene Guide.
Calculating effective access through nesting
Effective access is the full set of groups a principal belongs to, directly or through any chain, and therefore everything those groups grant. Calculate it before any review or clean-up.
Methods by platform
- Active Directory, transitive LDAP: the matching rule OID 1.2.840.113556.1.4.1941 (LDAP_MATCHING_RULE_IN_CHAIN) walks the whole ancestry chain in one query. A filter on memberOf with this rule against a user tells you whether they are in a group at any depth; a filter on member against the groups container lists every group a user holds. Microsoft notes that high fan-out subtree queries can be processor-intensive, so run them off-peak or against a replica.
- Entra ID, transitive membership: Microsoft Graph exposes transitive membership for users and groups (transitiveMemberOf and transitiveMembers), which resolves nesting for you. Remember that transitive membership in Entra ID does not mean transitive app or licence assignment.
- Graph analysis: for large AD estates, attack path tools build a graph of groups, ACLs and sessions and show which nesting chains lead to Tier 0. Use them defensively to find the chains to cut.
- IGA platforms: most compute effective entitlements through nesting and can show reviewers the path ("member of Helpdesk, which is a member of Server Admins"). Make sure reviews show effective access, not just direct membership.
Nesting metrics to report
| Measure | Why it matters | Suggested threshold |
|---|---|---|
| Maximum nesting depth per group | Deep chains are hard to reason about and to review | Investigate anything deeper than two or three levels |
| Circular nesting | Group A in B in A: always a design error, confuses tooling | Zero |
| Groups nested into protected or privileged groups | Silent route to Tier 0 | Zero without a documented exception |
| Effective versus direct member ratio | A group with 5 direct but 3,000 effective members is a review blind spot | Flag ratios above 10 to 1 on sensitive groups |
| Groups per user (effective) | Token size and over-provisioning indicator | Review outliers against peers |
Group ownership and lifecycle
Ownership is what turns a group into something governable. In Entra ID, owners can manage membership of groups they own; adding or removing members and owners centrally needs the Groups Administrator or User Administrator role.
- At creation: require at least two owners (a person and a deputy), a description of purpose, a data or access classification, and for security groups the resources it grants. Restrict who can create Microsoft 365 groups and security groups in Entra ID to stop uncontrolled growth.
- Naming: a naming convention that encodes type and purpose (for example role versus resource, environment, owning team) makes nesting reviews much faster. Microsoft 365 group naming policies can enforce prefixes and suffixes.
- Owner changes: link group ownership to the joiner-mover-leaver process so a leaving owner triggers reassignment. See the Joiner-Mover-Leaver Guide.
- Ownerless groups: report them weekly; for Microsoft 365 groups, the expiration policy sends renewal notices for ownerless groups to an alternate email address you configure.
- Owner reviews: have owners confirm membership and nested groups on a cadence driven by what the group grants, using access reviews in your IGA or Entra ID Governance.
Microsoft 365 group expiration
Entra ID supports one expiration policy per organisation for Microsoft 365 groups. Its documented behaviour:
- Lifetime: a preset or a custom number of days, minimum 30.
- Auto-renewal: groups with recent activity (for example SharePoint file activity, Outlook group messages, visiting a Teams channel, Viva Engage posts) renew automatically about 35 days before expiry without notifying owners.
- Notifications: otherwise, owners are emailed 30, 15 and 1 day before expiry.
- Deletion and restore: an expired group is deleted one day after expiry and can be restored by owners or admins within 30 days, a window that cannot be changed.
- Scope and licensing: All, Selected (up to 500 groups) or None; members of covered groups need Microsoft Entra ID P1 or P2 licences in the tenant.
The expiration policy does not cover security groups. For those, use access reviews with "remove access" outcomes, or your IGA platform's group lifecycle features, and record an intended end date at creation for project groups.
Dynamic group risks
Dynamic membership groups add and remove members based on attribute rules, which removes manual work and reduces leaver risk. They also move the control point from the group to the attribute.
| Risk | Example | Control |
|---|---|---|
| Self-writable attributes | A rule on an on-premises attribute that has SELF write lets a user change their own value and join the group | Audit write permissions on every rule attribute in Entra ID and on-premises; prefer attributes users cannot edit |
| Broad or loose rules | user.department -contains "Fin" also matches "Final Assembly" | Prefer -eq or -in over -contains and -match; test the rule against current users before saving |
| HR data quality | A wrong department code from HR grants finance access | Validate source attributes; alert on sudden membership jumps |
| Guests and non-employees | A rule on country or company that also matches guest accounts | Add (user.userType -eq "Member") or equivalent clauses where guests must be excluded |
| Delayed removal | Membership updates after an attribute change are processed asynchronously | Do not rely on dynamic removal as the only leaver control for sensitive access |
| Privileged use | Wanting a dynamic group for an admin role | Not possible in Entra ID: role-assignable groups must use assigned membership; use PIM eligibility instead |
Other documented limits worth knowing: a tenant can hold up to 15,000 dynamic membership groups, a rule body cannot exceed 3,072 characters, members cannot be added or removed manually, every unique user in a dynamic group needs a Microsoft Entra ID P1 licence in the tenant (device groups need none), and user.memberOf and device.memberOf rules are in preview and should be used with caution. Microsoft's own wording is that groups controlling sensitive apps, resources or Conditional Access policies are only as secure as the write controls on their rule attributes.
A safe clean-up method
Deleting groups is irreversible for security groups in AD unless the AD Recycle Bin is enabled, and deletion of a group used in an access control list breaks access silently. Remove in stages.
- Inventory: export every group with type, scope, owner, description, creation date, direct and effective member counts, nesting parents and children, and last modification date.
- Find usage: map where each group is referenced: file and share ACLs, application role assignments, Conditional Access, licensing, GPO security filtering, SharePoint and Teams. Unreferenced groups with no owner are the first candidates.
- Classify: empty groups, groups with no owner, groups with no reference, duplicate groups (same members), circular nesting, and groups nested into privileged groups.
- Fix privilege first: remove nesting into protected and admin groups, then circular nesting, under change control.
- Contact owners or managers of remaining candidates with a deadline and a default outcome.
- Soft retire: rename with a retirement prefix, remove members or remove the group from its parent, and record the previous state so it can be restored. Wait one review cycle (for example 30 to 60 days) and watch for access failures.
- Delete: after the quiet period, delete, keeping the export. For Microsoft 365 groups the 30-day restore window applies.
- Prevent regrowth: creation controls, ownership requirements, expiry and recurring owner reviews.
Small organisations can do this in a spreadsheet and a few PowerShell exports in weeks. Large enterprises should run it as a programme by business unit, starting with groups that reach Tier 0 or regulated data.
Detection and monitoring
- AD group changes: Windows Security events 4728 (member added to a security-enabled global group), 4732 (local group) and 4756 (universal group), with alerts on any change to protected groups. See the Active Directory Security Monitoring and Event IDs Guide.
- Entra ID audit log: "Add member to group", "Add owner to group" and changes to dynamic membership rules, with particular attention to role-assignable groups and groups used in Conditional Access. See the Entra ID Sign-In and Audit Log Detection Guide.
- Nesting drift: a daily diff of nesting relationships for sensitive groups; any new parent-child link into a privileged group should alert.
- Dynamic membership jumps: alert when a dynamic group's member count changes by more than a set percentage in a day.
Metrics
- Percentage of groups with at least two valid owners and a description.
- Number of ownerless, empty and unreferenced groups, trending down.
- Count of groups nested into privileged groups without an exception (target zero).
- Number of dynamic group rules using self-writable or loosely matched attributes.
- Groups retired per quarter versus groups created.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-2 Account Management | Requires approvals for group and role membership and specifying group membership for authorised users |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege; AC-6(7) Review of User Privileges; AC-2(7) Privileged User Accounts | Effective access reviews and monitoring of privileged role assignments |
| NIST CSF 2.0 | PR.AA-05 | Access permissions and entitlements managed and reviewed |
| MITRE ATT&CK | T1069.002 Domain Groups; T1069.003 Cloud Groups; T1098 Account Manipulation | Group discovery and privileged group changes as attacker techniques |
| CIS Controls v8.1 | Control 5 Account Management; Control 6 Access Control Management | Account and access inventories and revocation |
| ISO/IEC 27001:2022 | A.5.15 Access control; A.5.18 Access rights | Provisioning, review and removal of access rights |
Common failure patterns
- Reviewing direct members only: campaigns that show a group's direct members miss everyone who holds it through nesting.
- Help desk or project groups nested into admin groups: a convenience shortcut years ago becomes a standing route to domain or tenant control.
- Assuming Entra ID behaves like AD: teams nest a group under an app-assigned parent and expect access, or assume nested users are licensed, then build workarounds that grant more than intended.
- Dynamic rules on editable attributes: a rule keyed on a self-writable or loosely governed attribute lets users join sensitive groups.
- Delete first, ask later: clean-ups that delete unreferenced-looking groups break access controlled by ACLs nobody inventoried.
- No owner at creation: self-service groups created without a second owner become ownerless the day the creator leaves.
Practitioner checklist
- Export every group with owners, description, member counts (direct and effective), nesting and references.
- Remove nesting into protected and privileged groups and fix circular nesting first.
- Calculate effective access with transitive queries and show nesting paths in access reviews.
- Require two owners, a description and a classification at group creation, and restrict who can create groups.
- Enable the Microsoft 365 group expiration policy with an alternate email for ownerless groups.
- Audit write permissions on every attribute used in a dynamic membership rule and replace self-writable attributes.
- Exclude guests explicitly from dynamic rules where they must not match.
- Retire groups in stages: rename, remove members, wait a cycle, then delete with an export kept.
- Alert on changes to privileged group membership and new nesting into sensitive groups.
- Report ownerless, empty and unreferenced group counts monthly.
Standards and references
- Microsoft Learn: Active Directory security groups
- Microsoft Learn: Search filter syntax (LDAP_MATCHING_RULE_IN_CHAIN)
- Microsoft Learn: Manage Microsoft Entra groups and group membership
- Microsoft Learn: Dynamic membership rules for groups in Microsoft Entra ID
- Microsoft Learn: Configure the expiration policy for Microsoft 365 groups
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
- MITRE ATT&CK: Permission Groups Discovery: Cloud Groups (T1069.003)
Related NHI Mgmt Group resources: Access Reviews Guide · AdminSDHolder, SDProp and Protected Groups Guide · Entitlement Catalogue Guide · Role Mining and Role Design Guide · Orphaned and Dormant Accounts