Active Directory Tiered Administration Model: A Practical Setup Guide

If someone compromises a single help-desk laptop in your organisation, how far can they get? In a flat Active Directory, the honest answer is usually “everywhere” — because at some point a Domain Admin logged into that laptop to fix something, and their credentials have been sitting in memory ever since.

The tiered administration model exists to make that answer “not very far at all”. This guide covers what the tiers actually are, the rules that make them work, and how to roll the model out on an estate that is already running — which is the hard part nobody writes about.

Is the tier model still current in 2026?

Yes, and it is worth clearing this up first because there is a lot of confusion about it.

You will see people claim the tier model was retired and replaced by the Enterprise Access Model. That is not quite right. Microsoft’s current position is that the Enterprise Access Model is the broader framework — covering cloud, on-premises, user access and application access paths — and the AD DS tier model is a component of it, specifically the part that prevents privilege escalation inside Active Directory.

So if you run Active Directory, tiering is still the guidance. It sits inside a larger model rather than being superseded by one. The older “Red Forest” (ESAE) architecture is the thing that has genuinely been retired for most organisations — Microsoft now recommends it only for a small number of specialised cases.

The three tiers

The classification question that decides Tier 0 membership is not “is this server important?” It is: can this system, or an administrator of this system, take control of Active Directory? If yes, it is Tier 0 regardless of what it is called.

That catches a lot of things people put in Tier 1 by mistake. Your backup server can restore a domain controller, so it is Tier 0. Your patch management system pushes code to DCs as SYSTEM, so it is Tier 0. Your virtualisation hosts can mount a DC’s virtual disk, so they are Tier 0. The hypervisor management console is Tier 0. So is anything holding a certificate authority’s private key.

The three rules that make it work

The tiers themselves are just labels. These rules are the actual control:

1. One account, one tier

An administrator who works across tiers gets a separate account per tier. Not one account with more permissions — separate accounts. In practice that means a person might hold three: a standard user account for email and day-to-day work, a Tier 1 account for server administration, and (if they genuinely need it) a Tier 0 account for domain work.

This is the rule people resist hardest, and it is the one that does most of the work.

2. Credentials never travel downwards

A Tier 0 credential is never typed into a Tier 1 or Tier 2 machine. Ever. Not to “just quickly fix something”, not over RDP, not with Run As.

The reason is mechanical rather than theoretical. When you authenticate interactively to a machine, artefacts of that credential live in LSASS memory on that machine. Anyone with SYSTEM on the box — which is anyone who has compromised it — can harvest them. Typing a Domain Admin password into a help-desk laptop does not borrow the laptop’s trust level; it hands the laptop your trust level.

This is why “just this once” is never just once. The credential is exposed from that moment until it is reset.

3. Sessions reach down, never up

You administer a tier from a machine at that tier or higher, never from below. A Tier 0 admin sits at a Tier 0 workstation and connects out to domain controllers. They do not sit at their ordinary desktop and RDP up into a DC.

Microsoft calls this the clean keyboard principle: trust starts at the physical keyboard you are sitting at, and it must already match the tier you intend to reach. This is what Privileged Access Workstations are for — a dedicated, locked-down machine used for nothing but administration at a given tier. No email, no browsing, no productivity software.

Enforcing it technically

Rules that rely on discipline get broken at 2am during an incident. These are the controls that make the rules hold when nobody is watching.

Deny logon rights via Group Policy

This is the backbone. Create a GPO for each tier that denies the other tiers’ groups the ability to log on. The settings live under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

On Tier 1 and Tier 2 machines, deny the Tier 0 groups:

• Deny log on locally
• Deny log on through Remote Desktop Services
• Deny log on as a batch job
• Deny log on as a service
• Deny access to this computer from the network

Apply the same pattern in reverse on Tier 0 machines for Tier 1 and Tier 2 groups. The critical detail is to deny all five. Denying only interactive logon leaves the network and service paths wide open, and those are the ones attackers actually use.

Authentication policy silos

Silos are stronger than deny rights because they are enforced by the KDC rather than by the target machine. An account in a silo can only authenticate to machines in the same silo — so even if a deny-logon GPO fails to apply somewhere, the ticket is never issued in the first place.

# Create a silo for Tier 0
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" -Enforce

# Create a matching policy: Tier 0 accounts may only get TGTs
# from machines in the silo, with a short TGT lifetime
New-ADAuthenticationPolicy -Name "Tier0-Policy" -Enforce `
    -UserTGTLifetimeMins 240

# Put the DCs and the Tier 0 PAWs into the silo
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" `
    -Account "DC01$"

# And the admin accounts
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" `
    -Account "adm-t0-jsmith"

Silos require a Windows Server 2012 R2 or higher domain functional level, and every account placed in one must support Kerberos armouring. Test with -Enforce omitted first — audit mode logs what would have been blocked without actually blocking it, and that list is always longer than you expect.

Protected Users

Adding Tier 0 accounts to the built-in Protected Users group forces Kerberos-only authentication, blocks NTLM, disables delegation and stops credentials being cached. It is a single group membership and it removes several attack paths at once.

The catch: it genuinely breaks things that depend on NTLM or cached credentials. Anything using a legacy authentication path will stop working, and offline logon stops working entirely, so never put an account in it that might need to log on to a machine with no line of sight to a DC.

Rolling it out on a live estate

