FFoundationalActive Directory
Active Directory Groups and Scoping
Active Directory groups come in two types and three scopes, and the scope you pick determines what a group can contain, where it can be nested, and how far its permissions reach. This lesson explains why scoping is not a technicality but the mechanism that decides how access and nested membership actually propagate.
This lesson builds on
Why it matters
Group scope decides whether a permission grant is contained to one domain or reaches across an entire forest. Misjudging scope is one of the most common ways nested access goes unnoticed, both by administrators granting it and by defenders trying to trace it back. If you cannot explain why a global group behaves differently from a universal group, you cannot reliably reason about who actually has access to a resource, and you cannot explain a privilege-escalation path that depends on nested group membership.
This matters just as much on the defensive side as the offensive one. Tools like BloodHound render group relationships as a graph precisely because scoping rules determine which paths are even possible. Understanding scoping before you look at that graph is what turns a wall of nodes and edges into a story you can tell someone.
Key Concepts
- Security group — a group type that can be added to an ACL to grant or deny access to a resource; the group type most relevant to both administration and attack paths
- Distribution group — a group type used only for email distribution lists; it cannot appear in an ACL and grants no access, so it is not a security-relevant object
- Domain local scope — can contain members from any domain in the forest (or a trusted forest) but can only be granted permissions within its own domain; the narrowest scope for granting access
- Global scope — can only contain members from its own domain but can be granted permissions in any domain that trusts it; the typical scope for organizing users by role
- Universal scope — can contain members from any domain in the forest and can be granted permissions anywhere in the forest; membership is replicated to the global catalog, unlike the other two scopes
- Nesting rules — each scope has fixed rules for what it can contain and where it can be nested; global groups cannot cross domain boundaries, domain local groups cannot be nested into global groups, and universal groups bridge both
Theory
Core idea
Every Active Directory group has two independent properties: a type, which determines whether the group can be used to grant access at all, and a scope, which determines where the group can be used and what it can contain.
The type is a binary choice. Security groups can be placed on an access control list and used to grant or deny permissions to a resource; they can also, incidentally, be used for email like a distribution list. Distribution groups exist only for email distribution and carry no security identifier that resolves into access, so they are irrelevant to permissions and to attack paths.
Scope is where the real complexity lives. A security group can be domain local, global, or universal, and that choice constrains two separate things: what kinds of members the group can contain, and which other groups it can itself be nested into. Get the scope wrong and a group either cannot hold the members you intended, or it grants access in a place you did not expect.
Mental model
Think of the three scopes as three concentric zones with different rules for crossing the boundary between them, rather than as three interchangeable flavors of "group."
Domain local groups are the resource-facing layer. They exist to be attached to permissions inside their own domain, and in exchange for that narrow reach, they can accept members from almost anywhere: users, other groups, even foreign security principals from a trusted external domain. Think of a domain local group as a door badge that only opens doors in one building, but that building will issue a badge to a visitor from any other company.
Global groups are the organizational layer. They gather users who share a role, like "Finance Analysts" or "Domain Admins," and that gathering only happens within one domain; a global group cannot contain members from a different domain. But once assembled, a global group's badge can be shown at doors in any domain that trusts it, because it is small, well-defined, and cheap to reference elsewhere.
Universal groups are the forest-wide layer. They can gather members from any domain in the forest and can be granted access anywhere in the forest, which is exactly why their membership, unlike the other two scopes, gets replicated out to the global catalog: every domain controller with a global catalog copy needs to know who is in a universal group, because that group might grant access locally. The nesting rules follow directly from this shape: domain local groups cannot be nested into global groups, because a resource-facing group has no business becoming a member of an organizational one, while universal groups sit in the middle and can flow into domain local groups on one side and be built from global groups on the other.
Common misunderstandings
- Assuming any group can be nested inside any other group. Domain local groups cannot be nested into global or universal groups, global groups cannot contain members from a different domain, and only universal groups can freely bridge across domains in both directions. The scope chosen at creation time locks in these constraints for the life of the group.
- Treating global catalog replication as a performance detail. It has real security consequences. Because only universal group membership replicates to the global catalog, a query against the global catalog shows universal group members instantly but misses domain local and global group members entirely, which have to be queried domain by domain. Incomplete queries produce incomplete pictures of who has access.
- Confusing distribution groups with security groups. They are structurally different objects for access purposes. A distribution group cannot appear on an ACL, so it grants no access no matter how it is nested; only security groups matter when reasoning about who can reach a resource.
- Treating group scoping as a purely administrative concern. Scoping rules directly determine which nested-membership paths are even mechanically possible, which is exactly the kind of constraint that graph-based mapping tools rely on. A path that looks plausible on paper can turn out to be invalid once the scoping rules that govern it are checked.
Real-world context
Real environments accumulate group nesting over years, often without anyone tracking the cumulative effect. A user gets added to a global group for their team, that global group gets nested into a universal group for a business unit, and that universal group gets nested into a domain local group that has write access to a sensitive file share. No single addition looks risky in isolation, but the chain grants access that nobody explicitly reviewed.
This is also where cross-domain and cross-forest reasoning becomes concrete. A user from one domain can never land directly in a global group in another domain, so if you see a user with access that seems to originate in a foreign domain, the path almost certainly runs through a universal group or a domain local group accepting a foreign security principal. Recognizing which scope makes a given path possible lets you predict, before you even query anything, what kind of group must be sitting at each hop.
When you are explaining a finding, the scope of the groups involved is often the detail that makes the risk concrete. Saying "this service account is nested three groups deep into Domain Admins" is vague; being able to say which of those groups is universal, and therefore visible and reachable forest-wide, tells the stakeholder exactly how far the blast radius extends.
Communication
Interview answer
Active Directory groups have two independent properties: type and scope. Security groups can be placed on an ACL to grant access, while distribution groups exist only for email and grant no access at all. Scope then determines where a security group can be used and what it can hold: domain local groups can contain members from anywhere but only grant access within their own domain, global groups can only contain members from their own domain but can be used to grant access anywhere that trusts it, and universal groups can do both, containing and granting access across the whole forest.
The nesting rules follow from that design. A global group cannot contain users from a different domain, and a domain local group cannot be nested into a global or universal group, because that would let a narrowly-scoped access grant leak into a broadly-reachable container. Universal groups are the one scope whose membership replicates to the global catalog, which is also why they are the fastest scope to enumerate across an entire forest and often the most interesting one when tracing a cross-domain privilege path.
Follow-up questions
- Why can a domain local group not be nested inside a global group, but a global group can be nested inside a domain local group?
- If you needed a group that could be granted access to resources in every domain in a forest, which scope would you choose, and why?
- Why does only universal group membership replicate to the global catalog, and what does that mean for how quickly you can enumerate it?
- How would a foreign security principal from a trusted external domain end up with access to a resource, given that it cannot join a global group?
- What risk does deep, unreviewed group nesting create, even when every individual group addition looked reasonable at the time?
