Red Forest ESAE ou modèle d'accès d'entreprise en 2026

Pendant des années, dans les environnements exigeants, la réponse à la question « comment protéger les Domain Admins ? » s'appelait ESAE, l'Enhanced Security Admin Environment, plus connu sous le nom de Red Forest : une forêt d'administration distincte et durcie, dont les comptes détenaient des privilèges en production via une approbation unidirectionnelle, afin que les identifiants Tier 0 ne touchent jamais un poste de travail de production. Elle était efficace contre les attaques de son époque, mais coûteuse, longue à mettre en place, et n'apportait rien pour des identités de plus en plus hébergées dans le cloud. Microsoft l'a retirée de ses recommandations par défaut et a publié à la place le modèle d'accès d'entreprise.

Ce guide est un guide d'aide à la décision de conception plutôt qu'un pas-à-pas de configuration. Il explique contre quoi l'ESAE protégeait, pourquoi elle a été abandonnée, ce que le modèle d'accès d'entreprise demande de construire dans un environnement centré sur AD en 2026, et les cas restreints dans lesquels une forêt bastion avec une approbation PAM reste le bon choix. Il s'appuie sur l'article pilier sur les approbations et les frontières de forêt et sur l'article pilier sur le Tier 0.

Ce que faisait réellement l'ESAE

L'ESAE combinait plusieurs contrôles au sein d'une même architecture :

• Une forêt d'administration distincte avec ses propres DC, durcie au-delà des référentiels de production, sans accès Internet et avec un minimum de logiciels.
• Une approbation unidirectionnelle : la production approuve la forêt d'administration ; la forêt d'administration n'approuve pas la production. Les comptes d'administration n'existent que dans la forêt d'administration et reçoivent leurs droits en production par appartenance à des groupes.
• Des stations d'administration sécurisées (PAW) jointes à la forêt d'administration, utilisées exclusivement pour l'administration.
• L'authentification sélective et des restrictions d'ouverture de session, afin que les comptes de la forêt d'administration ne puissent s'authentifier que sur des systèmes de production précis.

Sa valeur résidait dans l'isolation : compromettre un poste ou un serveur de production ne permettait pas d'obtenir les identifiants de la forêt d'administration, car ils n'y étaient jamais exposés, et les administrateurs de production ne pouvaient pas atteindre la forêt d'administration.

Pourquoi Microsoft l'a retirée des recommandations par défaut

Le raisonnement de Microsoft, publié avec sa stratégie d'accès privilégié, se résumait en quatre points :

1. Coût et complexité. Une seconde forêt avec ses propres DC, PKI, mises à jour, supervision, sauvegarde et restauration. De nombreux déploiements se sont arrêtés à mi-chemin, laissant une Red Forest partielle qui ajoutait de la surface d'attaque sans apporter l'isolation.
2. Elle ne corrigeait pas la production. Les attaquants élevaient régulièrement leurs privilèges par des chemins que l'ESAE ne couvrait pas : ACL mal configurées, modèles AD CS, comptes de service, serveurs de sauvegarde, hyperviseurs et agents de gestion disposant de SYSTEM sur les DC. La forêt d'administration n'arrêtait pas un attaquant qui atteignait le Tier 0 par ces ressources.
3. L'identité cloud. Dès lors qu'Entra ID, Entra Connect et les rôles d'administration cloud contrôlent la messagerie, les fichiers et la gestion des appareils, un plan de contrôle qui n'existe que sur site ne protège que la moitié du royaume.
4. Les mêmes bénéfices sont accessibles avec moins. Des PAW saines, un modèle de tiers strict, des stratégies d'authentification et l'élévation juste-à-temps apportent l'essentiel de l'isolation des identifiants sans seconde forêt.

L'ESAE n'a pas été déclarée non sûre. Elle a été déclarée mauvais premier investissement pour la plupart des organisations.

Le modèle d'accès d'entreprise traduit en termes AD

Le modèle recadre les tiers en plans et ajoute les chemins empruntés par les utilisateurs et les applications :

