How to Set Up Active Directory Tiered Administration Model on Windows Server 2022

Why Flat Administration Models Fail

In many organizations, Active Directory administration evolved organically — every IT staff member who ever needed to manage a server received Domain Admin rights, and those rights were never revoked. Over time, dozens of accounts hold Domain Admin membership, and those credentials are used on every type of machine: workstations for browsing the web, servers running line-of-business applications, and domain controllers. This flat model makes credential theft trivially easy: a single compromised workstation with a cached Domain Admin token is sufficient to compromise the entire domain.

The Microsoft Active Directory Tiered Administration Model (also called the Admin Tier Model) solves this by creating strict boundaries — called tiers — between different classes of systems, and enforcing that credentials used in one tier are never usable in a lower-security tier. This prevents lateral movement: even if an attacker compromises a workstation, they cannot reach a server, and even if they reach a server, they cannot reach a domain controller.

This guide walks through the complete design and implementation of the three-tier model on Windows Server 2022, including Authentication Policy Silos, Protected Users, jump servers, and Group Policy controls.

The Three-Tier Model Defined

The Microsoft tiering model divides the IT environment into three tiers based on the business impact of compromise:

Tier 0 is the control plane. It contains domain controllers, Azure AD Connect servers, AD Certificate Services servers, AD FS servers, and any system that can modify Active Directory itself. Compromise of a Tier 0 asset equals complete domain compromise. Tier 0 administrators are Domain Admins or have equivalent rights. Tier 0 credentials must never touch a Tier 1 or Tier 2 system.

Tier 1 is the server plane. It contains Windows servers running business applications, databases, web servers, file servers, and other infrastructure. Tier 1 administrators can manage these servers but have no rights to domain controllers. Compromise of Tier 1 assets is serious but does not immediately grant domain control.

Tier 2 is the workstation plane. It contains user workstations, laptops, and non-privileged end-user devices. Tier 2 administrators (typically help desk staff) can manage workstations. They have no rights to servers or domain controllers. Compromise of a Tier 2 system should not expose server or domain credentials.

The critical rule is: credentials can only be used at their own tier or above. A Tier 1 admin account must never be used to log into a Tier 2 workstation. If it is, and the workstation is compromised, the Tier 1 credentials are at risk.

Privileged Access Workstations

A Privileged Access Workstation (PAW) is a hardened physical or virtual machine used exclusively for administrative tasks. Each tier should have dedicated PAWs. Tier 0 administrators perform all Tier 0 tasks (including logging into domain controllers) only from Tier 0 PAWs. Tier 1 administrators use Tier 1 PAWs for server management. Regular workstations are Tier 2.

A PAW is hardened differently from a regular workstation: no Office suite, no email client, no web browser (or a locked-down one), no USB access, host-based firewall allowing only required management protocols, full BitLocker encryption, Windows Defender Credential Guard enabled, and application whitelisting. The PAW should not be used for any task other than administration.

PAW hardening in GPO — restrict internet access from PAWs by configuring a proxy that blocks all categories except Microsoft update domains, and block all non-administrative applications via WDAC (Windows Defender Application Control). Apply these settings via a GPO linked to the PAW OU.

Active Directory OU Structure for Tiering

The OU structure should reflect the tiers. Create a top-level Admin OU with sub-OUs for each tier’s accounts, groups, and computers:

New-ADOrganizationalUnit -Name "Admin" -Path "DC=yourdomain,DC=com"
New-ADOrganizationalUnit -Name "Tier0" -Path "OU=Admin,DC=yourdomain,DC=com"
New-ADOrganizationalUnit -Name "Tier1" -Path "OU=Admin,DC=yourdomain,DC=com"
New-ADOrganizationalUnit -Name "Tier2" -Path "OU=Admin,DC=yourdomain,DC=com"

