What Is the Active Directory Tiered Admin Model
The Active Directory tiered admin model is the security architecture that stops an attacker who compromises a help-desk laptop from walking straight to Domain Admin. It splits every identity, workstation, and server into trust tiers — Tier 0 (the identity control plane itself), Tier 1 (servers and business applications), and Tier 2 (end-user workstations and standard accounts) — and enforces one rule in both directions: credentials from a higher tier must never be exposed to a lower tier, and lower-tier credentials must never be able to control a higher tier (Microsoft Learn, AD DS Tier Model).
Most environments that claim to run a tiered model don't actually enforce it. Domain Admins RDP into member servers to "just check something." A Tier 1 service desk GPO gets linked one OU too high and lands on the domain controllers OU. A break-glass account sits outside Protected Users because nobody remembered to add it. Each of these is individually small; together they collapse the tier boundary the model exists to protect, and they're exactly the kind of privileged access drift that creeps back in after a hardening pass unless something keeps re-checking it.
Getting the boundary wrong is expensive because Tier 0 compromise is not a localized incident — it's total. An attacker who lands a Tier 0 credential (via a cross-tier logon, a mis-scoped GPO, or an account left out of Protected Users) can typically DCSync the entire directory and forge Kerberos tickets for any identity in the domain. The tiered model exists specifically to keep that outcome contained to a Tier 0 breach, rather than letting a single compromised helpdesk workstation cascade into one.
ℹ️ Note: the model has gone through a naming shift worth knowing before you read older guidance. The original hardened admin-forest pattern — the Enhanced Security Admin Environment (ESAE), also called "red forest" — is now a retired Microsoft recommendation, reserved for niche exception cases. Microsoft replaced it with the Rapid Modernization Plan (RAMP) and the broader Enterprise Access Model, which keep the same tiering logic but assume most organizations should not stand up a whole second forest to get it (Microsoft Learn, ESAE retirement). If a vendor or a consultant is still pitching you a red forest build in 2026, ask why — RAMP gets you the same Tier 0 isolation with far less operational overhead.
From OUs to Enforcement: How Tiering Actually Works
Tiering is not a diagram — it's an OU structure, a set of scoped GPOs, and a hard boundary on where privileged accounts can interactively log on.
OU Structure
Tier 0 assets (domain controllers, AD FS, PKI/ADCS servers, backup infrastructure that can restore a DC, and the accounts/groups that administer any of them) live in a dedicated Tier 0 OU tree, separate from Tier 1 servers and Tier 2 workstations. Delegation and GPO links follow the same boundary — a Tier 2 workstation-hardening GPO should never be linked anywhere near the Tier 0 OU, and vice versa (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).
Privileged Access Workstations (PAWs)
Tier 0 admin accounts should only ever be able to log on interactively to a small, dedicated set of Tier 0 devices — PAWs joined to their own OU with hardening GPOs (no internet browsing, no email, application allow-listing) scoped exclusively to that OU (Microsoft Learn, PAW legacy guidance). This is the practical enforcement of Rule #1: if a Tier 0 credential can authenticate on a Tier 1 or Tier 2 device, the boundary is already broken, regardless of what the org chart or the wiki diagram says.
GPO Scoping Discipline
Link security-hardening GPOs at the tier-appropriate OU only — never at the domain root, never at Default Domain Policy. Cross-linking a GPO across tier OUs is one of the most common ways tier boundaries erode silently over months, because nobody notices a link addition the way they'd notice a new admin account.
💡 Tip: Microsoft now ships an official reference implementation for this — the microsoft/ActiveDirectoryTierModel GitHub repository, with deployment scripts for the Tier 0/1/2 OU structure and an Audit-TierModel.ps1 script that baselines your current OU and GPO layout against the model. It's a fast way to check where your build has drifted from the reference design before you start manual remediation.
Detection: Catching Tier Violations Before They're Exploited
A tier violation is not a single event — it's a pattern of a privileged identity or a GPO link showing up somewhere it shouldn't. Build detections around these signals:
| Indicator | Event ID / Source | What it catches |
|---|---|---|
| Tier 0 account logs on interactively outside a PAW | 4624 (logon type 2/10) + 4672 correlated by Logon ID | Cross-tier credential exposure — a Domain Admin authenticating on a standard workstation |
| Special privileges assigned on a non-Tier-0 host | 4672 on Tier 1/2 assets | Privileged token issued where it shouldn't be — pairs with 4624 as a high-fidelity, low-noise rule |
| Session teardown for a cross-tier logon | 4634 / 4647 | Confirms session duration and scope once a violation is flagged |
| GPO link added/changed outside expected scope | 5136 (directory service object modified) on gPLink attribute | A hardening or logon-rights GPO silently re-scoped across a tier boundary |
| Domain Admin / Enterprise Admin not in Protected Users | LDAP query on adminCount=1 accounts vs. Protected Users membership | Accounts that skip the NTLM/DES/delegation and credential-caching protections the group enforces |
| Privileged accounts outside a dedicated admin OU | LDAP query: distinguishedName of adminCount=1 accounts vs. Tier 0 admin OU | Admin accounts created or moved outside the OU boundary the whole model depends on |
Why Event ID 4672 Is the High-Fidelity Signal
Event ID 4672 ("special privileges assigned to new logon") fires immediately after a successful 4624 for any account holding admin-equivalent rights, and its Logon ID is the join key across the whole session lifecycle — 4624 → 4672 → activity → 4634/4647 (Microsoft Learn, Event 4672). On a workstation where a Domain Admin should never interactively sign in, a single 4672 for that account is a high-fidelity, low-effort alert — you don't need UEBA tooling to catch the obvious case, just the right correlation rule on the right OU scope.
⚠️ Warning: don't build this detection only on the domain controllers. Tier violations most often surface on Tier 1 member servers or Tier 2 workstations, where an admin RDP'd in "just this once." If your logon monitoring only watches the DCs, you'll miss the exact behavior the tier model is designed to prevent.
Remediation: Building Tiers That Hold Up
💡 Quick Win: run Audit-TierModel.ps1 from Microsoft's ActiveDirectoryTierModel repository (or an equivalent LDAP query against adminCount=1 accounts and their OU/DN) to get a baseline of every privileged account and GPO link that currently sits outside your intended tier boundary — before you change anything.
-
Move privileged accounts into a dedicated Tier 0 admin OU. This is the single check ANSSI calls out directly — accounts with
adminCount=1living outside a dedicated, tightly-delegated OU break the segmentation the rest of the model depends on (ANSSI-PA-099, "Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory," Oct. 2023). -
Add all Tier 0 accounts to Protected Users. This blocks NTLM authentication, DES/RC4 Kerberos encryption, unconstrained/constrained delegation, and long-lived TGTs for those accounts — closing off several of the credential-theft paths delegation gaps otherwise expose.
-
Enforce a Fine-Grained Password Policy on Tier 0 groups. Domain and Enterprise Admins should not inherit the default domain password policy; a dedicated PSO with stronger length and rotation requirements limits blast radius if a Tier 0 credential is exposed anyway.
-
Scope every GPO strictly to its tier OU. Audit existing GPO links for anything touching both a Tier 0 OU and a Tier 1/2 OU, and split them. Never add tiering enforcement settings to the Default Domain Policy — create dedicated GPOs and link them only to the relevant tier OU.
-
Stand up PAWs for Tier 0 interactive logon, then enforce it technically. Use logon-rights GPOs (
Deny log on locally/Deny log on through Remote Desktop Services) on Tier 1/2 assets for Tier 0 accounts, not just policy documentation — a written rule nobody can violate technically doesn't survive an incident. -
Re-baseline quarterly, not once. Tier boundaries drift from routine admin work — a new server admin added to the wrong group, a GPO relinked during a migration, or stale privileged accounts nobody offboarded from Tier 0. A one-time tiering project without a recurring audit degrades back to flat administration within a year; see the broader hardening priorities guide for how this fits into a wider AD hardening sequence and the ANSSI recommendations in practice for the full compliance-driven checklist this model is part of.
How EtcSec Detects This
EtcSec's Active Directory audit checks for tier model violations directly against your live directory: ANSSI_R15_TIER_MODEL_VIOLATION flags privileged accounts sitting outside a dedicated admin OU, ANSSI_R40_NO_PSO_TIER0 flags Tier 0 groups without a Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION checks administration-forest trust segregation where one is in use, NOT_IN_PROTECTED_USERS flags privileged accounts missing from the Protected Users group, and EXCESSIVE_PRIVILEGED_ACCOUNTS flags tier boundaries that have grown too large to audit manually.
ℹ️ Note: EtcSec automatically checks for these tier-model gaps during every Active Directory audit. Run a free audit to see where your current build has drifted from the tiered admin model it's supposed to be running.
Explore the identity security pages that support this topic
