Active Directory Tiering vs Red Forest: What Replaced ESAE and Why

Many organisations still treat a red forest as the gold standard for protecting Active Directory administrators, yet Microsoft now calls its hardened administrative forest a custom configuration suitable only for exception cases. The Enhanced Security Admin Environment (ESAE), widely known as red forest, moved Tier 0 administrator accounts into a separate, trusted forest. Microsoft's current guidance replaces it with the privileged access strategy, the enterprise access model and the rapid modernization plan (RAMP), which enforce tiering inside the production environment and across cloud control planes. This guide compares the two architectures as a decision: the threat model each was built for, how each fails, why the trust and cost problems pushed Microsoft away from ESAE, what Tier 0 must now include, and the narrow cases where a bastion forest still makes sense. It is written for identity architects and Active Directory owners who run, inherited or are being asked to build a red forest. The Tiered Administration and Enterprise Access Model Guide covers how to build tiering; this page goes deeper on the choice and the move.

Key takeaways

• Tiering in production is the default answer. Microsoft replaced ESAE with the privileged access strategy and RAMP and now limits the hardened forest to exception cases such as isolated or disconnected environments.
• A red forest never removed Tier 0 from production. Domain controllers, Entra Connect, certificate authorities and the service accounts that run them stay in the production forest, so production tiering was always needed anyway.
• The cost was not only servers. A second forest, its trust, its patching and its own administrators add complexity that Microsoft itself names as extra risk, and it protects only on-premises AD administrators, not cloud roles.
• Tier 0 scope decides success. Service accounts in privileged groups, Entra Connect, backup and hypervisor platforms are where both models are most often bypassed.
• Existing red forests need not be torn down in a hurry. Microsoft says there is no urgency to retire one that is operated as designed, but it must be patched, monitored and complemented with cloud control plane protection.

The short answer and the comparison table

Both models aim at the same outcome: an attacker who compromises a workstation or server must not be able to reach credentials that control the directory. They differ in where the boundary sits. ESAE puts it between forests. Tiering puts it between groups of accounts, devices and systems inside the same environment, enforced by logon restrictions, authentication policy silos, privileged access workstations (PAWs) and just-in-time elevation, and extends it to cloud identity planes.

How the red forest worked and what it defended against

Architecture in words: a new, minimal forest is built with its own hardened domain controllers. Production domains trust it, so principals from the bastion forest can be given rights in production. Tier 0 administrators receive dedicated accounts in the bastion forest and use them only from PAWs that belong to that forest. With Microsoft Identity Manager (MIM) PAM, privileged groups are recreated without members in the bastion forest; after an approved request, the admin account is added for a limited time and Windows Server 2016 or later ties the membership to a time limit, producing time-limited Kerberos tickets that trusting forests honour. Microsoft documents that adding a member must replicate across bastion domain controllers, while expiry is evaluated in real time.

Threat model: credential theft and reuse inside production, such as harvesting a Domain Admin's credentials from memory on a compromised server (T1078.002 Domain Accounts, T1550.003 Pass the Ticket). The bet was that if Tier 0 credentials are never typed into production machines and live in a smaller, cleaner forest, theft becomes much harder and the bastion forest remains a known-good place to recover from. Microsoft's MIM PAM documentation states that goal directly: a separate bastion environment known to be unaffected by malicious attacks.

How it failed in practice:

• Production Tier 0 remained: the bastion forest protects accounts, not systems. Anyone with SYSTEM on a production domain controller, the Entra Connect server, an enterprise CA or a backup server with domain controller agents controls production regardless of where administrators live. DCSync (T1003.006) and forged tickets (T1558.001 Golden Ticket) work against production directly.
• Service accounts stayed privileged in production: backup, monitoring and identity sync products often ran with Domain Admin or equivalent rights in the production forest. Microsoft's least privilege guidance notes that placing service accounts in highly privileged groups only changes the composition of those groups.
• Workarounds crept in: when the bastion workflow was slow, engineers kept a production Domain Admin account "for emergencies", and that account became the real path.
• Cloud was out of scope: Global Administrators and other Entra ID roles, and synchronised admin accounts, sat entirely outside the bastion design.
• The bastion became a high-value target of its own: a second forest with fewer operators, older patch levels and a trust into production adds a path, not just a wall.

Why Microsoft retired ESAE: the trust and cost problems

