Implementing the Active Directory Tier Model: A Practical Guide for Post-Netlogon Environments

The Microsoft Active Directory Tier Model — formalised as the Privileged Access Model in recent documentation — addresses the root cause of why domain controller compromises like CVE-2026-41089 result in complete domain compromise: the absence of privilege boundaries that prevent credentials from one tier of the environment from being used in another.

The model is conceptually simple but organisationally challenging to implement. This guide provides a practical implementation sequence for organisations beginning the process.

The Core Principle

Credentials from lower privilege tiers must never flow upward into higher privilege tiers. Concretely:

• Tier 0 (Domain Controllers, PKI, AD Connect, Tier 0 management): Administrators log in from PAWs; accounts are not used for any other purpose
• Tier 1 (Servers, cloud management): Server administrators use Tier 1 administrative accounts; these accounts cannot authenticate to Tier 0 systems
• Tier 2 (Workstations, user devices): Helpdesk and desktop administrators use Tier 2 accounts; these cannot authenticate to Tier 1 or Tier 0 systems

The boundaries between tiers are enforced by a combination of group policy, account configuration, and network controls. Violation of the principle — an administrator using their Domain Admin account to browse the web, or logging into a DC from a regular workstation — creates the cross-tier credential exposure that makes cascading compromise possible.

Implementation Sequence

The Tier Model cannot be implemented overnight without risk. The recommended sequence:

Phase 1: Account Separation (2–4 weeks)

Create separate administrative accounts for each tier:

• T0-username accounts for domain and Tier 0 infrastructure administration
• T1-username accounts for server administration
• T2-username accounts for workstation and user support

These accounts should have no standard user privileges — no email, no web access, no applications beyond administrative tools.

Existing domain admin accounts that have been used as daily-use accounts should be replaced with Tier 2 accounts for daily use and Tier 0 accounts for administrative tasks.

Phase 2: Logon Restriction Enforcement (2–4 weeks)

Configure Group Policy to enforce logon restrictions by tier. The critical control is preventing Tier 0 accounts from authenticating to non-Tier-0 systems:

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment:
- "Deny log on locally" on workstations and Tier 1 servers: add T0-Admins group
- "Deny log on through Remote Desktop Services" on workstations and Tier 1 servers: add T0-Admins group
- "Deny access to this computer from the network" on workstations: add T0-Admins group

Test these restrictions in a lab environment before deploying to production — incorrect Group Policy application can lock administrators out of systems.

Phase 3: Privileged Access Workstations for Tier 0 (4–8 weeks)

Privileged Access Workstations (PAWs) for Tier 0 are dedicated machines used only for domain controller administration:

• Dedicated physical hardware (preferred) or hardened VMs not connected to general user networks
• No internet access — use a dedicated management network segment
• Minimal software: Windows, administrative tools (ADUC, DNS Manager, Group Policy Management), security monitoring agent
• BitLocker encryption, UEFI Secure Boot, Windows Defender Application Control limiting to approved applications
• No email, no browser, no document applications

All Tier 0 administrative work — domain controller logon, AD administration, PKI management — done only from PAW machines.

Phase 4: Network Isolation (4–8 weeks)

Network controls that enforce the tier model at the infrastructure level:

• Tier 0 subnet (DC network) accessible only from PAW subnet and other Tier 0 infrastructure
• PAW subnet accessible only for administrative purposes — outbound to Tier 0 targets, no internet
• Management VLAN for Tier 1 server administration separated from user VLAN
• Workstation segment cannot reach DC subnet on authentication protocol ports (see DC hardening guide from May 29)

Phase 5: Monitoring and Audit

Instrument the tier boundaries for detection:

• Alert on Tier 0 accounts authenticating to non-Tier-0 systems (Event ID 4624 with T0-Admins logon on workstations)
• Alert on privileged account use from non-PAW source IPs for DC authentication
• Quarterly access review: ensure no accounts are members of multiple tier admin groups

What This Would Have Changed for CVE-2026-41089

In a properly implemented Tier Model environment with Phase 1–4 complete:

• DC network access restricted to PAW subnet → attacker with access to a workstation cannot reach DC TCP 445
• T0 administrative accounts not cached on workstations → LSASS dumps from workstations yield no DC credentials
• PAWs with no internet access → initial phishing or web-based initial access cannot reach PAWs

The vulnerability would still require patching. But exploitation from a workstation-level initial access — the most common enterprise attack path — would be prevented by the tier boundary controls.