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

One of the most impactful security improvements an organization can make to its Active Directory environment is implementing Microsoft’s Active Directory Tiered Administration Model. This model addresses a fundamental weakness in traditional flat-administration environments: the credential theft attack path. When domain administrators routinely log on to workstations and member servers, their highly privileged credentials are exposed to whatever malware or attacker has access to those lower-trust systems. A single compromised workstation can then pivot to full domain compromise through pass-the-hash or pass-the-ticket attacks. The tiered model breaks this attack path by strictly segregating administrative accounts, workstations, and systems by trust level — ensuring that Tier 0 (domain controller–level) credentials never touch Tier 1 (server) or Tier 2 (workstation) systems. This guide walks through implementing the three-tier model on Windows Server 2025 using Group Policy, Active Directory controls, and PowerShell.

Prerequisites

Windows Server 2025 Active Directory domain with at least one domain controller
Domain Admin or Enterprise Admin credentials for initial setup
Group Policy Management Console (GPMC) installed
Active Directory module for PowerShell (RSAT-AD-PowerShell)
At least one dedicated Privileged Access Workstation (PAW) available for Tier 0 administration
Documented inventory of servers, workstations, and services in the environment

Step 1: Understand the Three Tiers

The tiered model defines three trust levels, each with its own admin accounts, workstations, and logon restrictions:

Tier 0: The highest trust level. Includes domain controllers, AD DS, Azure AD Connect sync servers, AD FS servers, PKI/CA servers, and anything that directly controls identity. Tier 0 admins (T0-Admins) have privileges that, if compromised, result in full domain compromise.
Tier 1: Member servers, enterprise applications, cloud management planes (Azure subscriptions, VMware vCenter). Tier 1 admins (T1-Admins) are local administrators on servers but have no AD admin privileges.
Tier 2: End-user workstations, desktops, and laptops. Tier 2 admins (T2-Admins) provide helpdesk-level support — resetting passwords, managing standard user accounts — but have no elevated access to servers or domain controllers.

# Install AD PowerShell module on Windows Server 2025
Install-WindowsFeature RSAT-AD-PowerShell -IncludeManagementTools

# Create top-level Tier OUs to organize accounts and systems
$domainDN = (Get-ADDomain).DistinguishedName

New-ADOrganizationalUnit -Name "Tier 0" -Path $domainDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Tier 1" -Path $domainDN -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Tier 2" -Path $domainDN -ProtectedFromAccidentalDeletion $true

# Sub-OUs for accounts, groups, devices per tier
foreach ($tier in @("Tier 0","Tier 1","Tier 2")) {
    $tierDN = "OU=$tier,$domainDN"
    New-ADOrganizationalUnit -Name "Accounts"   -Path $tierDN -ProtectedFromAccidentalDeletion $true
    New-ADOrganizationalUnit -Name "Groups"     -Path $tierDN -ProtectedFromAccidentalDeletion $true
    New-ADOrganizationalUnit -Name "Devices"    -Path $tierDN -ProtectedFromAccidentalDeletion $true
    New-ADOrganizationalUnit -Name "Service Accounts" -Path $tierDN -ProtectedFromAccidentalDeletion $true
}

Step 2: Create Separate Administrator Accounts per Tier

Each administrator in the organization must have distinct accounts for each tier they are authorized to administer. An engineer who manages both domain controllers and servers requires a T0 account for DC work and a separate T1 account for server work — these accounts must never be used interchangeably. Standard user accounts (for reading email and browsing) are completely separate from all admin accounts.

$tier0OU = "OU=Accounts,OU=Tier 0,$domainDN"
$tier1OU = "OU=Accounts,OU=Tier 1,$domainDN"
$tier2OU = "OU=Accounts,OU=Tier 2,$domainDN"