Every guide shows you the finished architecture. Almost none of them tell you how to get there without taking the business down, which is the only part that matters if you already have an environment.

Do it in this order.

Step 1: Find out what you actually have

Before designing anything, find every account that currently holds domain-level privilege. It is almost always more than the org chart suggests.

# Everyone in the groups that matter, including nested membership
$tier0Groups = @(
    "Domain Admins", "Enterprise Admins", "Schema Admins",
    "Administrators", "Account Operators", "Backup Operators",
    "Server Operators", "Print Operators", "DnsAdmins"
)

foreach ($group in $tier0Groups) {
    Get-ADGroupMember -Identity $group -Recursive -ErrorAction SilentlyContinue |
        Select-Object @{n='Group';e={$group}}, Name, SamAccountName, objectClass
} | Sort-Object Group, Name | Format-Table -AutoSize

Pay particular attention to Account Operators, Backup Operators, Server Operators and Print Operators. These are legacy built-in groups with far more power than their names suggest — Backup Operators can read the entire directory database, and Account Operators can modify most accounts. Microsoft’s own guidance is to keep all four empty. In most estates that have been running a while, they are not.

Also find where privileged accounts have actually been logging on, because that tells you which machines are already contaminated:

# Interactive and RDP logons by admin accounts on a DC, last 7 days
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4624
    StartTime = (Get-Date).AddDays(-7)
} | Where-Object {
    $_.Properties[8].Value -in @(2,10) -and
    $_.Properties[5].Value -like 'adm-*'
} | Select-Object TimeCreated,
    @{n='Account';e={$_.Properties[5].Value}},
    @{n='Workstation';e={$_.Properties[11].Value}} |
    Sort-Object Account | Format-Table -AutoSize

Step 2: Build the OU structure and groups

Create a parallel structure before moving anything into it. A simple, boring layout survives contact with reality better than a clever one:

OU=Admin
  OU=Tier 0
    OU=Accounts
    OU=Groups
    OU=Servers
    OU=Workstations   (the Tier 0 PAWs)
  OU=Tier 1
    OU=Accounts
    OU=Groups
    OU=Servers
  OU=Tier 2
    OU=Accounts
    OU=Groups
    OU=Workstations

Block inheritance on the Admin OU so a permissive policy applied at the domain root cannot undermine it, and delegate control so that Tier 1 and Tier 2 administrators cannot modify anything under Tier 0.

Step 3: Run the GPOs in audit before enforcing

Link the deny-logon GPOs to a pilot OU containing a handful of representative machines rather than the whole estate. Leave them for at least a full business cycle — a fortnight is sensible, because month-end and patch weekends surface dependencies that a quiet Tuesday does not.

Watch for Event ID 4625 with a logon failure status of 0xC000015B, which is specifically “the user has not been granted the requested logon type”. Every one of those is something that was quietly depending on a cross-tier logon.

Step 4: Deal with the service accounts

This is where these projects stall, so budget properly for it. You will find service accounts that are Domain Admins for no reason other than that it made an installer work in 2014.

For each one: find what it genuinely needs, grant exactly that, and move it to the correct tier. Where the service supports it, replace it with a group Managed Service Account so the password rotates automatically and nobody ever knows it:

# One-time per forest, if you have never used gMSAs
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

New-ADServiceAccount -Name "gmsa-sqlsvc" `
    -DNSHostName "gmsa-sqlsvc.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"

# On the target server
Install-ADServiceAccount -Identity "gmsa-sqlsvc"
Test-ADServiceAccount -Identity "gmsa-sqlsvc"

The Add-KdsRootKey line normally needs ten hours to replicate before gMSAs work. The AddHours(-10) trick backdates it so you can use them immediately — fine in a single-DC lab, but in production with multiple DCs you should let it replicate properly instead.

Step 5: Enforce, then keep it honest

Enforce tier by tier, starting at Tier 0 — it has the fewest accounts and the highest value, so it is both the easiest and the most worthwhile.

Then set up an alert for the thing that will eventually undo all of it: someone adding an account back into a Tier 0 group. Event ID 4728 (member added to a global group) and 4732 (local group) on your domain controllers are the ones to watch. Without that alert, the model quietly erodes over a couple of years and nobody notices until an assessment.

The mistakes that undo the whole thing

• Forgetting the backup server. If it can restore a DC, it is Tier 0. Backup infrastructure is the single most commonly misclassified system.
• Forgetting the hypervisor. Anyone who can mount a virtual DC’s disk owns your directory. Virtualisation admins are Tier 0 admins whether the org chart says so or not.
• Denying only interactive logon. All five deny rights, or you have left the door open.
• Treating the PAW as a normal build with a policy on top. If it has a browser and an email client, it is not a PAW.
• Leaving the legacy operator groups populated. Account, Backup, Server and Print Operators should all be empty.
• No monitoring on group membership. The model does not fail loudly. It erodes.

Where to start if you do nothing else

Full tiering is a project measured in months. If that is not realistic right now, these three things deliver most of the protection for a fraction of the effort:

1. Give every Domain Admin a separate ordinary account for email and browsing, and make it the one they use by default.
2. Deny Tier 0 groups all five logon rights on workstations. One GPO, and it stops the single most common escalation path in the world.
3. Empty Account Operators, Backup Operators, Server Operators and Print Operators, and alert on anything being added back.

That is an afternoon’s work and it closes the path that most real-world domain compromises actually take.