Microsoft's ESAE retirement page gives three reasons. The design is more than ten years old and assumed on-premises AD as the identity provider. It relies on macro-segmentation and does not adequately account for hybrid or cloud environments. And it protects only on-premises AD administrators, not the finer-grained identity controls of a Zero Trust architecture. The page adds that organisations incur extra risk because of the technical complexity and operational cost of maintaining ESAE, and that cloud-based approaches can be deployed faster, protect a broader scope of roles, and need less capital investment.

In practice the cost shows up in four places:

The key strategic point in Microsoft's privileged access strategy is that implementing a PIM or PAM solution alone is not sufficient: every privileged pathway, every intermediary and every device must be trustworthy end to end. A separate forest addresses one pathway. Tiering, PAWs and session controls address all of them.

What replaces it: tiering, the enterprise access model and RAMP

The enterprise access model keeps the tier model's escalation logic and widens it. Tier 0 expands into the control plane, which covers all enterprise access control, including networking where it is the only option, as in legacy OT. Tier 1 splits into the management plane and the data and workload plane. Tier 2 splits into user access and application access. The hierarchy is enforced so that a lower plane cannot gain control of a higher one.

RAMP turns that into three workstreams. Separate and manage privileged accounts covers emergency access accounts, Entra Privileged Identity Management, identifying and categorising privileged Entra roles, separate on-premises AD admin accounts with PAWs, and Microsoft Defender for Identity. Improve credential management experience covers MFA or passwordless for privileged users and blocking legacy authentication for them. Admin workstations initial deployment covers dedicated admin devices. The detailed mechanics of logon restrictions, authentication policy silos and Protected Users are in the Tiered Administration and Enterprise Access Model Guide; PAW builds are in the Privileged Access Workstations Guide.

Threat model of tiering: the same credential theft and lateral movement, plus control plane takeover through cloud roles, sync infrastructure and management tooling. How it fails: exceptions. A single GPO that deploys software to domain controllers from a Tier 1 file share, a helpdesk group that can reset Tier 0 passwords, or a Tier 0 account used once on a Tier 1 server breaks the model. Audit those paths with attack path analysis and the delegation register described in Active Directory Delegation.

Defining Tier 0 scope in both models

Whichever model you run, Tier 0 is anything that can control the identity system. The red forest did not change that list; it only moved the human accounts.

Where identity fits: the non-human identities in this list, especially sync and backup service accounts, are where both models are bypassed most often. Inventory them with owners, rights and credential rotation, and treat their hosts as Tier 0.

When a bastion forest still makes sense

Microsoft keeps a door open. ESAE, or components of it, can still be valid in a limited set of exempted scenarios, typically isolated on-premises environments where cloud services may be unavailable, including critical infrastructure and disconnected OT. MIM PAM is documented as not recommended for new deployments in Internet-connected environments, and as intended for isolated AD environments without Internet access, configurations required by regulation, offline research laboratories and disconnected OT or SCADA environments. Microsoft also notes that it operates a similar architecture internally for its own trusted cloud services.

• Keep or build a bastion when: the AD environment is air-gapped or disconnected, cloud PIM cannot be used, a regulator or contract requires the architecture, or you are a service provider whose AD underpins many customers.
• Do not build one when: the environment is hybrid and Internet-connected, cloud admin roles are the larger risk, or the team cannot staff a second forest with the same rigour as production.
• If you already have one: Microsoft says there is no urgency to retire it if it is operated as designed. Keep it patched and in support, apply extra monitoring, and add the privileged access strategy for everything ESAE does not cover.

Decision criteria by organisation size

Worked scenario: retiring a 2017 red forest

A manufacturer built an ESAE forest in 2017 with MIM PAM. A review finds that six production service accounts are still in Domain Admins, the Entra Connect server is administered from Tier 1 jump servers, three engineers keep standing production Domain Admin accounts, and Global Administrators are synchronised from AD. Its separate OT network has its own AD with no cloud connectivity.

