Category: Directory Services
Nested Group
Also known as: Group Nesting
Simply put
A nested group is a group that contains one or more other groups as members, rather than only individual users. Through this structure, members of an inner group typically inherit the access granted to the outer group, allowing permissions to flow across multiple layers of group membership.
Formal definition
A nested group is a group entry that references one or more other group entries as members, such that membership, and any permissions associated with it, is resolved transitively across the nesting hierarchy. In directory implementations, the referenced members may themselves be static, dynamic, or further nested groups; for example, IBM directory products define a nested group via a dedicated object class (such as ibm-nestedGroup) that extends a structural group entry to reference child groups. Because access is inherited through multiple layers of membership, deep nesting can make it harder to determine effective access, who is granted what and why, which is why some vendors and practitioners recommend limiting nesting depth. The behavior of inherited membership, supported nesting depth, and how effective access is evaluated varies by directory platform and configuration.
Why it matters
Nested groups let organizations model access structures that mirror how real organizations are shaped, teams within departments, departments within divisions, without re-assigning permissions to every individual. Because members of an inner group typically inherit the access granted to the outer group, nesting can dramatically reduce administrative overhead and keep group membership aligned with organizational reality. This makes it a common building block in RBAC-style deployments built on directory groups.
The same inheritance that makes nesting convenient also makes it a governance risk. As access flows across multiple layers of membership, it becomes progressively harder to answer the core governance question of effective access: who is granted what, and why. Deeply nested structures can obscure how a user ended up with a particular permission, which complicates access reviews, certification, and segregation-of-duties analysis. Practitioners commonly advise keeping nesting to a minimum precisely because tracking who is getting access, and the reason for it, grows harder with each additional layer.
Who it's relevant to
Directory and system administrators
Administrators use nested groups to organize access along organizational lines and reduce the effort of managing permissions user-by-user. They also bear responsibility for keeping nesting depth manageable, since overly deep hierarchies make it harder to trace how membership and permissions flow.
Identity governance leads
For those running access reviews, certification, and segregation-of-duties analysis, nested groups directly affect the ability to determine effective access. Transitive inheritance across layers can obscure who has access and why, which is the central concern of nested group governance.
IAM engineers and security architects
Engineers designing group-based access models must account for how a given directory platform resolves nested membership and evaluates effective access, since inheritance behavior and supported nesting depth vary by platform and configuration.
Compliance and audit stakeholders
Auditors relying on clear answers to 'who has access to what and why' are affected when deep nesting obscures the path from a user to a permission, making it harder to validate that access aligns with policy.
Inside Nested Group
Parent Group
A group that contains one or more other groups as members, in addition to (or instead of) individual user or service accounts. The parent group's effective membership includes the members of its child groups, depending on directory configuration.
Child (Member) Group
A group that is itself a member of another group. Users who belong to a child group typically inherit any access associated with the parent group through nesting, though the exact resolution behavior varies by directory and application.
Nesting Depth
The number of levels of group-within-group relationships. Many directories and consuming applications impose limits on how deep nesting is traversed, and some do not evaluate nested membership at all unless explicitly configured to do so.
Effective (Transitive) Membership
The full set of principals that resolve to a group after all nested memberships are expanded. This is distinct from direct membership, and whether an application honors transitive membership depends on how it queries the directory or interprets group claims.
Membership Resolution Mechanism
The process by which a directory (for example, an LDAP directory) or a token-issuing service computes and exposes nested membership, such as recursive group expansion or transitive membership attributes. Behavior differs across vendor implementations and profiles.
Group-Based Authorization Mapping
The linkage between a group and the roles, entitlements, or permissions it grants. In access control terms, group nesting is typically an implementation detail of RBAC-style assignment; it determines which principals are treated as holding a role, not what the role is authorized to do.
Common questions
Answers to the questions practitioners most commonly ask about Nested Group.
Does adding a user to a nested group grant them the same access as direct membership in the parent group?
In most deployments, effective membership resolves transitively, so a user in a child group typically inherits the access associated with the parent group. However, this is not universal. Whether nested membership is honored depends on the directory or platform: some systems resolve nested membership only at certain layers, some limit nesting depth, and some evaluate group claims differently in tokens than in directory queries. Because nesting affects authorization outcomes only if the enforcing component (the PDP or the application consuming group claims) actually expands the nesting, you should confirm resolution behavior for each consumer rather than assume equivalence with direct membership.
Are nested groups just an implementation detail that doesn't affect security or governance?
No. Nesting influences who effectively holds access, which is a governance concern, not merely a structural convenience. Because effective membership can be inherited through multiple layers, nesting can obscure the true population with access to a resource, complicate access reviews and certification, and make segregation-of-duties analysis harder if reviewers see only direct membership. Nesting is relevant to both the IGA side (certifying who actually has access) and the runtime side (how group claims are expanded during enforcement), so it warrants explicit attention in both.
How should nested group membership be represented when it feeds into token claims?
This depends on configuration and the token profile. Some identity providers flatten transitive membership into the group claim so the consuming application sees all effective groups, while others emit only direct memberships and expect the application to resolve nesting itself. Because group claims can also be omitted or truncated when membership lists grow large, teams should verify how their provider populates group or role claims, whether nesting is expanded, and whether the resulting claim set is complete for the consumers relying on it. Signing a token containing these claims does not guarantee the nesting was resolved correctly upstream.
What should access reviews account for when nested groups are in use?
Reviews should reflect effective membership, meaning the full transitive population that inherits access through nesting, not only direct assignments. If a certification campaign shows only direct members of a group, reviewers may approve or attest to access without seeing users who gained it through a child group. Depending on the IGA tooling, you may need to enable transitive membership resolution, generate expanded membership reports, or document the nesting hierarchy so certifiers understand the inheritance paths they are attesting to.
What are practical limits to consider when nesting groups in a directory such as LDAP or another platform?
Common considerations include maximum nesting depth, performance of transitive membership resolution at query or authentication time, and the risk of circular references where groups reference each other. Behavior varies by product: some directories support arbitrary nesting but resolve it lazily, some cap depth, and some do not fully support nesting for certain group types. Because deep or complex nesting can increase resolution latency and complicate troubleshooting, many teams keep hierarchies shallow and documented, and validate that their directory and each consuming application handle the chosen depth consistently.
How can you troubleshoot when a user appears to be missing access despite nested group membership?
Start by determining whether the enforcing component resolves nesting at all, since a user may be a valid transitive member while the consuming application only reads direct membership or a truncated group claim. Check the directory's effective or transitive membership for the user, compare it against the membership the application or PDP actually receives (for example in a token claim), and look for nesting depth limits, unsupported group types, or filtering that excludes certain groups. Because behavior differs across directories, providers, and applications, isolate which layer drops the nested membership rather than assuming the directory and the enforcement point agree.
Common misconceptions
Every application and directory automatically resolves nested group membership the same way.
Support for nested membership varies significantly. Some directories expand nesting transitively, some limit nesting depth, and some consuming applications only evaluate direct membership. Whether nested membership is honored depends on the specific product, profile, and configuration.
Nested groups appear identically in tokens as they do in the directory.
How nested membership surfaces in a token (for example, in group claims within a JWT-based ID token or access token) depends on the issuer's configuration. An issuer may include only direct groups, only transitive groups, or omit groups entirely, and claim size limits can truncate large membership sets.
Adding a group inside another group is purely an administrative convenience with no security impact.
Nesting affects effective access and can obscure who ultimately holds an entitlement. Deep or circular nesting can make access reviews, certifications, and segregation-of-duties analysis harder, which are governance (IGA) concerns distinct from runtime enforcement.
Best practices
Confirm whether each consuming directory and application evaluates transitive (nested) membership or only direct membership before relying on nesting to grant access, since behavior varies by product and configuration.
Limit nesting depth to a level your directories and applications reliably resolve, and check any vendor-imposed depth limits rather than assuming unlimited recursion.
Prevent and detect circular group references, which can cause inconsistent or failed membership resolution depending on the implementation.
During access certifications and reviews, expand groups to their effective membership so reviewers see the actual principals granted access rather than only direct members, supporting accurate segregation-of-duties analysis.
Validate how nested membership is represented in issued tokens, accounting for whether the issuer emits direct or transitive group claims and for any claim size or truncation limits.
Document the intended authorization mapping for each group so that nesting relationships remain auditable and their impact on effective access stays transparent.
