Active Directory Group Nesting Explained

A user's actual access in Active Directory is almost never determined by their direct group memberships alone — groups can be members of other groups, and permissions granted to any group in that chain apply transitively to everyone nested inside it, however many levels deep. This is deliberate, well-established design (formalized as the AGDLP pattern), not an accident of how AD happens to work. This post covers why nesting exists, the standard pattern for using it well, and the two concrete failure modes — circular membership and token bloat — that show up when it's used carelessly.

Why nest groups at all instead of assigning permissions directly

Assigning a resource permission to each individual user who needs it works fine for three people and becomes completely unmanageable at fifty — every personnel change requires touching the resource's own permissions again. Groups exist to break that coupling: grant the permission to a group once, then manage membership in that group instead, and access changes never require touching the resource again. Nesting extends the same idea one level further: a group representing "can access the Finance share" can be composed from other groups representing organizational reality ("Finance Team," "Finance Contractors") rather than needing every individual person added to it directly.

AGDLP: the standard pattern

Account → Global group → Domain Local group → Permission
   (user)      (organizational           (resource-specific)
                  role)

Accounts go into Global groups that represent organizational structure (a department, a role) — Global groups can contain accounts from their own domain and can be nested in groups elsewhere in the forest, but can't contain accounts from other domains directly. Global groups then become members of Domain Local groups, which are what actually get the resource permission — Domain Local groups can accept members from any trusted domain, which is exactly the flexibility needed at the point where a permission actually gets granted. In a multi-domain forest, a Universal group layer is often inserted between Global and Domain Local specifically to let a group meaningfully span domains (AGUDLP). The underlying principle either way: accounts go into groups organized by who someone is; those groups nest into groups organized by what they can access.

Effective membership: following the chain to its end

A user's effective group membership is the full transitive closure — every group reachable by following "is a member of" links from their direct memberships, however many hops that takes. A user directly in "Finance Team," where "Finance Team" is nested inside "All Employees," is effectively a member of both, for every permission check Windows performs. This is exactly why reading a user's direct group list in Active Directory Users and Computers doesn't fully answer "what can this user access" — the real answer requires walking the chain to wherever it actually ends.

Failure mode one: circular membership

Nothing about AD's data model inherently prevents group A from ending up nested inside group B, which is nested inside group C, which is nested back inside group A — the standard tools block the most obvious direct case (adding a group as a member of itself), but an indirect cycle assembled gradually across several separate changes, especially by different administrators who each only see one link in isolation, isn't reliably caught. Once it exists, membership evaluation along that chain becomes genuinely unreliable rather than cleanly erroring out — not a crash, just an inconsistency that makes the group's actual effective membership hard to reason about.

Failure mode two: Kerberos token bloat

Every group in a user's effective membership — direct or nested, at any depth — adds that group's SID to the PAC (Privilege Attribute Certificate) embedded in their Kerberos ticket. Windows historically capped that ticket buffer at 12,000 bytes (MaxTokenSize), enough for roughly 120 group memberships; a user beyond that threshold can experience intermittent, genuinely confusing authentication failures that depend on which specific service is strict about checking token size. Later Windows versions raised the default, but plenty of environments still run with the older, lower ceiling, either by explicit configuration or because it was never revisited.

Common mistakes

• Assigning resource permissions directly to individual accounts. Works briefly, breaks down at any real scale — exactly what AGDLP's indirection exists to avoid.
• Building a cycle gradually across unrelated changes. No single change looks wrong in isolation; the problem only exists once the loop closes.
• Nesting a user into dozens of groups without checking effective count. Token bloat is a real, sporadic-looking failure mode, not a theoretical concern.
• Never reviewing nested membership after it's set up. Access granted through a chain of groups is exactly the kind of thing that quietly outlives whatever originally justified it.

Checking effective membership directly, rather than by hand

# Locally, for the current session
whoami /groups

# For a specific AD account (requires the ActiveDirectory PowerShell module)
Get-ADUser jsmith -Properties memberOf | Select -ExpandProperty memberOf

whoami /groups shows the fully resolved group list actually embedded in the current logon session's token — the real, already-flattened answer, rather than something to reconstruct manually by tracing nesting chains. Get-ADUser with -Properties memberOf, by contrast, only returns direct membership; getting the full transitive closure from PowerShell requires either recursively querying each returned group's own memberOf, or using Get-ADGroupMember with the -Recursive switch from the other direction (starting at a group, walking down to every member it contains, directly or nested). The distinction matters: reading memberOf once is not the same question as "what can this account actually do," and conflating the two is an easy way to under-audit real effective access.

FAQ

Try it yourself

AD Security Group Nesting Analyzer detects circular membership and computes a user's full effective membership, flagging token bloat and excessive depth, entirely in your browser.