Session 4Tier 1 · Competent Admin~55 min

Groups and group scopes

The two group types and the three scopes — what each can contain, where each can grant access, the nesting rules that connect them, and the misconceptions that trip everyone up.

Goal

In Session 3 you learned what a group is not — an OU. This session is the payoff: what a group actually does. By the end you'll know the two group types (Security vs Distribution) and the three group scopes (Domain Local, Global, Universal), the rules for what each scope can contain and where each can grant access, and the nesting directions that connect them. Scope is not a cosmetic dropdown — AD enforces these rules and will refuse memberships that break them. You'll build and nest groups the correct way, then deliberately trigger the errors so the rules stick by feel. Still Tier 1: you're learning to wield groups correctly, not designing enterprise permissions yet.

Concepts

Group type: Security vs Distribution

Every group has a type, chosen at creation:

Security — a real security principal. It has a SID, so it can appear on an ACL and be granted permissions to resources (files, shares, printers, rights). This is what you use for access control, and it's the vast majority of admin work. A Security group can also be emailed like a distribution list, so it covers both jobs.
Distribution — an email list only. It has no SID and can never grant access to anything. It exists purely for mail-enabled applications (e.g. Exchange) to address a set of people.

The one-line rule: if the group needs to control access, it must be a Security group. Distribution groups are for mail and nothing else.

Group scope: what it can hold, where it can be used

Independent of type, every group has a scope. Scope answers two separate questions: which members may this group contain? and where may this group be used to grant access? On a single-domain lab like lab.local the distinctions feel subtle, but they are strictly enforced, and they're the whole reason the AGDLP pattern below works.

Scope	Can contain (single domain)	Can grant access
Global	Users, computers, and other Global groups from its own domain	In any domain in the forest
Domain Local	Users, computers, Global groups, Universal groups (from any domain), and other Domain Local groups from its own domain	Only in its own domain
Universal	Users, Global groups, and other Universal groups from any domain	In any domain in the forest

The shorthand that captures the everyday intent: Global groups gather members (put your people in here, organized by role), Domain Local groups gate resources (attach these to the thing being protected), and Universal groups span domains (a forest-wide bridge you reach for only in multi-domain designs).

Nesting: which scope goes inside which

The crux — and exactly what the lab probes by breaking it. Because each scope restricts its allowed members, only certain nesting directions are legal. The ones you'll actually use:

