Use Protected Groups for critical OU containment

What “protected groups” means in practice

In AD, the phrase protected groups usually refers to one of three related ideas:

• Built-in high-privilege groups (Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, etc.) that you should treat as Tier 0 power.
• Protected Users (a special security group) designed to reduce credential theft and downgrade attacks for accounts that should never be exposed.
• AdminSDHolder / SDProp protection applied to “protected accounts” (typically accounts that are members—directly or indirectly—of certain privileged groups). This mechanism periodically stamps a hardened ACL onto the object to prevent permission tampering.

For critical OU containment, the big lever is this: if the accounts or groups that can change OU permissions are themselves easy to modify (or their credentials are easy to steal), your OU boundary is imaginary. You need a combination of (1) minimizing who has the power, (2) making those principals hard to tamper with, and (3) preventing their credentials from being reusable on lower-trust systems.

Containment failure modes you’re trying to prevent

Before designing controls, name the ways containment breaks. Most “OU escapes” are not about someone clicking “Move OU.” They’re about changing who can do privileged actions.

1) Group-based escalation that bypasses OU delegation

You delegate “Reset Password” and “Join Computers” on an OU to a helpdesk group. Then someone adds themselves to that helpdesk group (because that group’s ACL is weak or nested in something broad). Containment fails because the OU ACL was correct, but the group’s membership control wasn’t.

2) Abusing nested groups to smuggle privilege

Nested groups are operationally useful—but they also let privilege propagate in non-obvious ways. If a protected or privileged group is nested into something that’s managed by lower-tier admins, you’ve created a privilege “backdoor.”

3) AdminSDHolder stamping breaks your intended OU-based model

A common surprise: you carefully delegate control over an OU containing admin accounts, then you place those accounts into a privileged group. SDProp may periodically reapply AdminSDHolder permissions to those accounts, wiping your OU delegation and replacing it with a hardened (but not necessarily what you intended) ACL. That can either weaken your planned boundary or break your workflows—both are problems.

4) Credential reuse defeats logical boundaries

Even if OU permissions are perfect, if a Tier 0 credential is used on a workstation or server in a lower tier, an attacker can harvest and replay it. The attacker never needs to touch OU ACLs; they just become you.

The mental model: protect the principals that define the boundary

Think of OUs as policy zones and groups as control planes. OUs hold objects; groups decide who can administer those objects. For containment, you don’t only protect the OU ACL—you protect:

• The delegating groups (who is allowed to manage OU objects)
• The privileged accounts (who can change delegation and group membership)
• The endpoints where those credentials are used

“Protected groups” are your way to harden the control plane so lower-trust zones can’t mutate it.

Step 1: Build a tiered OU containment design (so protection has meaning)

Protected groups are most effective when they align with a tier model. A practical baseline:

• Tier 0: domain controllers, identity systems, PKI, ADFS (if present), Azure AD Connect, security tooling, and the accounts/groups that can administer them.
• Tier 1: server administration (member servers, application servers).
• Tier 2: workstations and user support (helpdesk).

Your “critical OUs” are typically Tier 0 OUs: Admins OU, Domain Controllers OU (or custom DC OU), Identity Services OU, Privileged Groups OU. Containment goal: Tier 1/2 admins can’t influence Tier 0—even indirectly via group membership.

Step 2: Treat high-privilege groups as “protected-by-default” and shrink them

Start with the obvious: membership in built-in privileged groups should be minimal, time-bound, and auditable. For OU containment, you want to eliminate “ambient authority.”

• Keep Domain Admins effectively empty day-to-day; use just-in-time elevation (PIM / PAM or well-governed workflows).
• Prefer delegated OU-specific groups over adding people to broad built-in admin groups.
• Avoid adding service accounts to privileged groups; use gMSA where possible and assign rights precisely.

Why this matters: if Domain Admins is bloated, containment is impossible because someone always has a credential that can rewrite OU boundaries and group membership.

Step 3: Use AdminSDHolder/SDProp intentionally (and avoid accidental protection)

AdminSDHolder is often described as “protecting privileged accounts,” but the important nuance for containment is: it protects them from delegated OU ACLs too. That can be good (prevent tampering) or bad (break your design).

Understand the consequence

If an account is considered protected, SDProp will periodically apply the AdminSDHolder security descriptor to it. That means:

• Permissions inherited from the OU may no longer apply the way you expect.
• Attempts to “delegate control” over that account via OU ACL can be overwritten later.
• Attackers also find it harder to add backdoor ACEs to those objects (which is a win).

Design guidance

• Don’t put routine admin accounts into protected groups unless you want them to behave like Tier 0 objects that resist OU-based delegation.
• If you need helpdesk workflows for privileged accounts (you usually shouldn’t), implement a controlled process rather than relying on OU inheritance.
• Regularly review which objects are protected and why—accidental membership in a privileged group can create confusion and break operations.

Step 4: Use the “Protected Users” group for the accounts that anchor Tier 0 containment

The Protected Users group helps reduce credential theft and reuse for sensitive accounts by restricting older/weak authentication methods and preventing certain forms of credential caching.

