ESAE Red Forest vs the enterprise access model in 2026

For years the answer to "how do we protect Domain Admins" in serious environments was ESAE, the Enhanced Security Admin Environment, better known as the Red Forest: a separate, hardened administrative forest whose accounts held privileges in production through a one-way trust, so that Tier 0 credentials never touched a production workstation. It worked against the attacks of its time, but it was expensive, slow to build and did nothing for identities that increasingly lived in the cloud. Microsoft withdrew it as the default recommendation and published the enterprise access model instead.

This guide is a design decision guide rather than a configuration walkthrough. It explains what ESAE protected against, why it was retired, what the enterprise access model asks you to build in an AD-centric estate in 2026, and the narrow cases where a bastion forest with a PAM trust is still the right call. It builds on the trusts and forest boundaries pillar and the Tier 0 pillar.

What ESAE actually did

ESAE combined several controls into one architecture:

• A separate administrative forest with its own DCs, hardened beyond production baselines, with no internet access and minimal software.
• A one-way trust: production trusts the admin forest; the admin forest does not trust production. Admin accounts live only in the admin forest and are granted rights in production through group membership.
• Privileged access workstations joined to the admin forest, used only for administration.
• Selective authentication and logon restrictions so admin forest accounts could only authenticate to specific production systems.

The value was isolation: compromising a production workstation or server could not yield admin forest credentials, because those credentials were never exposed there, and production administrators could not reach the admin forest.

Why Microsoft retired it as the default

Microsoft's reasoning, published with its privileged access strategy, came down to four points:

1. Cost and complexity. A second forest with its own DCs, PKI, patching, monitoring, backup and recovery. Many deployments stalled halfway, leaving a partial Red Forest that added attack surface without the isolation.
2. It did not fix production. Attackers routinely escalated through paths ESAE did not cover: ACL misconfigurations, AD CS templates, service accounts, backup servers, hypervisors and management agents with SYSTEM on DCs. The admin forest did not stop an attacker who reached Tier 0 through those assets.
3. Cloud identity. Once Entra ID, Entra Connect and cloud admin roles control mail, files and device management, a control plane that exists only on-premises protects half the kingdom.
4. The same benefits are available with less. Clean PAWs, strict tiering, authentication policies and just-in-time elevation deliver most of the credential isolation without a second forest.

ESAE was not declared insecure. It was declared the wrong first investment for most organisations.

The enterprise access model in AD terms

The model reframes tiers as planes and adds the paths users and apps take:

It also defines privileged access as a path: accounts, devices, intermediaries (jump servers, VPN, PIM) and interfaces. Every element in that path needs a security level at least as high as the resource it reaches. Microsoft names three levels: enterprise, specialised and privileged.

In an AD estate, building the model means concrete things you can check.

Privileged accounts

Separate admin accounts per plane, members of Protected Users, no mailbox, no internet. Standing membership in Domain Admins and Enterprise Admins should be close to zero, with break-glass accounts monitored.

"Domain Admins","Enterprise Admins","Schema Admins","Administrators" | ForEach-Object {
    [pscustomobject]@{
        Group   = $_
        Members = (Get-ADGroupMember $_ -Recursive | Measure-Object).Count
    }
}
Get-ADGroupMember "Protected Users" | Select-Object Name

Privileged devices

Privileged access workstations for control plane work, managed from the control plane themselves, with application allowlisting and no browsing or email. A PAW managed by a Tier 1 SCCM server is not a Tier 0 PAW.

Intermediaries and interfaces

Jump servers are only as trustworthy as whoever administers them. If Tier 0 admins use an RDS jump host, that host is Tier 0. Prefer Remote Credential Guard or Restricted Admin mode for RDP where supported, so reusable credentials are not left on the intermediary.

Enforcement in AD

Tiering must be technically enforced, not documented. That means Deny log on user rights assignments per tier, and more robustly authentication policies and silos, which restrict where Tier 0 accounts can obtain Kerberos tickets and shorten their TGT lifetime.