Il définit également l'accès privilégié comme un chemin : comptes, appareils, intermédiaires (serveurs de rebond, VPN, PIM) et interfaces. Chaque élément de ce chemin doit avoir un niveau de sécurité au moins équivalent à celui de la ressource qu'il atteint. Microsoft distingue trois niveaux : entreprise, spécialisé et privilégié.

Dans un environnement AD, construire ce modèle se traduit par des éléments concrets et vérifiables.

Comptes privilégiés

Des comptes d'administration distincts par plan, membres de Protected Users, sans boîte aux lettres ni accès Internet. L'appartenance permanente à Domain Admins et Enterprise Admins doit être proche de zéro, avec des comptes de secours (break-glass) surveillés.

"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

Appareils privilégiés

Des stations d'administration sécurisées pour le travail sur le plan de contrôle, elles-mêmes gérées depuis le plan de contrôle, avec une liste d'autorisation des applications et sans navigation web ni messagerie. Une PAW gérée par un serveur SCCM de Tier 1 n'est pas une PAW Tier 0.

Intermédiaires et interfaces

Un serveur de rebond n'est digne de confiance que dans la mesure où ceux qui l'administrent le sont. Si des administrateurs Tier 0 utilisent un hôte de rebond RDS, cet hôte est Tier 0. Privilégiez Remote Credential Guard ou le mode Restricted Admin pour RDP lorsque c'est possible, afin de ne pas laisser d'identifiants réutilisables sur l'intermédiaire.

Application dans AD

Le modèle de tiers doit être imposé techniquement, pas seulement documenté. Cela signifie des attributions de droits utilisateur Deny log on par tier et, de manière plus robuste, des stratégies et silos d'authentification, qui limitent les emplacements où les comptes Tier 0 peuvent obtenir des tickets Kerberos et raccourcissent la durée de vie de leur TGT.

# Couverture des silos pour les comptes Tier 0
Get-ADAuthenticationPolicySilo -Filter * | Select-Object Name, Enforce
Get-ADUser -Filter 'adminCount -eq 1' -Properties msDS-AssignedAuthNPolicySilo |
  Select-Object SamAccountName, @{n='Silo';e={$_.'msDS-AssignedAuthNPolicySilo'}}

Plan de contrôle cloud

Les administrateurs généraux et les administrateurs de rôle privilégié Entra ID, ainsi que le serveur Entra Connect, appartiennent au même plan de contrôle que les Domain Admins. Utilisez des comptes d'administration exclusivement cloud, PIM pour l'activation juste-à-temps et une MFA résistante au phishing. Ne synchronisez jamais de comptes d'administration locaux vers des rôles cloud privilégiés, et ne laissez jamais un compte d'administration cloud être contrôlé depuis l'environnement local.

Quand une forêt bastion ou une approbation PAM a encore du sens

Microsoft Identity Manager 2016 a introduit une forme allégée de la forêt d'administration : une forêt bastion reliée à la production par une approbation PAM, avec des shadow principals (objets msDS-ShadowPrincipal de la forêt bastion portant les SID de groupes de production) et des appartenances aux groupes limitées dans le temps. La forêt bastion exige le niveau fonctionnel de forêt Windows Server 2016 et la fonctionnalité optionnelle Privileged Access Management, qui ne peut plus être désactivée une fois activée.

# Vérifier, ne pas activer à la légère : cette fonctionnalité est irréversible
Get-ADOptionalFeature -Filter 'Name -like "Privileged*"' | Select-Object Name, EnabledScopes

# Une fois la fonctionnalité activée, l'appartenance peut expirer automatiquement
Add-ADGroupMember -Identity "Tier0-Operators" -Members "adm-jdoe" -MemberTimeToLive (New-TimeSpan -Hours 2)

Envisagez une forêt bastion lorsque :

