Admin tiering and Protected Users for Active Directory

Most Active Directory compromises follow the same path. An attacker lands on a workstation, finds a privileged credential in memory because an administrator logged on there, and reuses it until they reach a domain controller. Credential Guard, EDR and LAPS all make this harder, but the root cause is architectural: highly privileged credentials were exposed on a machine an ordinary user can compromise.

The tier model removes that exposure. Its rule is short: an account may only log on to systems in its own tier. A Domain Admin never types a password on a workstation, a server admin never logs on to a user laptop, and helpdesk accounts never touch servers. This guide turns that rule into Group Policy, group membership and checks.

The three tiers

The hardest part is being honest about Tier 0. Anything that can control a Tier 0 asset is Tier 0: the hypervisor cluster that runs virtual DCs, the backup server that can restore NTDS.dit, the software deployment tool with an agent on DCs, the monitoring agent running as SYSTEM on DCs. If your SCCM site server pushes software to domain controllers, SCCM is Tier 0.

Microsoft now describes a broader enterprise access model with control, management, data/workload, user and app access planes, which extends the same idea to Entra ID and cloud workloads. For on-premises AD, the three tiers are how you implement it.

Step 1: separate the accounts

Every administrator gets one account per tier they work in, plus their normal user account:

• jdoe - email, browsing, Office. No admin rights anywhere.
• adm-t2-jdoe - local admin on workstations (ideally via LAPS rather than group membership).
• adm-t1-jdoe - admin on member servers.
• adm-t0-jdoe - Domain Admins or delegated Tier 0 rights. Only a few people.

Create an OU structure that mirrors the tiers (Admin\Tier0, Admin\Tier1, Admin\Tier2, each with Accounts, Groups, Devices) so that GPOs and delegation can target each tier cleanly.

Then shrink the privileged groups. Check who is actually in them, including nested membership:

foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
               "Account Operators","Server Operators","Backup Operators","Print Operators") {
  Get-ADGroupMember -Identity $g -Recursive |
    Select-Object @{n="Group";e={$g}}, SamAccountName, objectClass
}

Account Operators, Server Operators, Backup Operators and Print Operators all have paths to domain controller compromise. They should be empty. Schema Admins and Enterprise Admins should be empty except during planned changes.

Step 2: enforce logon restrictions with GPO

The tier model only works if it is enforced, not just documented. Use User Rights Assignment under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, applied per tier OU:

Deny rights override allow rights, so this holds even if someone adds adm-t0-jdoe to a workstation's local Administrators group. Include the built-in Domain Admins and Enterprise Admins groups in the Tier 0 deny lists on workstations and member servers.

A note on network logon: "deny access from the network" for Tier 0 accounts on servers blocks SMB, WinRM and similar remote administration by those accounts, which is the point. Test with a pilot OU first, because some legacy management tools rely on a Domain Admin logging on everywhere.

Step 3: put Tier 0 humans in Protected Users

Protected Users is a built-in global security group (Windows Server 2012 R2 and later) that applies non-configurable protections to its members. On devices running Windows 10 / Windows 11 or Windows Server 2012 R2 or later, and with the domain functional level at Windows Server 2012 R2 or later for the domain controller protections:

• NTLM authentication is refused, so there is no NTLM hash to steal or relay.
• Kerberos will not use DES or RC4 for pre-authentication.
• The account cannot be delegated (constrained or unconstrained).
• The TGT lifetime is capped at four hours instead of ten.
• Credentials are not cached: no cached logon verifier, no CredSSP or WDigest plaintext, no long-term keys kept in memory.

Add every human Tier 0 and Tier 1 admin account. Do not add service accounts, computer accounts, or your break-glass account (it needs to work when Kerberos does not). Test first: anything that authenticates these accounts with NTLM, for example a management appliance that connects by IP address, will stop working, which is usually a finding in itself.

For accounts that cannot join Protected Users, at least set Account is sensitive and cannot be delegated on the account object.

Add-ADGroupMember -Identity "Protected Users" -Members adm-t0-jdoe, adm-t1-jdoe
Get-ADUser -Filter {AdminCount -eq 1} -Properties AccountNotDelegated |
  Select-Object SamAccountName, AccountNotDelegated

Step 4: administer from the right place

Logon restrictions tell you where an admin account may not go; you also need somewhere safe for it to go. A privileged access workstation (PAW) is a hardened device used only for administration: no email, no browsing, strict application control, Credential Guard on, and managed from its own tier. For Tier 0 this is non-negotiable. For Tier 1, hardened jump servers are a common compromise.

When you must RDP from a lower-trust device, use Remote Credential Guard (mstsc /remoteGuard) or Restricted Admin mode (mstsc /restrictedAdmin) so that reusable credentials are not sent to the remote host. Remote Credential Guard is generally preferred because it keeps Kerberos requests on the client side and still lets you reach network resources as yourself.

Step 5: Authentication policies and silos (optional)

For stronger enforcement than user rights, Active Directory authentication policies and silos (domain functional level 2012 R2+) restrict where Tier 0 accounts can obtain Kerberos tickets, checked by the domain controller itself. For example, members of a "Tier0" silo can only receive a TGT when logging on from computers in that silo. This requires Kerberos armoring (FAST) and careful testing, but it closes gaps that GPO-based deny rights cannot, such as a Tier 0 account used from an unmanaged device.

Verify it

1. Where have Tier 0 accounts logged on? On domain controllers, event 4768 (TGT requested) and 4769 (service ticket requested) show the client address; on member systems, 4624 with logon type 2 (interactive), 10 (remote interactive) or 3 (network) show where accounts were used. Build a report of Tier 0 accounts authenticating from anything that is not a DC or PAW; it should be empty.
2. Is Protected Users effective? On a DC, the log Applications and Services Logs > Microsoft > Windows > Authentication records failures for Protected Users members (the ProtectedUserFailures-DomainController and ProtectedUserSuccesses-DomainController logs on DCs, and ProtectedUser-Client on clients, are disabled by default; enable them first). NTLM attempts by members show up as failures.
3. Are there hidden paths? Tools such as BloodHound (Community Edition) or PingCastle map attack paths through ACLs, group nesting and delegation. Run them regularly; tiering on paper often leaks through an old ACL on an OU or a GPO editable by a Tier 1 group.

Checklist

• Tier 0 asset list written down, including hypervisors, backup, PKI and sync servers
• Separate admin accounts per tier, no admin rights on daily-use accounts
• Operator groups empty, Schema/Enterprise Admins empty by default
• Deny-logon GPOs on workstations, member servers and DCs
• Human privileged accounts in Protected Users; others marked "sensitive and cannot be delegated"
• PAWs for Tier 0; Remote Credential Guard for RDP
• Monthly report of Tier 0 logons outside Tier 0
• Attack-path review (BloodHound CE / PingCastle) on a schedule

Tiering is organisational work more than technical work, which is why it gets skipped. Pair it with unique local admin passwords and Credential Guard, and a single phished laptop stops being a path to your domain controllers.