# Silo coverage for Tier 0 accounts
Get-ADAuthenticationPolicySilo -Filter * | Select-Object Name, Enforce
Get-ADUser -Filter 'adminCount -eq 1' -Properties msDS-AssignedAuthNPolicySilo |
  Select-Object SamAccountName, @{n='Silo';e={$_.'msDS-AssignedAuthNPolicySilo'}}

Cloud control plane

Entra ID Global Administrators, Privileged Role Administrators and the Entra Connect server belong to the same control plane as Domain Admins. Use cloud-only admin accounts, PIM for just-in-time activation and phishing-resistant MFA. Never synchronise on-premises admin accounts into privileged cloud roles, and never let a cloud admin account be controlled from on-premises.

When a bastion forest or PAM trust still makes sense

Microsoft Identity Manager 2016 introduced a leaner form of the admin forest: a bastion forest joined to production through a PAM trust, with shadow principals (msDS-ShadowPrincipal objects in the bastion forest carrying production group SIDs) and time-bound group membership. The bastion forest requires Windows Server 2016 forest functional level and the Privileged Access Management optional feature, which cannot be disabled once enabled.

# Check, do not enable casually: this feature is irreversible
Get-ADOptionalFeature -Filter 'Name -like "Privileged*"' | Select-Object Name, EnabledScopes

# With the feature enabled, membership can expire automatically
Add-ADGroupMember -Identity "Tier0-Operators" -Members "adm-jdoe" -MemberTimeToLive (New-TimeSpan -Hours 2)

Consider a bastion forest when:

• The environment is disconnected: OT, classified or air-gapped networks where a cloud control plane with PIM is not an option.
• A large multi-forest estate needs time-bound privileged membership across several forests from one administrative source, and consolidation is not realistic.
• A regulator requires a physically and logically separate administrative directory.
• A long migration needs Tier 0 isolated while production is too compromised or too messy to trust.

In every case, the bastion forest becomes the new top of your control plane: it needs its own forest recovery plan, its own monitoring and the same PAW discipline. MIM receives no new feature investment, so plan the operating life of the design accordingly.

A decision path for 2026

1. Inventory the control plane, including indirect control through backup, virtualisation, agents and ACLs. Most estates discover their real Tier 0 is five to ten times larger than the admin groups.
2. Remove attack paths into it with attack path management: ACLs, delegation, AD CS, service accounts, GPO links.
3. Enforce tiering with logon restrictions, silos and Protected Users.
4. Build PAWs for control plane work and move admin tasks onto them.
5. Add just-in-time elevation, using Entra PIM for cloud roles and temporal membership or a PAM product on-premises.
6. Only then evaluate whether a bastion forest adds isolation that steps 1 to 5 did not.

Verify

Measure outcomes, not architecture diagrams:

• Standing members of Tier 0 groups, trending towards break-glass only.
• Tier 0 logons (event 4624 on non-Tier 0 machines for accounts in Tier 0 groups) should be zero; alert on any. The event IDs reference lists the fields.
• Silo enforcement: authentication failures for siloed accounts appear on DCs under Applications and Services Logs > Microsoft > Windows > Authentication > AuthenticationPolicyFailures-DomainController, and during an audit-only rollout they flag every place an admin still authenticates outside policy.
• Attack paths from Domain Users to Tier 0 in BloodHound, reported as a count and trend.
• If a bastion forest exists: the trust is one-way, selective authentication and SID filtering are configured as expected, and shadow principal memberships expire.

What it breaks

• Administrators' daily habits. Separate accounts, PAWs and no admin work from the email laptop add friction; expect resistance and plan for it.
• Management tools with broad agents. Monitoring, backup and deployment tools that run with SYSTEM on DCs either move into Tier 0 or lose access to DCs.
• Authentication silos block admins from logging on to machines outside the silo, including emergency troubleshooting on member servers; build and test break-glass procedures.
• Retiring an existing ESAE requires moving admin rights back into production accounts protected by the new controls, removing the trust, and cleaning up groups that referenced admin forest principals; do not leave the old forest running unmanaged.
• Bastion forests break when their trust or their DCs fail, taking privileged access with them; keep documented break-glass accounts in production.

Related reading: the Trusts & Forest Design topic, the tier model glossary entry, and SID filtering and selective authentication for configuring any trust you keep.