For OU containment, the rule is simple: if an account can change Tier 0 group membership, change OU ACLs, or administer identity infrastructure, it should be treated as a “can’t be phished once” identity. Protected Users is a strong default, but you must validate compatibility with your environment.

Where it helps containment

• It makes it harder for attackers to take a Tier 0 credential from a lower-tier system and replay it elsewhere.
• It nudges you away from legacy authentication paths that are common downgrade targets.

Operational cautions

Protected Users can break certain legacy flows (older protocols, certain delegation scenarios, service usage). The safe approach is: apply it first to a small set of privileged human accounts, validate critical admin workflows, then expand.

Step 5: Protect the “delegation groups” that own your OU boundaries

This is the part many teams skip: they harden Domain Admins but leave the “OU Admins – Servers” group writable by “IT Support.” That group is the real boundary.

Pattern: OU-specific delegation groups

Create groups like:

• GRP-OU-T0-Identity-Admins
• GRP-OU-T1-Servers-Admins
• GRP-OU-T2-Workstations-Admins

Then delegate OU permissions to these groups. The containment control is not just the delegation—it’s that only Tier 0-administered processes can modify the membership of Tier 0 delegation groups.

How to harden delegation group membership

• Put delegation groups in a dedicated Privileged Groups OU with strict ACLs.
• Ensure only Tier 0 admin roles can modify those groups (members, memberOf, managedBy, etc.).
• Remove “Write all properties” style broad rights; use minimal rights needed for controlled management.
• Avoid nesting Tier 0 delegation groups into groups that are managed by Tier 1/2 admins.

If you do only one thing: lock down who can change membership of the groups that hold OU delegation rights.

Step 6: Stop the classic containment breakers

Disable privilege by “accidental inheritance”

Review your critical OUs for inherited ACEs that grant broad rights to Authenticated Users, Domain Users, or legacy IT groups. Containment is rarely broken by one obvious ACE; it’s broken by three “seems fine” ACEs that add up.

Remove risky default rights where appropriate

Some default behaviors (like who can join machines to the domain, or broad ability to read attributes) may be acceptable in many environments, but for critical OUs you should explicitly define what is allowed rather than relying on defaults.

Block group nesting patterns that bypass tiers

Use a rule of thumb: privilege can flow downward by nesting, but it must never flow upward. That means:

• Tier 0 groups must not be members of Tier 1/2-managed groups.
• Tier 0 delegation groups must not accept members from Tier 1/2 groups without strict control.
• “Everyone gets it through nesting” is a containment anti-pattern.

Auditing: prove your containment is holding

Containment is a claim until you can validate it continuously. Focus auditing on:

• Privileged group membership changes (adds/removes, nesting changes)
• Delegation group membership changes (the groups you delegated OUs to)
• OU ACL changes (especially on Tier 0 OUs and “Privileged Groups OU”)
• AdminSDHolder changes (unexpected edits to AdminSDHolder ACL)

Build “expected state” baselines. Your best signal is drift: something changed that shouldn’t change often.

Practical deployment sequence

1. Inventory: list Tier 0 OUs, privileged groups, delegation groups, and who can modify them.
2. Clean up: remove stale or broad delegations; shrink privileged group membership.
3. Isolate: create a Privileged Groups OU and tighten ACLs; move delegation groups there.
4. Enforce: ensure only Tier 0 admin principals can change Tier 0 delegation groups.
5. Harden identities: add Tier 0 human accounts to Protected Users (after compatibility checks).
6. Audit & alert: enable auditing for group membership/OU ACL/AdminSDHolder drift; review regularly.

This order matters: if you apply “protection” without fixing who can edit the delegation groups, you often end up with broken workflows and the same underlying risk.

Common pitfalls (and how to avoid them)

Assuming OU ACLs alone provide containment

OU permissions are only as strong as the groups they rely on. If a Tier 2 admin can modify the group that has Tier 0 OU rights, your boundary is already gone.

Using AdminSDHolder as a substitute for design

AdminSDHolder prevents some forms of tampering, but it doesn’t fix a messy privilege model. It can also override your intended delegation patterns. Use it as a guardrail, not as architecture.

Overusing protected status for operational accounts

If you mark too many accounts as “special,” routine operations become painful and teams work around the controls. Keep Tier 0 truly small, and make elevation time-bound.

Ignoring endpoints

If Tier 0 credentials are used on Tier 1/2 systems, containment fails even if AD permissions are perfect. Use dedicated admin workstations (PAWs/SAWs) and restrict where privileged accounts can sign in.

A reference checklist for “critical OU containment” using protected groups

• Tier model defined (T0/T1/T2) and mapped to OUs and admin roles
• Built-in privileged groups minimized; no standing broad memberships
• Delegation implemented via OU-specific groups (not direct user ACEs)
• Delegation groups placed in a hardened OU; membership changes tightly controlled
• No upward privilege flow via group nesting (Tier 2 → Tier 1 → Tier 0)
• Protected Users applied to Tier 0 human accounts after compatibility validation
• AdminSDHolder permissions monitored; unexpected protection status investigated
• Auditing enabled for: privileged groups, delegation groups, OU ACL changes
• Privileged sign-in restricted to hardened admin endpoints