1. Decision: retire ESAE for the corporate forest; keep a bastion-style design for the isolated OT AD, where cloud PIM is not available.
2. Fix production Tier 0 first: remove service accounts from Domain Admins and delegate exact rights, move Entra Connect administration to Tier 0 PAWs, and make all Global Administrators cloud-only with phishing-resistant MFA.
3. Build tiering: Tier 0 OU, separate admin accounts, deny logon rights on Tier 1 and Tier 2, authentication policy silos in audit then enforce, Protected Users for Tier 0 humans.
4. Replace JIT: cloud roles move to PIM; for AD, a small set of named Tier 0 accounts with approval-based elevation through the organisation's PAM tool.
5. Run in parallel: both the bastion groups and production Tier 0 accounts work for one quarter while administrators move.
6. Decommission: empty the bastion-mapped groups, remove the trust, retire MIM and the bastion domain controllers, and archive their logs.
7. Rollback: until the trust is removed, re-enabling bastion group mappings restores the old path; after removal, rollback relies on the break-glass accounts.

Migrating from red forest to tiering

1. Inventory both forests: trusts, groups granted rights from the bastion, MIM roles, PAWs, and every production account with Tier 0 rights, including service accounts.
2. Define Tier 0 for production and cloud: use the asset table above and assign an owner to each item.
3. Protect production Tier 0: PAWs, logon restrictions, silos and least privilege delegation, tested in audit mode first.
4. Move privileged roles: map each bastion group to a production Tier 0 role or a cloud PIM role.
5. Prepare emergency access: two monitored break-glass accounts per plane, see the Break Glass Access Procedure Template.
6. Remove the trust and retire the forest: only after no production permission references a bastion principal.

Detection and measurement

Monitor Tier 0 group changes (Windows events 4728, 4732 and 4756), logons by Tier 0 accounts on non-Tier 0 hosts (event 4624 correlated with your Tier 0 host list), creation of new trusts (event 4706), and changes to Entra Connect and federation settings. Defender for Identity or an equivalent identity threat detection tool adds DCSync and ticket forgery detections.

• Standing Tier 0 membership: number of permanent members of Domain Admins, Enterprise Admins and Administrators, trending to break-glass only.
• Tier 0 credential exposure: Tier 0 logons on lower-tier hosts per month, target zero.
• Service accounts in privileged groups: count, target zero.
• Tier 0 assets with owners: percentage of the Tier 0 list with a named owner and review date.
• Attack paths to Tier 0: number of control paths from Tier 1 or Tier 2 found by attack path analysis.

Common failure patterns

• Treating the red forest as the whole answer: production domain controllers and sync servers remain reachable from lower tiers.
• Leaving sync infrastructure outside Tier 0: in the Storm-0501 hybrid cloud attacks, Entra Connect Sync credentials taken after reaching Domain Admin carried the intrusion into the cloud.
• Standing emergency admin accounts: the fallback becomes the normal path and defeats either model.
• Synchronised cloud administrators: an AD compromise becomes a tenant compromise.
• Decommissioning the trust before mapping every permission: breaks administration and invites ad hoc privileged grants.
• Unpatched bastion forests: the protective environment ages faster than production because few people use it.

Framework mapping

Practitioner checklist

• Write down your Tier 0 list, including Entra Connect, AD CS, backup and hypervisor platforms and privileged service accounts, with an owner for each.
• If you run a red forest, confirm it is patched, in support and still the only path to Tier 0 rights.
• Remove service accounts from Domain Admins and equivalent groups and delegate exact rights.
• Make all cloud administrator accounts cloud-only with PIM and phishing-resistant MFA.
• Deploy PAWs for Tier 0 and enforce their use with silos or logon restrictions.
• Keep Enterprise Admins, Domain Admins and Administrators empty apart from break-glass use.
• Do not build a new red forest for an Internet-connected hybrid environment.
• Retire the bastion trust only after every permission is remapped and tested.
• Track standing Tier 0 membership and Tier 0 logons on lower tiers every month.

Standards and references

• Microsoft Learn: Enhanced Security Admin Environment retirement
• Microsoft Learn: Developing a privileged access strategy
• Microsoft Learn: Enterprise access model
• Microsoft Learn: Rapid modernization plan
• Microsoft Learn: Privileged Access Management for Active Directory Domain Services
• Microsoft Learn: Implementing least privilege administrative models
• Microsoft Learn: Microsoft Entra Connect prerequisites
• ASD ACSC, CISA and partners: Detecting and mitigating Active Directory compromises

Related NHI Mgmt Group resources: Tiered Administration and Enterprise Access Model Guide · Microsoft Identity Manager and MIM PAM · Privileged Access Workstations Guide · AD Domain Controller Hardening Guide · Windows Services and Service Account Security Guide