Active Directory administrative tiering, and why implementations stall

Almost every organisation I have worked with has a tiering diagram. Far fewer have tiering. The gap between the two is not effort or budget. It is that the diagram describes an intention, and tiering is only real when something refuses a logon.

The problem tiering actually solves

A domain administrator signs in to a file server to fix a permissions problem. Their credential is now resident on that file server. If the file server is compromised, the attacker does not need to break Active Directory. They wait, they harvest, and they inherit the directory.

That is credential theft and reuse, and it is the mechanism behind most of the domain compromises I have read about. The interesting part is what it implies: the security of your domain controllers is bounded by the security of the least trustworthy machine any Tier 0 credential has ever touched.

Tiering is the containment answer. Administrative accounts are partitioned by what they control, and accounts from a higher tier are prevented from authenticating to lower-tier systems. The point is not tidiness. The point is that a compromised workstation yields workstation credentials and nothing else.

Where the tier model sits now

The original AD DS tier model defined three tiers: Tier 0 for the identity control plane, Tier 1 for servers and applications, Tier 2 for user workstations and devices. Microsoft’s enterprise access model builds on that structure and extends it to cloud services and modern access paths, so the control plane now includes Microsoft Entra ID, not only your forest.

The underlying principle did not change, and it is worth stating plainly because it is the principle that gets violated: lower-trust systems must not be able to influence higher-trust systems. Everything else is implementation detail.

Defining Tier 0 honestly

This is the step where implementations go wrong, and they go wrong by being too generous about what is not Tier 0.

Tier 0 is anything that can take control of the forest, directly or indirectly. That includes:

Domain controllers, and the virtualisation hosts that run them. A hypervisor administrator can copy a domain controller’s disk.
Microsoft Entra Connect and Cloud Sync servers, and their service accounts.
Active Directory Federation Services servers and their token-signing keys.
Issuing certification authorities in a PKI that Active Directory trusts for authentication.
The backup system that holds domain controller system state, and the accounts that can restore it.
Any account or group with directory-wide control: Domain Admins, Enterprise Admins, Schema Admins, the built-in Administrators group, and the operator groups — Account Operators, Backup Operators, Server Operators and Print Operators — which people routinely forget carry escalation paths.
Group Policy Creator Owners, and anyone who can edit a GPO linked to the domain controllers organisational unit. Editing that GPO is equivalent to running code on every domain controller.
DnsAdmins, where the DNS service runs on domain controllers.

Write this list for your own environment before you draw anything. If a system can take over the forest and it is not in Tier 0, your tiering does not exist — it has a hole with a diagram over it.

The four control decisions

Tiering is implemented by four decisions. Skip any one and the model degrades to guidance.

Separate accounts. A person who administers domain controllers has a distinct account for that, used for nothing else. Not a member of their daily account’s groups, not used for email, not used to browse. One human, several accounts, each scoped to one tier.

Separate workstations. A Tier 0 account must sign in only from a Tier 0 administrative workstation. If the Tier 0 account signs in from the same laptop that reads mail, the separation is cosmetic: both credentials now sit in the same memory space.

Enforced logon restrictions. This is the part that turns the diagram into a control. Group Policy deny rights, applied to the appropriate tier’s systems, are the blunt and reliable mechanism:

Deny access to this computer from the network       (SeDenyNetworkLogonRight)
Deny log on as a batch job                          (SeDenyBatchLogonRight)
Deny log on as a service                            (SeDenyServiceLogonRight)
Deny log on locally                                 (SeDenyInteractiveLogonRight)
Deny log on through Remote Desktop Services         (SeDenyRemoteInteractiveLogonRight)

Apply these to Tier 1 and Tier 2 systems, denying the Tier 0 administrative groups. Then apply the mirrored restriction to domain controllers, denying Tier 1 and Tier 2 groups. Deny rights take precedence over allow rights, which is exactly the property you want here.

Delegation instead of membership. Most of the reason people end up in Domain Admins is that nobody delegated the specific thing they needed. Someone needs to reset passwords for one organisational unit, or restart a service, or create computer objects. Delegate that. Membership of a directory-wide group to solve an organisational-unit-wide problem is the default failure.

Directory controls worth adding

Two features do work that Group Policy cannot, and both are underused.

The Protected Users group changes how a credential behaves rather than where it can be used. Members cannot authenticate with NTLM, cannot use DES or RC4 for Kerberos pre-authentication, cannot be delegated, and get a non-renewable four-hour ticket-granting ticket. Credentials are not cached, so a member cannot sign in when a domain controller is unreachable. That last property is a genuine operational consequence — it is also why you never put your only break-glass account in the group.

Authentication policies and silos let you state, in the directory, that a given account may only obtain a ticket-granting ticket when authenticating from a named set of machines. This is the control that enforces “Tier 0 accounts only from Tier 0 workstations” at the Kerberos layer rather than the Group Policy layer. It requires a Windows Server 2012 R2 or later domain functional level and Kerberos armoring, so it usually arrives after the Group Policy work rather than instead of it.

Why implementations stall

I have seen the same four stalls repeatedly, and none of them are technical.

The list of Tier 0 systems is never finished. Someone raises the backup server, or the hypervisor, or a monitoring agent that runs as a domain administrator, and the scoping meeting adjourns. The fix is to accept an imperfect Tier 0 list and enforce it, then widen it. An enforced partial boundary beats an unenforced complete one.

Service accounts are treated as a later problem. They are not later. A service account in Domain Admins running on a Tier 1 server is a Tier 0 credential resident on a Tier 1 machine, which is the precise thing tiering exists to prevent. Inventory these first, because the remediation — group managed service accounts, or reduced rights — takes longer than any other part of the project.

Nobody owns the second workstation. Tier 0 administrative workstations cost money and inconvenience people. Without an executive owner, this is the step that quietly does not happen, and without it the rest is theatre.

The emergency path is undefined. Administrators will break the model during an incident unless there is a documented, rehearsed way to act under pressure. Define the break-glass procedure, and make breaking the model an auditable event rather than an improvisation.

Trade-offs worth accepting deliberately

Tiering makes routine work slower. An administrator who needs to touch two tiers needs two sessions on two machines. That cost is real and it is permanent. What you are buying is that a compromised endpoint stays a compromised endpoint.

It also increases your dependency on delegation being correct. When Domain Admins stops being the answer to everything, every unmet need becomes a delegation request. Budget for that work, or the group membership will quietly grow back.

Finally, tiering does not protect against a compromised Tier 0 workstation, a malicious administrator, or a directory that was already compromised before you started. If you have reason to suspect the last one, tiering is not the first task — assessing the directory itself and planning recovery come first.

Where to start on Monday

Write the Tier 0 list for your environment. Include the backup system and the hypervisor.
Enumerate current membership of every group on that list, including nested membership, and every service account with those rights.
Create separate administrative accounts for the people who genuinely need Tier 0.
Deploy the deny-logon Group Policy to Tier 1 and Tier 2 first. Do it in audit-adjacent fashion: a pilot organisational unit, then widen.
Only then start the workstation conversation, with evidence from steps one and two to support it.

How this was established

Written from current Microsoft documentation on the enterprise access model, the AD DS tier model, Protected Users and authentication policy silos, checked on 20 September 2026, and from my own experience of running and reviewing Active Directory environments. The user rights listed above are the standard Windows constant names.

No procedure here was executed in a lab for this article. The deny-logon rights in particular will lock people out if applied to the wrong group or the wrong scope, so pilot them against a small organisational unit with a tested rollback before you widen the link.