ESAE Red Forest oder Enterprise Access Model im Jahr 2026

Jahrelang lautete die Antwort auf die Frage „Wie schützen wir Domain Admins?“ in anspruchsvollen Umgebungen ESAE – Enhanced Security Admin Environment, besser bekannt als Red Forest: eine separate, gehärtete Verwaltungs-Gesamtstruktur, deren Konten über eine unidirektionale Vertrauensstellung Privilegien in der Produktion besaßen, sodass Tier-0-Anmeldeinformationen nie eine Produktionsarbeitsstation berührten. Gegen die Angriffe ihrer Zeit funktionierte sie, doch sie war teuer, langwierig im Aufbau und nutzte nichts für Identitäten, die zunehmend in der Cloud lebten. Microsoft zog sie als Standardempfehlung zurück und veröffentlichte stattdessen das Enterprise Access Model (Unternehmenszugriffsmodell).

Dieser Leitfaden ist eine Entscheidungshilfe für das Design, keine Konfigurationsanleitung. Er erklärt, wovor ESAE schützte, warum es aufgegeben wurde, was das Enterprise Access Model 2026 in einer AD-zentrierten Umgebung von Ihnen verlangt und in welchen eng umrissenen Fällen eine Bastion-Gesamtstruktur mit PAM-Vertrauensstellung nach wie vor die richtige Wahl ist. Er baut auf dem Grundlagenartikel zu Vertrauensstellungen und Gesamtstrukturgrenzen und dem Grundlagenartikel zu Tier 0 auf.

Was ESAE tatsächlich leistete

ESAE vereinte mehrere Maßnahmen in einer Architektur:

• Eine separate Verwaltungs-Gesamtstruktur mit eigenen DCs, über die Produktions-Baselines hinaus gehärtet, ohne Internetzugang und mit minimaler Software.
• Eine unidirektionale Vertrauensstellung: Die Produktion vertraut der Verwaltungs-Gesamtstruktur, die Verwaltungs-Gesamtstruktur vertraut der Produktion nicht. Admin-Konten existieren nur in der Verwaltungs-Gesamtstruktur und erhalten Rechte in der Produktion über Gruppenmitgliedschaften.
• Privileged Access Workstations, die der Verwaltungs-Gesamtstruktur beigetreten sind und ausschließlich für die Administration genutzt werden.
• Selektive Authentifizierung und Anmeldeeinschränkungen, sodass sich Konten der Verwaltungs-Gesamtstruktur nur an bestimmten Produktionssystemen authentifizieren konnten.

Der Nutzen lag in der Isolation: Die Kompromittierung einer Produktionsarbeitsstation oder eines Produktionsservers konnte keine Anmeldeinformationen der Verwaltungs-Gesamtstruktur liefern, weil diese dort nie exponiert wurden, und Produktionsadministratoren konnten die Verwaltungs-Gesamtstruktur nicht erreichen.

Warum Microsoft es als Standard aufgegeben hat

Microsofts Begründung, veröffentlicht zusammen mit der Strategie für privilegierten Zugriff, lief auf vier Punkte hinaus:

1. Kosten und Komplexität. Eine zweite Gesamtstruktur mit eigenen DCs, eigener PKI, eigenem Patching, Monitoring, Backup und eigener Wiederherstellung. Viele Projekte blieben auf halbem Weg stecken und hinterließen einen unvollständigen Red Forest, der Angriffsfläche hinzufügte, ohne zu isolieren.
2. Die Produktion wurde nicht repariert. Angreifer eskalierten routinemäßig über Pfade, die ESAE nicht abdeckte: ACL-Fehlkonfigurationen, AD-CS-Vorlagen, Dienstkonten, Backup-Server, Hypervisoren und Management-Agenten mit SYSTEM-Rechten auf DCs. Die Verwaltungs-Gesamtstruktur hielt keinen Angreifer auf, der Tier 0 über diese Systeme erreichte.
3. Cloud-Identität. Sobald Entra ID, Entra Connect und Cloud-Admin-Rollen E-Mail, Dateien und Geräteverwaltung kontrollieren, schützt eine rein lokale Steuerungsebene nur das halbe Königreich.
4. Dieselben Vorteile gibt es mit weniger Aufwand. Saubere PAWs, striktes Tiering, Authentifizierungsrichtlinien und Just-in-Time-Erhöhung liefern den Großteil der Isolation von Anmeldeinformationen ohne zweite Gesamtstruktur.

ESAE wurde nicht für unsicher erklärt. Es wurde für die meisten Organisationen zur falschen ersten Investition erklärt.

Das Enterprise Access Model in AD-Begriffen