# Create Tier 0 admin account (domain admin level)
$t0SecurePass = Read-Host "T0 Admin Password" -AsSecureString
New-ADUser -Name "T0-JSmith" `
    -SamAccountName "T0-JSmith" `
    -UserPrincipalName "[email protected]" `
    -Path $tier0OU `
    -AccountPassword $t0SecurePass `
    -Enabled $true `
    -PasswordNeverExpires $false `
    -Description "Tier 0 admin account for John Smith — DC/AD administration only"

# Create Tier 1 admin account (server admin level)
$t1SecurePass = Read-Host "T1 Admin Password" -AsSecureString
New-ADUser -Name "T1-JSmith" `
    -SamAccountName "T1-JSmith" `
    -UserPrincipalName "[email protected]" `
    -Path $tier1OU `
    -AccountPassword $t1SecurePass `
    -Enabled $true `
    -Description "Tier 1 admin account for John Smith — member server administration only"

# Create Tier 2 admin account (helpdesk level)
$t2SecurePass = Read-Host "T2 Admin Password" -AsSecureString
New-ADUser -Name "T2-JSmith" `
    -SamAccountName "T2-JSmith" `
    -UserPrincipalName "[email protected]" `
    -Path $tier2OU `
    -AccountPassword $t2SecurePass `
    -Enabled $true `
    -Description "Tier 2 admin account for John Smith — workstation and user support only"

# Add T0 account to Domain Admins (only T0 accounts should be DA)
Add-ADGroupMember -Identity "Domain Admins" -Members "T0-JSmith"

Step 3: Add Tier 0 Accounts to Protected Users Group

The Protected Users security group, available since Windows Server 2012 R2, enforces strong credential protections on its members: credentials are not cached in LSASS, NTLM authentication is disabled, DES and RC4 are disabled for Kerberos, and Kerberos TGTs are limited to 4-hour lifetimes. All Tier 0 accounts should be members of this group.

# Add Tier 0 admin accounts to Protected Users
$tier0Accounts = Get-ADUser -SearchBase $tier0OU -Filter * | Select-Object -ExpandProperty SamAccountName

foreach ($account in $tier0Accounts) {
    Add-ADGroupMember -Identity "Protected Users" -Members $account
    Write-Host "Added $account to Protected Users"
}

# Verify Protected Users membership
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName, DistinguishedName

# IMPORTANT: Test that Protected Users membership does not break any service accounts
# before broadly applying. Protected Users cannot use NTLM, Kerberos delegation, or DES/RC4.
# Service accounts that require delegation must NOT be in Protected Users.
Get-ADUser -SearchBase $tier0OU -Filter * -Properties MemberOf |
    Where-Object { $_.MemberOf -match "Protected Users" } |
    Select-Object SamAccountName, Enabled

Step 4: Implement Logon Restrictions via Group Policy

The critical enforcement mechanism of the tiered model is preventing tier credential cross-contamination at logon time. A T0 admin account must never be able to interactively log on to a Tier 1 server or Tier 2 workstation. Conversely, T2 accounts must not be able to log on to servers. These restrictions are implemented via GPO User Rights Assignments.

# Create and link GPO: Deny Tier 0 accounts from logging on to Tier 1 servers
# (Do this in GPMC GUI or via PowerShell using GroupPolicy module)
Import-Module GroupPolicy

# Create GPO for Tier 1 servers
$t1GPO = New-GPO -Name "Tier1-Server-Logon-Restrictions" -Comment "Block T0 creds on T1 servers"
New-GPLink -Name "Tier1-Server-Logon-Restrictions" `
    -Target "OU=Devices,OU=Tier 1,$domainDN" `
    -LinkEnabled Yes

# Use secedit/INF to configure User Rights via PowerShell
# The following shows the INF content that would be applied:
$infContent = @"
[Privilege Rights]
; Deny interactive logon for Tier 0 accounts on this tier
SeDenyInteractiveLogonRight = *S-1-5-21-DOMAIN-T0ADMINS-SID
SeDenyRemoteInteractiveLogonRight = *S-1-5-21-DOMAIN-T0ADMINS-SID
SeDenyNetworkLogonRight = *S-1-5-21-DOMAIN-T0ADMINS-SID
SeDenyBatchLogonRight = *S-1-5-21-DOMAIN-T0ADMINS-SID
SeDenyServiceLogonRight = *S-1-5-21-DOMAIN-T0ADMINS-SID
"@

# Get SID of Tier 0 Admins group to use in policy
$t0AdminGroup = Get-ADGroup -Identity "Tier0-Admins"
$t0AdminSID   = $t0AdminGroup.SID.Value
Write-Host "Tier 0 Admins SID: $t0AdminSID"

# Restrict Tier 0 logon using userWorkstations AD attribute (complementary approach)
# This prevents T0 accounts from logging on to any computer not listed
$t0PAWName = "T0-PAW01"
Set-ADUser -Identity "T0-JSmith" -Replace @{ userWorkstations = $t0PAWName }

Step 5: Configure Privileged Access Workstations per Tier

Each tier requires dedicated Privileged Access Workstations (PAWs). A Tier 0 PAW is a locked-down workstation used exclusively by T0 admins to manage domain controllers — it has no internet access, no email client, and all inbound/outbound traffic is restricted to management protocols. Tier 1 PAWs are used by server admins and may allow more tools but are still isolated from internet browsing.

# Move PAW computers into their respective tier Device OUs
$t0PAWDN = "CN=T0-PAW01,CN=Computers,$domainDN"
Move-ADObject -Identity $t0PAWDN -TargetPath "OU=Devices,OU=Tier 0,$domainDN"

$t1PAWDN = "CN=T1-SRV-MGMT01,CN=Computers,$domainDN"
Move-ADObject -Identity $t1PAWDN -TargetPath "OU=Devices,OU=Tier 1,$domainDN"

# Create a Restricted Groups GPO to ensure only T0 admins are in local admin group on T0 PAWs
# (Prevents privilege escalation by non-T0 accounts on PAWs)
$pawGPO = New-GPO -Name "Tier0-PAW-Restricted-Groups"
New-GPLink -Name "Tier0-PAW-Restricted-Groups" `
    -Target "OU=Devices,OU=Tier 0,$domainDN" `
    -LinkEnabled Yes

# Apply Windows Defender Firewall rules to T0 PAWs (block internet, allow only DC management ports)
$fwRuleBlock = New-NetFirewallRule `
    -DisplayName "Block Internet Outbound from T0 PAW" `
    -Direction Outbound `
    -Action Block `
    -RemoteAddress Internet `
    -Profile Domain `
    -Enabled True

# Allow only RDP, WinRM, SMB to Tier 0 systems (e.g., DC subnet 10.0.0.0/24)
New-NetFirewallRule `
    -DisplayName "Allow DC Management Outbound" `
    -Direction Outbound `
    -Action Allow `
    -RemoteAddress "10.0.0.0/24" `
    -RemotePort @(3389, 5985, 5986, 445, 135) `
    -Protocol TCP `
    -Profile Domain `
    -Enabled True

Step 6: Create Emergency Access (Break-Glass) Accounts

Break-glass accounts are emergency Tier 0 accounts kept offline and locked away, used only when all normal admin accounts are unavailable (e.g., during an Azure AD outage or if all T0 admins are locked out). These accounts must be excluded from all conditional access policies and MFA requirements while being tightly audited.

# Create two break-glass accounts (two separate accounts for redundancy)
$bgPass1 = Read-Host "Break-Glass Account 1 Password (32+ chars)" -AsSecureString
New-ADUser -Name "BG-Emergency-01" `
    -SamAccountName "BG-Emergency-01" `
    -Path "OU=Accounts,OU=Tier 0,$domainDN" `
    -AccountPassword $bgPass1 `
    -Enabled $true `
    -PasswordNeverExpires $true `
    -Description "BREAK-GLASS: Emergency Tier 0 access. Audit any use immediately."

Add-ADGroupMember -Identity "Domain Admins" -Members "BG-Emergency-01"
Add-ADGroupMember -Identity "Enterprise Admins" -Members "BG-Emergency-01"

# Set fine-grained password policy: even longer, more complex password required
$pso = New-ADFineGrainedPasswordPolicy `
    -Name "BreakGlass-PSO" `
    -Precedence 1 `
    -MinPasswordLength 32 `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false `
    -MaxPasswordAge "0" `
    -LockoutThreshold 3 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00"

Add-ADFineGrainedPasswordPolicySubject -Identity "BreakGlass-PSO" -Subjects "BG-Emergency-01"

# Create an audit script to alert on any use of break-glass accounts
# Schedule this as a task that runs every 15 minutes
$auditScript = @'
$events = Get-WinEvent -ComputerName "DC01" -LogName Security -FilterXPath `
    "*[System[(EventID=4624 or EventID=4648)] and EventData[Data[@Name='TargetUserName']='BG-Emergency-01']]" `
    -ErrorAction SilentlyContinue
if ($events) {
    Send-MailMessage -To "[email protected]" `
        -From "[email protected]" `
        -Subject "ALERT: Break-Glass Account Used" `
        -Body ($events | Select-Object TimeCreated,Message | Out-String) `
        -SmtpServer "smtp.progressiverobot.com"
}
'@
$auditScript | Out-File "C:ScriptsMonitor-BreakGlass.ps1" -Encoding UTF8

Conclusion

Implementing the Active Directory Tiered Administration Model on Windows Server 2025 is one of the highest-return security investments an organization can make. By creating dedicated administrator accounts for each trust tier, enforcing logon restrictions through Group Policy, adding Tier 0 accounts to the Protected Users group, and deploying dedicated Privileged Access Workstations, you eliminate the lateral movement paths that attackers most commonly exploit after gaining a foothold on a workstation. The model requires discipline — administrators must form new habits around which account to use for which task — but the security payoff is substantial. Emergency break-glass accounts ensure that the strict controls never lock your team out in a crisis. Over time, complement the tiered model with Just-In-Time (JIT) access via Microsoft Entra PIM, which further reduces the window during which privileged credentials exist and can be stolen.

Links

Newsletter

Contact