Tiered Administration Guide: Tier 0, PAWs and Clean Source

When a Domain Admin signs in to an ordinary workstation or server, any attacker who already controls that machine can take the credential and, with it, the whole directory. Tiered administration separates the identities, devices and systems that control the directory from everything their credentials could be stolen from. This guide goes deeper than the Active Directory and Entra ID Hardening Guide on that one design: the Microsoft enterprise access model, how to define Tier 0 (tier zero), the clean source principle, privileged access workstations, authentication policy silos, Protected Users, and what to do with an existing ESAE or red forest. It is written for identity architects and directory engineers planning or repairing an admin tiering model.

Key takeaways

• Tier 0 is defined by control, not by server type. Anything that can directly or indirectly control the directory, including backup, hypervisor and EDR systems with agents on domain controllers, is Tier 0.
• The credential and the keyboard define the tier. Microsoft's tier model states that higher-tier credentials are never used on lower-tier systems, and that a Tier 0 session must originate from a Tier 0 privileged access workstation.
• Clean source means every dependency is at least as trusted as what it controls. A hardened admin account used from a phishable laptop inherits the laptop's risk.
• Enforce tiers technically. Authentication policy silos, Protected Users, deny-logon user rights and Conditional Access turn a tiering diagram into real boundaries.
• ESAE is no longer the default. Microsoft replaced the Enhanced Security Admin Environment (red forest) with its privileged access strategy and rapid modernization plan, and now treats ESAE as a custom configuration for exception cases.

From the AD tier model to the enterprise access model

The original AD tiering model (the tier zero model) split administration into three tiers so that a compromise at a lower tier could not climb upward. Microsoft states that "the enterprise access model builds on the AD tier model", which remains "a component of the EAM as a key method for preventing unauthorized privilege escalation". The Microsoft enterprise access model widens the scope to multiple clouds, partners, customers and APIs.

Microsoft states that "Tier 0 expands to become the control plane and addresses all aspects of access control". Across all planes sit privileged access pathways, which "must be stringently protected against compromise". In practice, AD tiering implements the control plane boundary for Active Directory, and the wider model extends it to Entra ID, Azure and SaaS as part of the privileged access strategy.

Defining Tier 0: what is a control plane asset

Microsoft's tier model defines Tier 0 as "assets and identities that directly or indirectly control the directory service and enterprise-wide permissions". The 2024 Five Eyes guidance on detecting and mitigating Active Directory compromises recommends "a tiered model, such as Microsoft's Enterprise Access Model". A workable inventory of Tier 0 assets, or control plane assets, has four groups.

The third row is where most programmes under-scope. If the backup product can restore a domain controller, or a console can push software to it, its administrators hold Tier 0 access whatever their job title says; whoever administers the hypervisor hosting a virtual domain controller can read its disk. Either move those systems into Tier 0, or give domain controllers a separate instance. Write the list down, name an owner, and review it whenever a new agent, integration or role touches identity infrastructure.

The clean source principle

Microsoft's definition is short: "The clean source principle requires all security dependencies to be as trustworthy as the object being secured." It continues: "Any subject in control of an object is a security dependency of that object. If an adversary can control anything in control of a target object, they can control that target object." And: "the trust level of the source must be the same or higher than the destination."

Applied to administration, the chain runs from device through intermediary to target:

• Device: the workstation where the administrator types is a dependency of every system they manage. Microsoft's tier model puts it plainly: "Trust starts at the first physical keyboard used to sign in."
• Intermediary: a jump server or PAM session host is a dependency of everything reached through it, so one managed from Tier 1 cannot host Tier 0 sessions.
• Account: the password reset path, MFA registration and group memberships are dependencies. If the help desk can reset a Tier 0 password, Tier 0 is only as strong as the help desk.
• Management tooling: GPOs linked to Tier 0 OUs and whoever can edit them.

