Active Directory Tiered Administration Model: A Practical Setup Guide

The tiered administration model is Microsoft’s answer to one of the most common ways Active Directory environments get compromised: an admin logs into a low-trust workstation with high-trust (Domain Admin) credentials, malware or a keylogger captures the session, and the attacker now owns the domain. Tiering breaks that chain by strictly separating which accounts can log on to which systems. It sounds bureaucratic on paper, but a lean version of it is achievable in most environments within a few weeks.

• Tier 0 = domain controllers, AD FS, PKI, and anything that can control the domain itself
• Tier 1 = servers and applications (SQL, Exchange, file servers)
• Tier 2 = end-user workstations and helpdesk-level access
• The golden rule: a Tier 0 credential should never be entered on a Tier 1 or Tier 2 machine
• Privileged Access Workstations (PAWs) are the practical mechanism that makes this enforceable

Why tiering matters more than most security controls

Most AD compromises Microsoft’s own DART incident response team investigates follow the same pattern: credential theft on a lower-trust machine, followed by lateral movement using cached credentials or tokens, ending in Domain Admin. Tiering doesn’t stop the initial compromise, but it stops it from ever reaching Tier 0, which is the difference between a contained incident and a full domain rebuild.

Step 1: Map your accounts and systems to tiers

Start with an inventory, not a policy document. List every service account, admin account, and system, and assign each a tier. Domain Admins, Enterprise Admins, and anything with rights over AD itself is Tier 0. Application and server admins are Tier 1. Helpdesk and standard user support is Tier 2. Expect this step to surface accounts nobody remembers creating. That’s normal and part of the value of doing it.

Step 2: Create tier-specific admin accounts

Every admin needs a separate account per tier they operate in. A Tier 0 admin account (used only from a PAW to manage DCs), a Tier 1 account (for server administration), and their normal Tier 2/standard user account for email and browsing. Yes, this means some staff carry three accounts. That’s the point: it makes it structurally impossible to use a Domain Admin credential to log into a regular workstation.

Step 3: Enforce logon restrictions with Group Policy

Use “Deny log on locally” and “Deny access to this computer from the network” GPO settings to prevent Tier 0 accounts from ever authenticating to Tier 1 or Tier 2 machines, and Tier 1 accounts from authenticating to Tier 2 machines. Apply these via security filtering scoped to OUs matching your tier structure, and test in a pilot OU before rolling out domain-wide. An overly broad deny rule can lock admins out of systems they legitimately need.

Step 4: Stand up a Privileged Access Workstation for Tier 0

A PAW is a dedicated, locked-down machine used exclusively for Tier 0 administration. No email, no general web browsing, no installing arbitrary software. It can be a physical laptop reserved solely for this purpose or a hardened VM, but it must never be used for anything else. This is the single highest-value control in the whole model, and it’s realistic to implement even for a small IT team with just one or two shared PAWs.

Rolling it out without breaking production

Don’t try to tier everything on day one. Start with Tier 0 isolation only. Get Domain Admin-equivalent accounts restricted to PAWs and denied everywhere else, and treat Tier 1/Tier 2 separation as a follow-up phase. Microsoft’s Enterprise Access Model documentation (the modern successor to the original tiering whitepaper) is worth reading in full before you start, since it reflects current recommended practice including cloud identity considerations.

For official guidance, see Microsoft’s Windows Server documentation.