New-ADOrganizationalUnit -Name "Accounts" -Path "OU=Tier0,OU=Admin,DC=yourdomain,DC=com"
New-ADOrganizationalUnit -Name "Groups" -Path "OU=Tier0,OU=Admin,DC=yourdomain,DC=com"
New-ADOrganizationalUnit -Name "Devices" -Path "OU=Tier0,OU=Admin,DC=yourdomain,DC=com"

Each tier has dedicated admin accounts (e.g., adm0-jsmith for Tier 0, adm1-jsmith for Tier 1, adm2-jsmith for Tier 2). These are separate accounts from the user’s regular account. The regular user account is Tier 2 by default — it is used for email, browsing, and day-to-day work.

Preventing Credential Exposure with Logon Restrictions

The most critical enforcement mechanism is preventing privileged accounts from logging onto lower-tier systems. Use the User Rights Assignment policies in GPO to configure Deny log on locally, Deny log on through Remote Desktop Services, and Deny log on as a service for higher-tier admin groups on lower-tier systems.

Create and link a GPO to the Workstations OU that denies Tier 0 and Tier 1 admins from logging in:

# On domain controller, create the GPO
New-GPO -Name "Tier2 - Deny Privileged Logon"
New-GPLink -Name "Tier2 - Deny Privileged Logon" -Target "OU=Workstations,DC=yourdomain,DC=com"

Then in the GPO’s Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, add the Tier0-Admins and Tier1-Admins groups to:

– Deny access to this computer from the network

– Deny log on locally

– Deny log on through Remote Desktop Services

Similarly, create a GPO linked to the Servers OU that denies Tier 0 admins from logging in interactively (they should only access servers from Tier 1 jump servers, never directly). And create a GPO for domain controllers that denies Tier 1 and Tier 2 accounts from logging in.

Authentication Policy Silos

Authentication Policy Silos, introduced in Windows Server 2012 R2 and fully supported in Windows Server 2022, provide an Active Directory-level enforcement mechanism that restricts which computers a user can obtain service tickets for. Unlike GPO-based restrictions (which are enforced by the target machine), silos are enforced by the KDC (domain controller) — even if a workstation is compromised and its policies are bypassed, the DC will not issue a Kerberos service ticket allowing a Tier 0 account to authenticate to a Tier 2 workstation.

Create an Authentication Policy Silo for Tier 0:

New-ADAuthenticationPolicySilo `
    -Name "Tier0-Silo" `
    -Description "Restricts Tier 0 accounts to Tier 0 computers only" `
    -Enforce

Create an Authentication Policy that restricts user logon to Tier 0 computers. First, create the policy:

New-ADAuthenticationPolicy `
    -Name "Tier0-UserPolicy" `
    -Description "Tier 0 admins can only log on to Tier 0 devices" `
    -UserAllowedToAuthenticateTo "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == `"Tier0-Silo`"))" `
    -Enforce

The SDDL expression above means: allow access only if the computer the user is authenticating to is also a member of Tier0-Silo. Assign the policy to the silo:

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -UserAuthenticationPolicy "Tier0-UserPolicy"

Assign Tier 0 admin accounts and Tier 0 computers to the silo:

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "adm0-jsmith"
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "DC01$"
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "AzureADConnect01$"

Set-ADUser -Identity "adm0-jsmith" -AuthenticationPolicySilo "Tier0-Silo"
Set-ADComputer -Identity "DC01" -AuthenticationPolicySilo "Tier0-Silo"

Protected Users Security Group

The Protected Users group is a special security group in Active Directory (available since Windows Server 2012 R2) that applies additional protections to member accounts automatically, without GPO configuration. Tier 0 administrative accounts should always be members.

Protections applied to Protected Users members:

– Kerberos authentication only (NTLM authentication is blocked for these accounts)

– No Kerberos ticket delegation (prevents pass-the-ticket attacks via delegated services)

– Kerberos TGT lifetime limited to 4 hours (instead of the default 10 hours)

– No long-term credential caching on workstations (no cached credentials)

– DES and RC4 encryption types are not used

