🏢Active DirectoryPrivileged AccessConfigComplianceMonitoring

Active Directory Tiered Admin Model: Building Tiers That Hold Up (ESAE to RAMP)

Most "tiered" Active Directory builds don't actually enforce the tier boundary. Here's how the model works in practice — OUs, PAWs, GPO scoping — plus detection and remediation.

Younes AZABARBy Younes AZABAR8 min read
Active Directory Tiered Admin Model: Building Tiers That Hold Up (ESAE to RAMP)

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.

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.

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:

IndicatorEvent ID / SourceWhat it catches
Tier 0 account logs on interactively outside a PAW4624 (logon type 2/10) + 4672 correlated by Logon IDCross-tier credential exposure — a Domain Admin authenticating on a standard workstation
Special privileges assigned on a non-Tier-0 host4672 on Tier 1/2 assetsPrivileged token issued where it shouldn't be — pairs with 4624 as a high-fidelity, low-noise rule
Session teardown for a cross-tier logon4634 / 4647Confirms session duration and scope once a violation is flagged
GPO link added/changed outside expected scope5136 (directory service object modified) on gPLink attributeA hardening or logon-rights GPO silently re-scoped across a tier boundary
Domain Admin / Enterprise Admin not in Protected UsersLDAP query on adminCount=1 accounts vs. Protected Users membershipAccounts that skip the NTLM/DES/delegation and credential-caching protections the group enforces
Privileged accounts outside a dedicated admin OULDAP query: distinguishedName of adminCount=1 accounts vs. Tier 0 admin OUAdmin 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.

Remediation: Building Tiers That Hold Up

  1. Move privileged accounts into a dedicated Tier 0 admin OU. This is the single check ANSSI calls out directly — accounts with adminCount=1 living 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Explore the identity security pages that support this topic