The common violation is a PAW run as a virtual machine on an ordinary laptop, or a Tier 0 remote desktop session opened from a daily-use device: the less trusted host controls the keyboard, screen and memory of the more trusted session. Microsoft also says its personal device exception "cannot be extended to specialized security and privileged security levels".

Privileged access workstations

A privileged access workstation (PAW), sometimes called a secure admin workstation, is a dedicated, hardened device used only for privileged work. Microsoft describes it as "the highest security configuration designed for extremely sensitive roles" and notes that it blocks "the most common vector for phishing attacks: email and web browsing". Microsoft's device profiles show how a PAW differs from other managed devices.

Microsoft adds Credential Guard, BitLocker on all disks and a hardware root of trust (TPM 2.0, UEFI Secure Boot, HVCI, DMA protection, System Guard) deployed with Windows Autopilot.

• One PAW per tier: Microsoft's tier model calls for "a Tier 0 PAW for Tier 0 assets, a Tier 1 PAW for Tier 1, and a Tier 2 PAW for Tier 2". For cloud landing zones it names a Privileged Access Workstation for Cloud Services Management (PAWCSM).
• Separate productivity device: email and browsing happen elsewhere with a standard account; Microsoft calls this "a necessary control".
• Management independence: use cloud-managed PAWs (Entra join, cloud device management) so on-premises management cannot become a back door.
• Enforcement: require compliant PAWs in Conditional Access for privileged roles, and restrict where Tier 0 accounts can sign in on-premises. A PAW nobody is forced to use is a spare laptop.

For the Windows build itself, see the Windows Endpoint Hardening Guide.

Active Directory tiering in practice

Microsoft's tier model design principles are the rules engineers will argue about:

• No shared credentials across tiers: "An account, service account, or group must operate in a single tier."
• Containment, not perimeter: "Network segmentation supports the model but doesn't replace it. The credential and the keyboard define the tier, not the IP address."
• No upward sessions from lower tiers: "Lower-tier workstations never initiate sessions to higher-tier endpoints by using higher-tier credentials."

The reason is credential exposure: a privileged sign-in can leave reusable credential material on the host, which an attacker with local admin can harvest (MITRE ATT&CK T1003.001 LSASS Memory) and reuse as a valid domain account (T1078.002). ATT&CK's Privileged Account Management mitigation (M1026) for Valid Accounts includes limiting privileged account use across administrative tiers. See the Credential Dumping Guide.

Building the structure

• Tier 0 OU: put Tier 0 accounts, groups, servers and PAWs in a dedicated OU tree whose permissions only Tier 0 administrators can change, with no delegation to help desk or server teams.
• Separate accounts per tier: one account per tier administered plus a standard user account.
• Logon restrictions by GPO: on Tier 1 and Tier 2 computers, assign the user rights "Deny log on locally", "Deny log on through Remote Desktop Services", "Deny access to this computer from the network", "Deny log on as a batch job" and "Deny log on as a service" to the Tier 0 groups (and on Tier 2, to Tier 1 groups). Blunt, but easy to audit.
• Service accounts: an account running on Tier 1 servers must not hold Tier 0 rights.

Authentication policies and silos

Deny-logon rights live on each target computer, so a new or misconfigured machine has no protection. An authentication silo moves the decision to the domain controller: Microsoft describes silos as "containers to which administrators can assign user accounts, computer accounts, and service accounts", governed by an authentication policy, to "limit high-value account usage to high-value hosts".

• Allowed to authenticate from: restricts the devices from which an account can obtain a TGT, for example only Tier 0 PAWs and domain controllers; this needs Kerberos armoring.
• Allowed to authenticate to: restricts which services the account can get tickets for.
• TGT lifetime and NTLM: TGTs are non-renewable, so a short lifetime limits a stolen ticket; NTLM is rejected because restrictions cannot be applied to it.
• Audit, then enforce: an unenforced policy runs in audit mode and logs potential denials as events 305 (TGT) and 306 (service ticket) in the Microsoft-Windows-Authentication AuthenticationPolicyFailures-DomainController log. Enforced denials appear as 105 and 106, NTLM failures as 101.

