Tier 0 and privileged access: locking down Domain Admins

Most Active Directory compromises do not start with a zero-day against a domain controller — they start with an over-privileged account logging into an under-protected machine. An IT admin RDPs into a help desk workstation with their Domain Admin credentials to fix a printer issue, a credential-theft tool harvests the token, and the attacker walks straight to NTDS.dit. The tier model exists to make that walk impossible by construction, not by policy memo.

This guide covers the enterprise access model, how to physically and logically separate Tier 0, and the concrete GPO, group, and PowerShell work needed to enforce it.

The tier model: Tier 0, 1, and 2

Microsoft's classic three-tier model (now folded into the broader Enterprise Access Model) separates administration by blast radius:

The rule that makes the model work is directional: a Tier N admin account may only log on to Tier N assets. A Tier 0 credential must never touch a Tier 1 or Tier 2 machine, and a Tier 1 admin must never use their credentials on a Tier 2 workstation. Violate this once — logging into a help desk PC with a Domain Admin account — and the tier boundary is gone, because credential theft on that machine now yields Tier 0 access.

What belongs in Tier 0

Be strict here; scope creep into Tier 0 is the most common failure. Tier 0 includes:

• Domain controllers (all of them, including RODCs for administrative purposes)
• AD Certificate Services root and issuing CAs (a compromised CA can forge authentication certificates for any user)
• AD FS servers and their token-signing certificates
• Microsoft Entra Connect / Entra Connect Sync servers
• Backup and imaging systems capable of restoring or reading AD data
• Privileged Access Workstations themselves and any jump/bastion hosts used to reach Tier 0
• The security groups: Domain Admins, Enterprise Admins, Schema Admins, Administrators (on DCs), Account Operators, Backup Operators, Print Operators, Server Operators

If you are unsure whether something belongs in Tier 0, ask: "if this system is compromised, can the attacker compromise the domain?" If yes, it is Tier 0, full stop — regardless of how inconvenient that is operationally.

Separate admin accounts

Every human administrator who touches Tier 0 needs a dedicated account used for nothing else — no email, no browsing, no Teams. A practical naming convention:

florian.amette          -> standard user account (Tier 2, email, day-to-day)
adm-t0-famette          -> Tier 0 admin account (DCs, PKI, Entra Connect)
adm-t1-famette          -> Tier 1 admin account (member servers, apps)

Do not reuse a single "admin" account across tiers, and do not give the standard user account any implicit membership in privileged groups. Enforce this with AdminSDHolder-protected groups and periodic membership audits rather than trust.

Deny-logon GPOs to enforce the boundary

Group membership alone does not stop an admin from logging into the wrong tier — you need explicit logon-right denials. Create dedicated GPOs and link them by tier:

GPO: "Tier 0 – Deny Logon From Lower Tiers" (linked to the Domain Controllers OU and any Tier 0 server OU)

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Mirror this with a "Tier 1 – Deny Logon From Tier 0 and Tier 2" GPO on member server OUs, and a "Tier 2 – Deny Logon From Tier 0 and Tier 1" GPO on workstation OUs. This is what actually stops a Domain Admin credential from being usable if phished on a workstation: even with valid credentials, the deny right blocks the logon.

Protected Users group

Adding Tier 0 accounts to Protected Users (available since Windows Server 2012 R2, enforced by DCs and clients at 2012 R2+) hardens the credential itself:

• Blocks NTLM authentication for the account entirely
• Blocks DES and RC4 in Kerberos pre-authentication, forcing AES
• Disables credential caching (no cached logon, no CredSSP, no WDigest)
• Prevents Kerberos ticket renewal beyond 4 hours, forcing re-authentication

Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-famette"

Test in a pilot group first — see "what it breaks" below. Combine this with the encryption hardening in Kerberos hardening for full effect.

Privileged Access Workstations (PAWs)

A deny-logon GPO stops the wrong-tier logon, but the admin still needs somewhere to administer Tier 0 from. That's the PAW: a hardened, single-purpose device that:

