What this does
Analyzes a list of Active Directory group nesting relationships — one group being a member of another — entirely in your browser. It detects circular membership (a group indirectly nested inside itself, which AD doesn't resolve reliably), and, given a specific user's direct group memberships, computes their full effective membership by following nesting transitively, flagging both excessively deep chains and a large enough effective group count to risk Kerberos "token bloat."
Why effective membership isn't what the group list shows
A user's directly-assigned groups are only the starting point — AD group membership is transitive, so being a member of one group that's itself nested inside several others means effectively belonging to all of them for permission-checking purposes. This is exactly why "what can this user access" can't always be answered by reading their direct group list; it requires following every nesting chain to its end, which is precisely what tends to go unnoticed when a group is nested three or four levels deep by different administrators over time.
FAQ
Can Active Directory actually contain a circular group membership?
AD's own tools try to prevent creating one directly, but circular nesting still happens in practice — through replication timing, scripted bulk changes, or a chain built up gradually by different administrators who each only see one link at a time and never notice the loop closes. Once it exists, membership evaluation along that chain becomes unreliable rather than cleanly erroring out.
What exactly is Kerberos "token bloat"?
Every group a user belongs to (directly or through nesting) adds that group's SID to the PAC (Privilege Attribute Certificate) embedded in their Kerberos ticket. Windows historically capped the ticket buffer size (MaxTokenSize) at 12,000 bytes — enough for roughly 120 group memberships — and a user beyond that threshold can experience intermittent, hard-to-diagnose authentication failures depending on which services check the token size strictly.
Is deep nesting itself a security problem, or just an auditing inconvenience?
Mostly the latter — deeply nested groups aren't inherently insecure, but they make it genuinely hard to answer "what can this user actually access" by inspection, since the answer requires walking several levels of indirection rather than reading one group's membership list. That difficulty is exactly what lets excessive access quietly accumulate and go unnoticed.
Does this tool query a real Active Directory environment?
No — it analyzes whatever group relationships you type or paste in, entirely in your browser. Nothing is queried, connected to, or sent anywhere; it's meant for reasoning through membership on paper or verifying an export before making changes.
How is "depth" measured?
Depth counts nesting hops from a user's direct group membership to the furthest group reached transitively — a user directly in Sales, where Sales is a member of AllStaff, and AllStaff is a member of Everyone, has a depth of 2 for Everyone (two hops away from the direct membership).
Try it yourself
Decoding a specific group or user's SID instead of tracing its nesting? SID Decoder breaks down the identifier itself.