Microsoft's own example is a Forest Administrators silo containing enterprise, schema and domain administrators, configured so that authentication "from systems other than domain controllers and domain administrator consoles would fail". That is a Tier 0 silo. Protocol detail on armoring and ticket behaviour is in the Kerberos Security Guide.

The Protected Users group

The Protected Users group is the simplest control for human Tier 0 accounts. Members get no cached plaintext credentials for CredSSP or Digest, no NTLM NTOWF caching, no DES or RC4 keys and no offline sign-in verifier, and domain controllers refuse them NTLM, DES or RC4 pre-authentication and any delegation, with TGTs capped at four hours.

It needs domain functional level Windows Server 2012 R2 or later and AES-capable accounts. Microsoft warns: "Never add accounts for services and computers to the Protected Users group", and advises testing before adding Domain Admins. Enable the ProtectedUserFailures-DomainController log (disabled by default): event 100 is an NTLM failure, 104 a DES or RC4 pre-authentication failure. The Five Eyes guidance also asks that privileged users are marked "sensitive and cannot be delegated".

Extending tiers to Entra ID and hybrid identity

Hybrid identity is where on-premises Tier 0 meets the cloud control plane, and where tiering most often breaks. Microsoft's guidance is unambiguous: "Fully isolate your Microsoft 365 administrator accounts", cloud-native, phishing-resistant and "Accessed only by using Cloud-managed privileged access workstations". "No on-premises accounts should have administrative privileges in Microsoft 365", and synchronised objects should have no direct or nested privileged cloud role.

• Entra Connect is Tier 0: its on-premises account holds DCSync-level replication rights and its cloud account can set passwords; Microsoft asks for hybrid identity servers to be monitored "as a tier-0 system".
• Federation: AD FS is Tier 0; Microsoft recommends disabling federation for Microsoft 365 where possible, removing that dependency.
• Cloud role holders: make privileged Entra roles eligible rather than permanent and activate them from PAWs; see the JIT Access Guide.

The Storm-0501 hybrid cloud attacks show the cost of skipping this: after reaching Domain Admin, the actor extracted Entra Connect Sync credentials, and in one case a Domain Admin account had a cloud counterpart with the Global Administrator role and MFA disabled.

ESAE and the red forest: history and current status

The Enhanced Security Admin Environment (ESAE), known as the red forest, placed Tier 0 administrative accounts in a separate hardened forest trusted by production. Microsoft's ESAE retirement page now states that its recommendation "has been replaced by the modern privileged access strategy and rapid modernization plan (RAMP) guidance as the default recommended approach for securing privileged users", and that the hardened administrative forest "is now considered a custom configuration suitable only for exception cases".

• Why it was retired: Microsoft says the approach "is based on macro-segmentation techniques" and "doesn't adequately account for hybrid- or cloud-based environments", and that organisations incur "extra risk due to the increased technical complexity and operational costs".
• Where it still fits: isolated on-premises environments where cloud services may be unavailable, such as critical infrastructure or disconnected OT.
• If you already run one: Microsoft says "there's no urgency to retire or replace an ESAE implementation if it's being operated as designed", provided it is patched and supported, and recommends adopting the privileged access strategy for roles ESAE does not cover, including Entra administrators.

Implementing tiered administration: a phased rollout

1. Define Tier 0 against the table above and get the list approved.
2. Reduce before you protect: remove unneeded privileged group members and agents on domain controllers.
3. Issue Tier 0 PAWs and accounts and move Tier 0 administration onto them.
4. Pilot: deny-logon rights on a test OU of Tier 1 servers, and the Tier 0 silo in audit mode; review events 305 and 306 for two to four weeks.
5. Enforce for Tier 0: enforce the silo, add tested accounts to Protected Users, extend deny-logon rights everywhere.
6. Isolate the cloud control plane: cloud-only admins, PAW compliance in Conditional Access.
7. Repeat for Tier 1 with Tier 1 PAWs or hardened intermediaries.
8. Roll back safely: keep a monitored break-glass Tier 0 account outside the silo; returning a policy to audit mode or unlinking a GPO restores access without dismantling the design.