Add Tier 0 accounts to Protected Users:

Add-ADGroupMember -Identity "Protected Users" -Members "adm0-jsmith", "adm0-bwilliams", "Administrator"

Note: Before adding service accounts to Protected Users, verify that no service depends on NTLM authentication or Kerberos delegation, as those features will break for Protected Users members.

Jump Servers Per Tier

Jump servers (also called jump hosts or bastion hosts) are intermediary management servers through which admins connect to target systems. Rather than allowing RDP directly from a PAW to a production server, the admin RDPs to the tier’s jump server, and from there connects to the target. This reduces the network exposure of production systems and centralizes session logging and recording.

Deploy one or more jump servers per tier. Tier 1 jump servers should be dedicated Windows Server 2022 members accessible only from Tier 1 PAWs. Configure them with:

– Remote Desktop Gateway role (for encrypted, audited RDP sessions)

– Windows Defender Application Control (only admin tools allowed)

– No internet access

– Session recording if compliance requires it

Install Remote Desktop Gateway on the jump server:

Install-WindowsFeature RDS-Gateway -IncludeManagementTools

Configure RD Gateway CAP (Connection Authorization Policy) to allow only Tier 1 admin groups to connect, and RAP (Resource Authorization Policy) to allow connections only to Tier 1 servers.

Administrative Forest (ESAE / Red Forest)

For the highest-security environments, Microsoft’s Enhanced Security Administrative Environment (ESAE) — also called the Red Forest model — creates a separate, hardened Active Directory forest that contains only the privileged administrative accounts. The production forest trusts the admin forest (one-way trust), but the admin forest does not trust the production forest. Attackers who compromise the production forest cannot reach the admin forest’s credentials.

While full ESAE deployment is a major architectural project, the core concept can be partially implemented by creating shadow admin accounts in a separate dedicated admin OU with strict access controls, using those accounts exclusively for administrative tasks, and protecting the OU with AdminSDHolder permissions. For full ESAE, establish a new forest, create a one-way trust from production to admin:

New-ADTrust `
    -Name "admforest.local" `
    -TrustType External `
    -Direction Inbound `
    -TrustingDomainName "production.local" `
    -TrustedDomainName "admforest.local" `
    -Confirm:$false

Note: Microsoft has indicated that ESAE is a legacy reference architecture and recommends using Azure PIM and cloud-based PAM solutions for new deployments. However, the on-premises ESAE model remains valid for air-gapped or hybrid environments.

Auditing Tier Violations

Enable advanced audit policy to detect when a privileged account logs onto a system it should not. The key event IDs are 4624 (successful logon), 4625 (failed logon), and 4648 (explicit credential use — pass-the-hash indicator).

Configure advanced audit policy via GPO (Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration) or PowerShell:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

Create a scheduled task or script that queries the Security event log on workstations for Tier 0 or Tier 1 account logons (Event ID 4624 with a subject matching admin account naming conventions). Alert the security team when a Tier 0 account is detected logging onto a Tier 2 workstation:

Get-WinEvent -ComputerName "workstation01" -FilterHashtable @{
    LogName = "Security"
    Id = 4624
    StartTime = (Get-Date).AddHours(-24)
} | Where-Object { $_.Properties[5].Value -like "adm0-*" }

Forward all security events from domain controllers and jump servers to a SIEM via Windows Event Forwarding or a SIEM agent to enable centralized detection of tier violations.

Summary

The Active Directory Tiered Administration Model significantly raises the cost of credential-based attacks. By separating the domain control plane (Tier 0) from server administration (Tier 1) and workstation administration (Tier 2), enforcing those boundaries through GPO-based logon restrictions, Authentication Policy Silos, and the Protected Users group, and using dedicated PAWs and jump servers per tier, you prevent the most common attack path — lateral movement from a compromised workstation to full domain compromise. Implementing this model requires organizational discipline: admins must have and use separate accounts per tier, and violations must be monitored and remediated promptly.