Das Modell deutet Tiers als Ebenen um und ergänzt die Pfade, die Benutzer und Anwendungen nehmen:

Außerdem definiert es privilegierten Zugriff als Pfad: Konten, Geräte, Vermittler (Jump-Server, VPN, PIM) und Schnittstellen. Jedes Element dieses Pfads braucht ein Sicherheitsniveau, das mindestens so hoch ist wie das der Ressource, die es erreicht. Microsoft unterscheidet drei Niveaus: Enterprise, Specialized und Privileged.

In einer AD-Umgebung bedeutet der Aufbau des Modells konkrete, überprüfbare Dinge.

Privilegierte Konten

Getrennte Admin-Konten pro Ebene, Mitglieder von Protected Users, kein Postfach, kein Internet. Dauerhafte Mitgliedschaften in Domain Admins und Enterprise Admins sollten nahe null liegen, Break-Glass-Konten werden überwacht.

"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

Privilegierte Geräte

Privileged Access Workstations für Arbeiten an der Steuerungsebene, die selbst aus der Steuerungsebene verwaltet werden, mit Anwendungs-Allowlisting und ohne Browsen oder E-Mail. Eine PAW, die von einem Tier-1-SCCM-Server verwaltet wird, ist keine Tier-0-PAW.

Vermittler und Schnittstellen

Jump-Server sind nur so vertrauenswürdig wie diejenigen, die sie administrieren. Nutzen Tier-0-Admins einen RDS-Jump-Host, ist dieser Host Tier 0. Bevorzugen Sie für RDP, wo unterstützt, Remote Credential Guard oder den Restricted-Admin-Modus, damit keine wiederverwendbaren Anmeldeinformationen auf dem Vermittler zurückbleiben.

Durchsetzung in AD

Tiering muss technisch durchgesetzt und nicht nur dokumentiert werden. Das bedeutet Deny log on-Zuweisungen von Benutzerrechten pro Tier und – robuster – Authentifizierungsrichtlinien und -silos, die einschränken, wo Tier-0-Konten Kerberos-Tickets erhalten können, und die Lebensdauer ihrer TGTs verkürzen.

# Silo-Abdeckung für Tier-0-Konten
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-Steuerungsebene

Globale Administratoren und Administratoren für privilegierte Rollen in Entra ID sowie der Entra-Connect-Server gehören zur selben Steuerungsebene wie Domain Admins. Verwenden Sie reine Cloud-Admin-Konten, PIM für Just-in-Time-Aktivierung und phishingresistente MFA. Synchronisieren Sie niemals lokale Admin-Konten in privilegierte Cloud-Rollen, und lassen Sie niemals zu, dass ein Cloud-Admin-Konto von lokal aus kontrolliert werden kann.

Wann eine Bastion-Gesamtstruktur oder PAM-Vertrauensstellung noch sinnvoll ist

Microsoft Identity Manager 2016 führte eine schlankere Form der Verwaltungs-Gesamtstruktur ein: eine Bastion-Gesamtstruktur, die über eine PAM-Vertrauensstellung mit der Produktion verbunden ist, mit Schattenprinzipalen (msDS-ShadowPrincipal-Objekte in der Bastion-Gesamtstruktur, die SIDs von Produktionsgruppen tragen) und zeitlich begrenzten Gruppenmitgliedschaften. Die Bastion-Gesamtstruktur erfordert die Gesamtstrukturfunktionsebene Windows Server 2016 und das optionale Feature Privileged Access Management, das sich nach der Aktivierung nicht mehr deaktivieren lässt.

# Nur prüfen, nicht leichtfertig aktivieren: dieses Feature ist unumkehrbar
Get-ADOptionalFeature -Filter 'Name -like "Privileged*"' | Select-Object Name, EnabledScopes

# Mit aktiviertem Feature können Mitgliedschaften automatisch ablaufen
Add-ADGroupMember -Identity "Tier0-Operators" -Members "adm-jdoe" -MemberTimeToLive (New-TimeSpan -Hours 2)

Ziehen Sie eine Bastion-Gesamtstruktur in Betracht, wenn:

• die Umgebung getrennt ist: OT-, klassifizierte oder per Air Gap getrennte Netze, in denen eine Cloud-Steuerungsebene mit PIM keine Option ist.
• eine große Umgebung mit mehreren Gesamtstrukturen zeitlich begrenzte privilegierte Mitgliedschaften über mehrere Gesamtstrukturen aus einer einzigen administrativen Quelle benötigt und eine Konsolidierung unrealistisch ist.
• eine Aufsichtsbehörde ein physisch und logisch getrenntes Verwaltungsverzeichnis verlangt.
• eine lange Migration Tier 0 isolieren muss, während die Produktion zu kompromittiert oder zu unübersichtlich ist, um ihr zu vertrauen.