Decision guidance

• Small organisations: separate Tier 0 accounts, a PAW each, Protected Users and deny-logon GPOs; skip Tier 1 PAWs at first.
• Large organisations: full three-tier separation, Tier 0 silos, a Tier 0 owner and change board, PAWCSM for cloud landing zones.
• Physical PAW or virtual: the PAW must be the host, not the guest. Running productivity in a VM on a PAW respects clean source; running a PAW VM on a productivity laptop does not.
• Silos or GPO deny rights: use both; GPO rights are easy to audit, silos are enforced centrally.
• Keep ESAE or migrate: keep a healthy, patched ESAE in disconnected environments; elsewhere, plan the move to the privileged access strategy as the forest reaches its next major change.

Detection and measurement

Monitor the boundaries: event 4624 on Tier 1 and Tier 2 hosts for any Tier 0 account (4625 when deny rights block it); silo events 105, 106, 305 and 306; Protected Users events 100 and 104; changes to Tier 0 groups, OUs and GPOs; and privileged Entra sign-ins from non-PAW devices.

Metrics that show it is working:

• Tier 0 logons on non-Tier 0 hosts per month (target zero).
• Share of Tier 0 human accounts in Protected Users and in an enforced silo.
• Share of privileged sessions originating from PAWs, measured in Entra sign-in logs and remote desktop logs.
• Number of Tier 0 assets, and of people with Tier 0 rights, against the approved list.
• Synchronised accounts holding privileged cloud roles (target zero).

Common failure patterns

• Tier 0 defined as "the domain controllers": backup, hypervisor, EDR and management consoles left in Tier 1 give Tier 1 admins a path to the directory.
• PAWs that are optional: devices issued, but nothing in Conditional Access or AD stops admins using their daily laptop.
• Help desk can reset Tier 0 accounts: a Tier 2 process controls Tier 0 credentials, breaking clean source.
• Shared service accounts: one monitoring account that is local admin everywhere, including domain controllers.
• Synchronised admins: on-premises admins holding cloud roles, as in the Storm-0501 intrusions.
• Silos created but never enforced: audit mode left on indefinitely.

Framework mapping

Practitioner checklist

• Publish an owned Tier 0 asset list covering accounts, groups, identity servers, agents on domain controllers, management platforms and privileged cloud roles.
• Issue cloud-managed Tier 0 PAWs with application control, deny-by-default web access and no local admin rights.
• Apply deny-logon user rights for Tier 0 groups on all Tier 1 and Tier 2 computers.
• Create a Tier 0 authentication policy silo, run it in audit mode, then enforce it.
• Add human Tier 0 accounts to Protected Users after testing, and mark them sensitive and cannot be delegated.
• Keep cloud admin accounts cloud-only, require compliant PAWs in Conditional Access, and remove synchronised accounts from privileged roles.
• Alert on Tier 0 logons to lower-tier hosts and on Tier 0 group and OU changes.
• Decide, document and review the future of any existing ESAE forest.

Standards and references

• Microsoft Learn: Enterprise access model
• Microsoft Learn: Active Directory Domain Services tier model
• Microsoft Learn: Privileged access success criteria (clean source principle)
• Microsoft Learn: Securing devices as part of the privileged access story
• Microsoft Learn: Enhanced Security Admin Environment (ESAE) architecture mainstream retirement
• Microsoft Learn: Authentication policies and authentication policy silos
• Microsoft Learn: Protected Users security group
• ASD, CISA, NSA et al.: Detecting and mitigating Active Directory compromises

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Lateral Movement Guide · Privileged Session Management Guide · Identity Recovery Guide