A Global group can be a member of a Domain Local group. ✅ (This is the important one — it's the AGDLP hinge.)
A Global group can be a member of another Global group (same domain). ✅
A Global or Universal group can be a member of a Universal group. ✅

And the direction AD will reject:

A Domain Local group cannot be a member of a Global group. ❌ (A Global group refuses Domain Local members outright — you'll see this error in the lab.)

Read it as a one-way flow: membership travels Global → Domain Local, never the reverse.

The canonical pattern: AGDLP (kept light)

The scopes exist to support one standard shape, AGDLP:

Accounts → Global group → Domain Local group → Permission.

You put user Accounts into a Global role group ("who they are"), nest that Global group into a Domain Local resource group ("what's being protected"), and grant the Permission to the Domain Local group. Change a person's access by moving them between Global groups; change what a resource allows by editing the Domain Local group's permission. That separation is why the nesting direction is one-way.

Rendering diagram…

AGDLP: accounts go into a Global role group, which nests into a Domain Local resource group, which is granted the permission.

Keep this light for now — you're just learning the shape so the scope rules make sense. The full delegation-and-permissions design (why AGDLP scales, how to apply it to real shares and OUs) is Tier 2, Session 13.

Watch out

Scope and type are not cosmetic — AD enforces them. Two classic traps to avoid:

Distribution ≠ access. Drop users into a Distribution group and expect them to reach a file share, and they never will — a Distribution group has no SID and cannot appear on an ACL. If access is the goal, it must be a Security group.
Random scope bites back. Pick a scope without thinking and you'll eventually hand AD an invalid membership — e.g. trying to nest a Domain Local group inside a Global one — and it will flatly refuse with an error. The rules above aren't guidelines; they're constraints the directory checks on every change. The lab has you hit these on purpose so the boundaries become muscle memory.

Note

One cost to file away: a Universal group stores its full membership in the Global Catalog, which replicates forest-wide. That's what lets it span domains, but it also means churn in a Universal group's membership generates forest-wide replication — a reason to prefer Global groups for frequently-changing membership. Don't overthink it on a single-domain lab; the Global Catalog and replication get their proper treatment in Session 9.

Lab

Goal: build Security groups at the right scopes, wire up one correct AGDLP nest, then deliberately break the rules to feel how AD enforces scope. Everything is done in Active Directory Users and Computers; the one PowerShell block at the end is optional. Fake values only — lab.local, the sample users from Session 3, no real credentials.

You'll create groups the same way you created users: right-click a target OU → New → Group. The New Object – Group dialog is where you pick Group scope (Domain local / Global / Universal) and Group type (Security / Distribution) — the two dropdowns this whole session is about. Add members by right-clicking a group → Properties → Members → Add, or by selecting users → right-click → Add to a group….

The deliberate-error steps are the point — don't skip them. When AD rejects a membership, read the exact dialog text and name the rule it just enforced before moving on.

Note

When you try an illegal nest, AD pops a message along the lines of "…is not a valid member of this group because of its type or scope." That single sentence is the rule made visible: the target group's scope won't accept the member you offered. Note which combination you tried and why it's disallowed.

How you know it worked: in ADUC you have two Global Security role groups populated with your Session 3 users, a Domain Local Security group with the Global group nested inside it (the AGDLP direction, accepted without complaint), and a Distribution group you've confirmed can't be used for access. Most importantly, you triggered at least one scope/nesting error on purpose and can say why AD refused it — that's the sign the rules have moved from memorized to understood.

Note

The same thing in PowerShell — optional (we go deep on PowerShell in Session 8). Recognize these, don't master them yet. -GroupScope and -GroupCategory are the cmdlet equivalents of the two dropdowns; Add-ADGroupMember does the nesting:

PowerShell

New-ADGroup -Name "Sales-Staff" -GroupScope Global -GroupCategory Security -Path "OU=Sales,DC=lab,DC=local"
New-ADGroup -Name "Share-Sales-Read" -GroupScope DomainLocal -GroupCategory Security -Path "OU=Sales,DC=lab,DC=local"
Add-ADGroupMember -Identity "Share-Sales-Read" -Members "Sales-Staff"

Lab steps0 / 8 done

In ADUC, right-click an OU → New → Group and create two GLOBAL Security groups representing roles, e.g. Sales-Staff and IT-Staff (Group scope = Global, Group type = Security).
Add your Session 3 users to the matching role group (Sales users → Sales-Staff, IT users → IT-Staff) via the group's Properties → Members → Add.
Create a DOMAIN LOCAL Security group representing access to a resource, e.g. Share-Sales-Read (Group scope = Domain local, Group type = Security).
Nest correctly (AGDLP direction): add the Global group Sales-Staff as a MEMBER of the Domain Local group Share-Sales-Read. Confirm AD accepts it without error.
Break it on purpose: try to add the Domain Local group Share-Sales-Read as a member of the Global group Sales-Staff. Read the exact error and note the rule it revealed (Global cannot contain Domain Local — membership flows Global → Domain Local, not back).
Break it again: try another invalid membership a scope won't accept (e.g. nesting a Domain Local group into another Global group). Read the message and articulate why the scope refused it.
Create a DISTRIBUTION group (Group type = Distribution) and confirm you cannot use it to grant resource access — it has no SID and won't appear where security principals are picked (contrast with your Security groups).
Verify: the Global role groups hold the right users, the Global→Domain Local nest was accepted, the Distribution group can't grant access, and you can state WHY each deliberate error was rejected.