• Runs no browser, email client, or Office suite (or a heavily locked-down browser limited to the internal admin portal only)
• Is joined to a dedicated Tier 0 OU with its own restrictive GPOs
• Has no local admin rights for the logged-on user beyond what's needed
• Is the only device permitted to log on with Tier 0 credentials (enforced by the deny-logon GPOs above, applied in reverse — Tier 0 accounts denied everywhere except the PAW OU)
• Uses BitLocker, Credential Guard, and up-to-date patching as a baseline

Minimum viable PAW: a locked-down VM or Cloud PC reserved exclusively for Tier 0 tasks, RDP'd into from a standard workstation but never directly logged into with Tier 0 credentials on the workstation itself.

Authentication policies and silos

Windows Server 2012 R2+ domains support Authentication Policies and Authentication Policy Silos, which enforce tier boundaries at the Kerberos KDC level rather than relying only on GPO logon rights — a defense-in-depth layer that survives even if a GPO fails to apply.

# Create a silo restricting Tier 0 admins to PAW and DC access
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
    -UserAuthenticationPolicy "Tier0-UserAuthPolicy" `
    -ComputerAuthenticationPolicy "Tier0-ComputerAuthPolicy" `
    -Enforce

# Membership is two-sided: permit the account in the silo, then assign the silo to the account
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "adm-t0-famette"
Set-ADAccountAuthenticationPolicySilo -Identity "adm-t0-famette" -AuthenticationPolicySilo "Tier0-Silo"

Authentication policies can also cap the Kerberos TGT lifetime for silo members, shrinking the window an attacker has if a ticket is stolen.

Cleaning out Domain Admins and Enterprise Admins

Audit membership regularly — these groups accumulate stale entries for years.

# List current Domain Admins and Enterprise Admins
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Find accounts that haven't logged on in 90+ days but remain privileged
$cutoff = (Get-Date).AddDays(-90)
Get-ADGroupMember -Identity "Domain Admins" |
    Get-ADUser -Properties LastLogonDate |
    Where-Object { $_.LastLogonDate -lt $cutoff -or -not $_.LastLogonDate }

Target state: Enterprise Admins should be empty except during scheduled forest-level changes (schema updates, new domain adds), then emptied again afterward. Domain Admins should contain only the small set of named Tier 0 administrator accounts — not service accounts, not "just in case" accounts, not vendor accounts.

# Verify a specific user right assignment (e.g., deny log on locally) applied via GPO
Get-ADGroup "Tier 1 Admins" | Select-Object -ExpandProperty SID
# Cross-check the effective user rights on the target host (includes domain GPOs):
secedit /export /cfg "$env:TEMP\rights.inf" /areas USER_RIGHTS
Select-String -Path "$env:TEMP\rights.inf" -Pattern "SeDenyInteractiveLogonRight"

What it breaks

• Scheduled tasks and services running as Domain Admin accounts on member servers or workstations will fail immediately once deny-logon-as-a-batch-job/service rights apply. Inventory every scheduled task and service with Get-ScheduledTask / Get-CimInstance Win32_Service filtered on privileged account names before rollout, then migrate them to Group Managed Service Accounts (gMSAs) scoped to Tier 1.
• Delegated help desk workflows that rely on a shared "admin" account for both password resets and server troubleshooting stop working across tiers — you must delegate password-reset rights via OU-scoped delegation instead of tier-crossing accounts.
• Protected Users membership breaks NTLM-dependent legacy applications, cached logon on non-DC machines, and Kerberos ticket renewal past 4 hours — pilot before wide deployment.
• PAW-only Tier 0 access slows down emergency response unless you provision at least one break-glass path (a documented, monitored, physically-secured procedure) for DC recovery when the PAW itself is unavailable.

Related reading: Kerberos hardening for the authentication layer underneath these accounts, and Delegation for the constrained-delegation risks that can bypass tier boundaries. See also the glossary entries for Protected Users and DCSync.