Every time I walk into a post-compromise environment, I see the same thing: a flat Active Directory where a compromised Tier 1 helpdesk account — or sometimes a Tier 2 workstation — has a clear path to Domain Admin. Three hops in BloodHound. Sometimes two. Occasionally one.
The Microsoft Enterprise Access Model (EAM) — the successor to the old three-tier admin model — is the right framework for preventing this. It's well-documented, freely available, and broadly ignored. Not because people don't know about it. Because actually implementing it in a real enterprise is hard in ways the documentation doesn't acknowledge.
This post is about doing it anyway.
What the Enterprise Access Model Actually Is
The old Microsoft tier model was straightforward: Tier 0 (Domain Controllers and AD itself), Tier 1 (servers and applications), Tier 2 (workstations and end users). The rule was clean — credentials from a lower tier must never touch a higher tier. A Tier 2 admin account must never log into a Tier 1 or Tier 0 system. A Tier 1 admin account must never log into a DC.
The Enterprise Access Model modernizes this to account for cloud identity, SaaS, and hybrid environments. It introduces the concept of a Control Plane — the highest trust tier — plus a Management Plane and a Data/Workload Plane. It maps both on-premises and cloud assets into a unified model.
Key terminology shift: Microsoft no longer uses "Tier 0/1/2" in the current EAM docs — they use Control Plane, Management Plane, and User Access. But in practice, most organizations (and most IR practitioners) still think in tier numbers. I'll use both interchangeably here.
The assets that belong in the Control Plane (Tier 0) include:
- Domain Controllers (all of them, including RODCs)
- Active Directory itself — the database, SYSVOL, NETLOGON
- AD Certificate Services (ADCS) — a root CA is Tier 0; subordinates may be Tier 1
- Entra ID (and the Entra Connect sync account — critically important)
- Any system that can push policy to DCs or modify AD objects without restriction
- Privileged Access Workstations (PAWs) used to manage Control Plane assets
- Backup systems that hold DC backups — the most commonly forgotten Tier 0 asset
The most common Tier 0 asset people miss: The Entra Connect Sync account. If your AD Connect sync service account has been granted Directory Sync rights, an attacker who compromises it can often pivot to resetting passwords of cloud-only Global Admins. It's on-prem, but it's Control Plane.
Why Flat AD Is the Default — and Why It's Lethal
Active Directory wasn't designed with tiering in mind. The default installation creates a single flat domain where any Domain Admin can touch everything. Over years of organic growth — server provisioning, helpdesk tooling, backup software, monitoring agents — permissions get layered on in ways nobody tracks.
When I run SharpHound against a typical mid-size enterprise, I almost always find:
- Helpdesk accounts that are local admins on servers (not just workstations)
- Service accounts with Domain Admin membership "because it was easier"
- Backup software service accounts with DC access that haven't been reviewed in years
- Kerberoastable SPNs on accounts with weak passwords
- Unconstrained delegation on non-DC machines (should be zero outside of DCs)
- Tier 1 admin accounts that administrators also use to check email and browse the web
Any of these is an attack path. Several together form a highway.
The Implementation Challenge: Organizational, Not Just Technical
Here's what the documentation undersells: AD tiering is a change management problem as much as a technical one.
Technically, the controls are well-understood. You use GPO to enforce logon restrictions — deny interactive/RDP logon for Tier 0 admins on Tier 1 and Tier 2 systems, and vice versa. You provision separate admin accounts per tier. You deploy PAWs for Tier 0 management. You implement LAPS for local admin randomization. You restrict service account permissions to what's actually needed.
The organizational problem is that implementing these controls breaks things. That helpdesk admin who's been logging into servers for six years? She can't anymore once you enforce Tier 1 restrictions. That backup software running under a Domain Admin account? It stops working the moment you demote the service account. The vendor-provided monitoring tool that "requires Domain Admin"? That'll require a conversation with the vendor.
The most important thing I tell clients before starting a tiering project: Budget for a regression phase. Things will break. That's not a failure — it's the model surfacing how much your environment has drifted from least-privilege. Document what breaks, understand why, and fix it the right way instead of restoring the old permission.
Where to Start: A Practical Sequence
Don't try to build the full EAM in one project. It won't happen. Here's the sequence I recommend, roughly ordered by risk reduction per unit of effort:
1. Enumerate What You Have
You cannot tier what you haven't inventoried. Before touching a single GPO, run a full BloodHound collection and export your AD object inventory. Use the data to find:
- All accounts with paths to Domain Admin
- All accounts with DCSync rights
- All accounts with AdminCount=1 (current and historical AdminSDHolder subjects)
- Kerberoastable SPNs and AS-REP-roastable accounts
- Unconstrained delegation on non-DC computers
2. Protect Tier 0 First — Fully, Before Moving On
The Control Plane is where a breach becomes a catastrophe. Get this right before worrying about Tier 1 or Tier 2 separation.
- Audit Domain Admin membership. It should be near-empty. Built-in Administrator accounts, a break-glass account, and nothing else as permanent members.
- Deploy PAWs for anyone who manages DCs or AD — a hardened, dedicated device used only for Tier 0 management. No email, no web browsing, no general use.
- Enforce logon restrictions via GPO. Deny interactive logon, deny RDP, deny network logon for Tier 0 admins on non-Tier-0 systems.
- Audit and tighten the Entra Connect sync permissions. The MSOL_ and AZUREADSSOACC accounts should have exactly the permissions they need and nothing more.
- Audit ADCS. ESC1–ESC8 are all Control Plane risk. Misconfigured certificate templates are one of the most common paths to Tier 0 escalation I see in the field.
3. Separate Admin Identities by Tier
Each administrator who manages systems across tiers needs separate accounts per tier. An admin who manages both workstations and servers needs:
- A standard user account for daily work (email, browsing, Teams)
- A Tier 2 admin account for workstation management
- A Tier 1 admin account for server management
- A Tier 0 admin account for DC/AD management, used only from a PAW
Yes, this is more accounts to manage. Yes, users complain. Do it anyway. The whole point of tiering is that credential theft from a lower tier doesn't give you access to a higher tier.
4. Deploy LAPS Everywhere
Local Administrator Password Solution randomizes the local admin password on every managed machine and stores it in a confidential AD attribute (or in Entra ID with Windows LAPS). This eliminates the most common lateral movement technique in ransomware intrusions: reusing the same local admin password across hundreds of machines.
Windows LAPS is built into Windows 11 22H2+ and Windows Server 2022. There's no good reason not to have this deployed across your entire estate.
5. Enforce Authentication Policies and Silos
Authentication Policies let you restrict which accounts can authenticate to which systems and impose TGT lifetime limits. This is the most technically complex piece of EAM and the one most organizations skip. Worth implementing for Tier 0 at minimum — restricting Tier 0 accounts so their Kerberos TGTs can only be used on designated systems eliminates Pass-the-Ticket attacks across tiers.
Common Pitfalls
Treating ADCS as an afterthought. AD Certificate Services is Tier 0 and one of the most abused attack surfaces in enterprise AD. Audit your CA before you declare Tier 0 "secured."
Forgetting about GPO delegation. Who can edit GPOs that apply to DCs? That's a Tier 0 privilege. In most organizations, far too many accounts have GPO edit rights through AD delegation that was configured years ago and never reviewed.
Ignoring service accounts. Old, over-privileged service accounts with SPNs that make them Kerberoastable. Build a service account inventory and enforce least-privilege aggressively.
Not testing logon restrictions before enforcing them. Always test in a staging OU before applying to production. Run in audit mode before enforcing.
Declaring victory too early. Permissions drift. New systems get provisioned without following the model. Build a review cadence into your security program — quarterly at minimum — and use BloodHound as your measurement tool.
The Payoff
In every environment where I've seen a successful Tier 0 compromise, the attack path went through a misconfigured Tier 1 or Tier 2 asset. Always. The attacker didn't start by attacking the DC — they started with a phished helpdesk user, moved laterally, hit a server with local admin access, and eventually reached something with delegated rights to AD.
A properly implemented EAM makes that attack chain fail at multiple points. Not just at the endpoint, not just at the perimeter — at the identity layer itself. Stolen credentials from Tier 2 can't touch Tier 1 systems. Compromised Tier 1 service accounts can't reach DCs. The attack path simply doesn't exist.
Where to start if this feels overwhelming: Run BloodHound against your environment and count the shortest paths to Domain Admin. If you have more than five paths with three or fewer hops, start there — close the shortest, highest-impact paths first. You don't need to implement full EAM to dramatically reduce your blast radius.