In jedem Fall wird die Bastion-Gesamtstruktur zur neuen Spitze Ihrer Steuerungsebene: Sie braucht einen eigenen Gesamtstruktur-Wiederherstellungsplan, eigenes Monitoring und dieselbe PAW-Disziplin. MIM erhält keine neuen Funktionen mehr; planen Sie die Nutzungsdauer des Designs entsprechend.

Ein Entscheidungspfad für 2026

1. Inventarisieren Sie die Steuerungsebene, einschließlich indirekter Kontrolle über Backup, Virtualisierung, Agenten und ACLs. Die meisten Umgebungen stellen fest, dass ihr tatsächliches Tier 0 fünf- bis zehnmal größer ist als die Admin-Gruppen.
2. Beseitigen Sie Angriffspfade dorthin mit Attack Path Management: ACLs, Delegierung, AD CS, Dienstkonten, GPO-Verknüpfungen.
3. Setzen Sie Tiering durch mit Anmeldeeinschränkungen, Silos und Protected Users.
4. Bauen Sie PAWs auf für Arbeiten an der Steuerungsebene und verlagern Sie Admin-Aufgaben dorthin.
5. Ergänzen Sie Just-in-Time-Erhöhung, mit Entra PIM für Cloud-Rollen und zeitlich begrenzter Mitgliedschaft oder einem PAM-Produkt lokal.
6. Erst dann bewerten Sie, ob eine Bastion-Gesamtstruktur eine Isolation bietet, die die Schritte 1 bis 5 nicht erreicht haben.

Überprüfen

Messen Sie Ergebnisse, nicht Architekturdiagramme:

• Dauerhafte Mitglieder von Tier-0-Gruppen, mit Tendenz hin zu ausschließlich Break-Glass-Konten.
• Tier-0-Anmeldungen (Ereignis 4624 auf Nicht-Tier-0-Computern für Konten in Tier-0-Gruppen) sollten null betragen; alarmieren Sie bei jeder. Die Referenz der Ereignis-IDs listet die Felder auf.
• Silo-Durchsetzung: Authentifizierungsfehler für Konten in Silos erscheinen auf DCs unter Applications and Services Logs > Microsoft > Windows > Authentication > AuthenticationPolicyFailures-DomainController und markieren während einer reinen Audit-Einführung jede Stelle, an der sich ein Admin noch außerhalb der Richtlinie authentifiziert.
• Angriffspfade von Domain Users zu Tier 0 in BloodHound, berichtet als Anzahl und Trend.
• Falls eine Bastion-Gesamtstruktur existiert: Die Vertrauensstellung ist unidirektional, selektive Authentifizierung und SID-Filterung sind wie erwartet konfiguriert, und die Mitgliedschaften von Schattenprinzipalen laufen ab.

Was dadurch nicht mehr funktioniert

• Die täglichen Gewohnheiten der Administratoren. Getrennte Konten, PAWs und keine Admin-Arbeit vom E-Mail-Laptop aus erzeugen Reibung; rechnen Sie mit Widerstand und planen Sie dafür.
• Verwaltungswerkzeuge mit weitreichenden Agenten. Monitoring-, Backup- und Softwareverteilungswerkzeuge, die mit SYSTEM-Rechten auf DCs laufen, wandern entweder in Tier 0 oder verlieren den Zugriff auf die DCs.
• Authentifizierungssilos hindern Admins daran, sich an Computern außerhalb des Silos anzumelden – auch bei der Notfall-Fehlersuche auf Mitgliedsservern; erstellen und testen Sie Break-Glass-Verfahren.
• Das Stilllegen eines bestehenden ESAE erfordert, Admin-Rechte zurück auf Produktionskonten zu verlagern, die durch die neuen Maßnahmen geschützt sind, die Vertrauensstellung zu entfernen und Gruppen zu bereinigen, die Prinzipale der Verwaltungs-Gesamtstruktur referenzierten; lassen Sie die alte Gesamtstruktur nicht unverwaltet weiterlaufen.
• Bastion-Gesamtstrukturen fallen aus, wenn ihre Vertrauensstellung oder ihre DCs ausfallen – und nehmen den privilegierten Zugriff mit; halten Sie dokumentierte Break-Glass-Konten in der Produktion vor.

Weiterführende Lektüre: das Thema Vertrauensstellungen & Gesamtstruktur, der Glossareintrag zum Tier-Modell und SID-Filterung und selektive Authentifizierung zur Konfiguration jeder Vertrauensstellung, die Sie behalten.