Skip to content
Jussi Metso
Jussi Metso

It’s all about The Cloud and The Security

  • Posts
  • About the blog
  • Activity
  • Connect!
  • Privacy Policy
Jussi Metso

It’s all about The Cloud and The Security

August 7, 2026August 7, 2026

Red Forest: The predecessor of EAM

The second part of my red tenant study comes now. 

In my first part, kind of mockup intro to the Red Tenant concept introduced some core ideas in title level what are included in the model.

In practice, a “Red Tenant” usually means an isolated admin control plane. The common components are: a dedicated Entra tenant for admin identities, separate admin accounts from normal user accounts, hardened admin devices/PAWs, strict Conditional Access, just-in-time role activation through Microsoft Entra PIM, monitoring/auditing for privileged actions, and controlled ways to manage production tenants or on-prem AD without letting compromise in the normal estate spread into the admin estate. That matches both the public vendor (which is glueckkanja ) descriptions and Microsoft’s privileged-access guidance.

Before going in the modern way to do it let’s look at the history where it began.

The predecessor of them all - the ESAE

ESAE,  the Enhanced Security Administrative Environment, universally nicknamed the “Red Forest”  was Microsoft’s reference architecture from roughly the mid-2010s for protecting the most powerful credentials in an Active Directory environment.
 
It’s the direct ancestor of the tiering and isolated-admin ideas from the earlier background, so it’s worth understanding what it actually did.  The core insight behind it is that in Active Directory, the forest not the domain is the real security boundary.
 
A compromised domain can be used to pivot to other domains in the same forest, but crossing a forest boundary is much harder. ESAE exploited this by standing up a dedicated administrative forest, separate from the production forest where users, servers, and workloads lived. That admin forest was where the Tier 0 privileged accounts and the workstations used to administer production actually resided. It was deliberately tiny and hardened: very few accounts, no email, no internet browsing, strict baselines, minimal attack surface.
 
The two forests were connected by a one-way trust: production trusted the admin forest, but the admin forest did not trust production. This is the whole point. Even if an attacker fully owned the production forest, they still couldn’t reach into the red forest to steal the admin credentials that governed everything, the trust simply didn’t flow that direction. The admin forest was often paired with Microsoft Identity Manager’s PAM feature to provide time-bound, just-in-time membership in privileged groups, so even within the red forest, standing privilege was limited. It sat alongside the tier model and Privileged Access Workstations as a package.

The reasons for the retirement

The legacy Red Forest ESAE
Copyright Jussi Metso - a two forest environment
Microsoft retired the ESAE guidance around 2020–2021, and the reasons are instructive because they explain why the modern models look the way they do.
 
First, it was expensive and complex. Standing up and maintaining an entire second forest, the trust, MIM (Microsoft Identity Manager), and the operational discipline around it was a heavy lift, and many organizations deployed it partially or misconfigured it,  which produced a false sense of security rather than real protection. It had a tendency to become a checkbox that let teams neglect broader hygiene like patching, attack-surface reduction, and privileged access management everywhere else.
 
Second, and more fundamentally, the world moved to hybrid and cloud. ESAE was intensely AD-centric, built for a time when on-prem Active Directory was the center of gravity. Once Entra ID, SaaS, and cloud workloads became business-critical, isolating just the on-prem AD admin forest was solving yesterday’s problem while leaving the cloud identity attack surface unaddressed. A hardened red forest does nothing for a compromised cloud admin.
 
Microsoft replaced it with the modern Enterprise Access Model (EAM) and a rapid modernization plan for privileged access, built on Zero Trust principles: just-in-time privilege through Entra PIM, hardened PAWs, and Conditional Access gating everything on device and risk signals,  securing identity holistically across cloud and on-prem rather than walling off one forest.
 
ESAE wasn’t declared wrong, exactly; it was narrowed to a very small set of genuinely isolated on-prem scenarios (think air-gapped OT environments) and dropped as general guidance for everyone else.
 
So the through-line is: the red forest’s containment instinct was correct and survives in EAM and isolated admin tenants, but the mechanism, a separate on-prem forest with a one-way trust, was too costly, too easily botched, and too on-prem bound for a cloud world. The newer models keep the principle and swap the machinery.

If you still have ESAE - Guidance for existing deployments

The next chapters are quotes from Microsoft Learn:

there's no urgency to retire or replace an ESAE implementation if it's being operated as designed and intended. As with any enterprise systems, you should maintain the software in it by applying security updates and ensuring software is within support lifecycle.

adopt the modern privileged access strategy using the rapid modernization plan (RAMP) guidance. This guidance complements an existing ESAE implementation and provides appropriate security for roles not already protected by ESAE including Microsoft Entra administrators, sensitive business users, and standard enterprise users.

Links to consider

Guidance for Existing Deployments

Best Practice for Securing on-premises AD

Privileged Access Strategy

Rapid modernization plan (RAMP)

This was the history part. The next one is the modern part. At least part number one. The EAM model, some explanations of MIM PAM (Privileged Access Management) vs Entra ID PIM (Privileged Identity Management). Also where I started the “Red tenant” reference architecture at least in short.

There’s so much stuff around these so I’ll try to be strict and not spread the idea too much. Let’s see how I can manage this.

Picture of Jussi Metso
Jussi Metso

Author is a lifelong IT enthusiast, Microsoft Security MVP and interested in Cloud Security, XDR, SIEM and AI. Motto: Learning is the key for your future.

Share on Social Media
xfacebooklinkedinwhatsapp

Discover more from Jussi Metso

Subscribe to get the latest posts sent to your email.

RED #activedirectory#redforest#redtenant

Post navigation

Previous post

Related Posts

RED

Red Tenant intro

March 31, 2026August 8, 2026

a “Red Tenant” usually means an isolated admin control plane. The common components are: a dedicated Entra tenant for admin identities, separate admin accounts from normal user accounts, hardened admin devices/PAWs, strict Conditional Access, just-in-time role…

Read More

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Link to my MVP profile:

Subscribe my blog to get updates!

Join 42 other subscribers

Recent Posts

  • Red Forest: The predecessor of EAM
  • Conditional Access (CA) Policy templates
  • Enabling Cloud Security in Defender portal
  • Red Tenant intro
  • Understanding Microsoft Zero Trust Assessment Tool

Top posts:

Defender for Cloud – Part 10: Cloud Workload protection (CWP)
NextGen Defender for Cloud: Phase 1 - public preview
Microsoft Sentinel Data lake (preview)
Malware automated remediation in Defender for Storage
Defender for Cloud - Part 6: Attack Path Analysis

Categories

Tags

#activedirectory #architecture #azure #bookreview #cloudsecurity #defenderforcloud #defenderforstorage #defenderxdr #malwarescan #mdcseries #redforest #redtenant #securitycopilot #sentinel #siem #soc entraid

Archives

Visits on my site

25,711 hits

©2022-2026 Jussi Metso. All rights reserved.