• L'environnement est déconnecté : réseaux OT, classifiés ou isolés (air-gapped) où un plan de contrôle cloud avec PIM n'est pas envisageable.
• Un grand environnement multi-forêts a besoin d'appartenances privilégiées limitées dans le temps sur plusieurs forêts depuis une source d'administration unique, et une consolidation n'est pas réaliste.
• Un régulateur exige un annuaire d'administration physiquement et logiquement séparé.
• Une longue migration nécessite d'isoler le Tier 0 alors que la production est trop compromise ou trop désordonnée pour être digne de confiance.

Dans tous les cas, la forêt bastion devient le nouveau sommet de votre plan de contrôle : elle a besoin de son propre plan de restauration de forêt, de sa propre supervision et de la même discipline en matière de PAW. MIM ne reçoit plus de nouvelles fonctionnalités : planifiez la durée de vie de cette architecture en conséquence.

Une démarche de décision pour 2026

1. Inventoriez le plan de contrôle, y compris le contrôle indirect via la sauvegarde, la virtualisation, les agents et les ACL. La plupart des organisations découvrent que leur véritable Tier 0 est cinq à dix fois plus vaste que les groupes d'administration.
2. Supprimez les chemins d'attaque qui y mènent grâce à la gestion des chemins d'attaque : ACL, délégation, AD CS, comptes de service, liaisons de GPO.
3. Imposez le modèle de tiers avec des restrictions d'ouverture de session, des silos et Protected Users.
4. Déployez des PAW pour le travail sur le plan de contrôle et migrez-y les tâches d'administration.
5. Ajoutez l'élévation juste-à-temps, avec Entra PIM pour les rôles cloud et l'appartenance temporaire ou un produit PAM en local.
6. Ensuite seulement, évaluez si une forêt bastion apporte une isolation que les étapes 1 à 5 n'ont pas fournie.

Vérifier

Mesurez des résultats, pas des schémas d'architecture :

• Les membres permanents des groupes Tier 0, avec une tendance vers les seuls comptes de secours.
• Les ouvertures de session Tier 0 (événement 4624 sur des machines hors Tier 0 pour des comptes membres de groupes Tier 0) doivent être nulles ; déclenchez une alerte sur chacune. La référence des ID d'événements détaille les champs.
• L'application des silos : les échecs d'authentification des comptes placés dans un silo apparaissent sur les DC sous Applications and Services Logs > Microsoft > Windows > Authentication > AuthenticationPolicyFailures-DomainController et, pendant un déploiement en mode audit, ils signalent chaque endroit où un administrateur s'authentifie encore hors stratégie.
• Les chemins d'attaque de Domain Users vers le Tier 0 dans BloodHound, suivis en nombre et en tendance.
• Si une forêt bastion existe : l'approbation est unidirectionnelle, l'authentification sélective et le filtrage des SID sont configurés comme prévu, et les appartenances des shadow principals expirent.

Ce que cela casse

• Les habitudes quotidiennes des administrateurs. Comptes séparés, PAW et interdiction d'administrer depuis le portable de messagerie ajoutent de la friction ; attendez-vous à des résistances et anticipez-les.
• Les outils de gestion aux agents étendus. Les outils de supervision, de sauvegarde et de déploiement qui s'exécutent avec SYSTEM sur les DC doivent soit entrer dans le Tier 0, soit perdre leur accès aux DC.
• Les silos d'authentification empêchent les administrateurs d'ouvrir une session sur des machines hors du silo, y compris pour un dépannage d'urgence sur des serveurs membres ; construisez et testez des procédures de secours.
• Retirer une ESAE existante implique de rapatrier les droits d'administration vers des comptes de production protégés par les nouveaux contrôles, de supprimer l'approbation et de nettoyer les groupes qui référençaient des principaux de la forêt d'administration ; ne laissez pas l'ancienne forêt tourner sans gestion.
• Les forêts bastion tombent en panne lorsque leur approbation ou leurs DC défaillent, emportant avec elles l'accès privilégié ; conservez des comptes de secours documentés en production.

Pour aller plus loin : la thématique Approbations & conception de forêt, l'entrée du glossaire sur le modèle de tiers et Filtrage des SID et authentification sélective pour configurer toute approbation que vous conservez.