Durcir les approbations AD et les frontières de forêt

La documentation Active Directory et une bonne partie de l'outillage associé parlent encore de « sécurité du domaine » comme si un domaine était une frontière d'isolation. Ce n'est pas le cas. Chaque contrôleur de domaine d'une forêt détient un réplica complet et accessible en écriture des partitions de schéma et de configuration, chaque domaine fait implicitement confiance à la racine de forêt, et le groupe Enterprise Admins du domaine racine dispose de droits sur tous les domaines de la forêt. Considérer un domaine enfant ou un domaine de ressources comme une frontière de sécurité et négliger le durcissement des approbations est l'une des erreurs de conception les plus tenaces dans les environnements AD, et c'est précisément ce qui permet à un attaquant arrivé dans un domaine de faible valeur de rebondir vers celui qui compte vraiment.

Cet article explique comment inventorier et durcir les approbations au sein de vos forêts et entre elles : types d'approbation et transitivité, filtrage des SID et quarantaine, authentification sélective, et dans quels cas une forêt d'administration dédiée ou une approbation PAM se justifie réellement, par opposition aux cas où le modèle d'accès d'entreprise moderne vous couvre déjà.

La frontière, c'est la forêt, pas le domaine

Quelques faits qui doivent guider chaque décision relative aux approbations :

• La partition de schéma et la partition de configuration sont répliquées sur tous les DC de la forêt. Une modification du schéma ou un objet malveillant dans la partition de configuration (par exemple un conteneur de stratégie de groupe illégitime ou un lien de site forgé) affecte tous les domaines.
• Enterprise Admins et Schema Admins (domaine racine de la forêt) disposent de droits sur l'ensemble de la forêt, y compris celui de modifier le schéma et d'ajouter des domaines.
• La compromission de n'importe quel contrôleur de domaine, dans n'importe quel domaine, constitue un chemin crédible vers la compromission complète de la forêt, par abus de la réplication, altération du schéma ou exploitation des approbations.

Conséquence pratique : si vous avez besoin d'une véritable isolation (une filiale qui ne doit pas pouvoir affecter votre environnement principal, une acquisition dont l'hygiène est inconnue, une exigence réglementaire d'administration séparée), il vous faut une forêt distincte reliée par une approbation au périmètre soigneusement limité, et non un domaine enfant dans la même forêt.

Types d'approbation et transitivité, en bref

Les approbations de forêt et les approbations externes sont celles qui franchissent une véritable frontière de sécurité et méritent les contrôles ci-dessous. Les approbations intra-forêt se trouvent déjà dans votre rayon d'impact ; traitez-les par le modèle de tiers (Tier 0 et accès privilégiés) plutôt que par les paramètres d'approbation.

Commencer par inventorier les approbations existantes

Avant de modifier quoi que ce soit, sachez ce dont vous disposez :

Get-ADTrust -Filter * -Properties * |
  Select-Object Name, Direction, TrustType, ForestTransitive, SIDFilteringForestAware, SIDFilteringQuarantined, SelectiveAuthentication, IntraForest, DisallowTransivity |
  Format-Table -AutoSize

Pour chaque approbation, vérifiez aussi avec netdom :

netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify
netdom query trust

Signalez toute approbation pour laquelle :

• SIDFilteringQuarantined vaut False sur une approbation externe, ou SIDFilteringForestAware vaut True sur une approbation de forêt (SID history accepté à travers elle).
• SelectiveAuthentication vaut False sur une approbation externe ou de forêt avec un partenaire non fiable ou de niveau inférieur.
• L'approbation est bidirectionnelle alors qu'un seul sens est réellement nécessaire : une approbation sortante unidirectionnelle depuis le côté sensible élimine tout un chemin d'attaque.
• L'approbation est ancienne, non documentée ou liée à un domaine partenaire décommissionné. Les approbations obsolètes sont fréquentes dans les environnements qui ont connu des fusions, cessions ou migrations sans nettoyage ultérieur.

Filtrage des SID et quarantaine

L'historique des SID (sIDHistory) sert à préserver les accès lors des migrations de domaine : un utilisateur déplacé du domaine A vers le domaine B conserve ses anciens SID afin que les ACL existantes continuent de se résoudre. Ce même mécanisme est à la base de l'injection de SID history : si un attaquant compromet le domaine A (ou l'un de ses DC) et que l'approbation ne filtre pas l'historique des SID, il peut associer à un principal du domaine A le SID, par exemple, du groupe Enterprise Admins du domaine B, et s'authentifier comme s'il était privilégié dans B.

Le filtrage des SID est activé par défaut sur les approbations de forêt (les SID n'appartenant pas à la forêt approuvée sont supprimés) et, sous forme de quarantaine, sur les approbations externes créées avec des versions récentes de Windows Server. Il est cependant souvent assoupli pendant les migrations (/quarantine:no ou /enablesidhistory:yes) et jamais rétabli. Vérifiez-le et imposez-le :

:: Enable quarantine (SID filtering) on an external trust
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:yes /userD:<Admin> /passwordD:*

:: On a forest trust: explicitly disable SID history acceptance (only re-enable temporarily during a real migration)
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:no

Vérification par script :

Get-ADTrust -Filter {Name -eq "<TrustedDomainName>"} | Select-Object Name, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware

SIDFilteringQuarantined doit valoir True sur chaque approbation externe, et SIDFilteringForestAware doit valoir False sur chaque approbation de forêt, sauf si vous êtes dans une fenêtre de migration active et limitée dans le temps nécessitant l'historique des SID. Dans ce cas, traitez cette fenêtre comme une période à haut risque, surveillez de près les événements de modification d'appartenance aux groupes 4728/4732/4756 et désactivez à nouveau l'acceptation de SID history dès la fin de la migration.

Authentification sélective

Le filtrage des SID détermine quelles revendications d'identité sont acceptées. L'authentification sélective détermine quelles ressources les principaux du domaine approuvé peuvent seulement tenter d'atteindre. Sur une approbation de forêt ou externe où l'authentification sélective est activée, un principal du domaine approuvé n'obtient aucun accès dans le domaine approbateur tant qu'un administrateur ne lui a pas explicitement accordé l'autorisation « Allowed to Authenticate » (Autorisé à s'authentifier) sur des objets ordinateur précis.

Activez-la :

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth:yes

Accordez ensuite l'accès uniquement là où il est nécessaire, objet ordinateur par objet ordinateur, via l'onglet Sécurité → Allowed to Authenticate, ou avec dsacls :

dsacls "CN=<TargetComputer>,OU=Servers,DC=trusting,DC=example,DC=com" /G "TRUSTEDDOMAIN\SomeGroup:CA;Allowed to Authenticate"

On transforme ainsi une approbation ouverte, où n'importe quel utilisateur authentifié du domaine partenaire peut tenter d'ouvrir une session n'importe où, en liste d'autorisation explicite. C'est le contrôle le plus rentable sur une approbation externe ou de forêt, et il devrait constituer la posture par défaut pour toute approbation vers un partenaire que vous ne maîtrisez pas entièrement.

Abus de SID history : ce qu'il faut surveiller

Même avec la quarantaine activée, surveillez les anomalies au lieu de supposer que le contrôle est infaillible :

• Apparition soudaine de valeurs sIDHistory sur des comptes en dehors d'une migration connue et planifiée.
• Tickets Kerberos de type golden ticket contenant un historique des SID de groupes privilégiés : ils apparaissent comme des contenus de PAC anormaux dans les outils de détection et dans les alertes de Microsoft Defender for Identity.
• Événements d'authentification provenant d'un domaine approuvé vers des ressources Tier 0, en dehors des autorisations « Allowed to Authenticate » que vous avez configurées.

Consultez Audit, journalisation et détection pour les ID d'événements et la configuration des SACL qui rendent ces activités visibles.

Quand une Red Forest ou une approbation PAM est réellement nécessaire

L'ESAE (Enhanced Security Admin Environment) d'origine de Microsoft, plus connue sous le nom de « Red Forest », reposait sur une forêt d'administration dédiée et durcie, reliée à la forêt de production par une approbation PAM (Privileged Access Management) unidirectionnelle, afin que les identifiants Tier 0 ne touchent jamais de postes joints à la forêt de production. Fin 2020, Microsoft a retiré l'ESAE de ses recommandations générales, dans le cadre de sa stratégie d'accès privilégié, au profit du modèle d'accès d'entreprise moderne fondé sur Azure AD / Microsoft Entra ID, les stations d'administration sécurisées (Privileged Access Workstations) et l'administration juste-à-temps / juste-suffisante (JIT/JEA). En effet, une forêt d'administration autonome coûte cher à exploiter, devient elle-même une cible et ne traite pas du tout les chemins d'attaque liés à l'identité cloud.

Envisagez tout de même une forêt d'administration dédiée ou une approbation PAM lorsque :

• Vous êtes en environnement isolé (air-gapped) ou ne pouvez pas adopter un plan de contrôle d'identité cloud (environnements réglementés, classifiés ou OT).
• Vous gérez un très grand environnement multi-forêts dans lequel une frontière d'approbation d'administration réellement séparée réduit le rayon d'impact inter-forêts plus efficacement que le seul modèle de tiers.
• Vous avez besoin d'une passerelle pendant une longue migration de l'identité AD vers le cloud et souhaitez isoler le Tier 0 dans l'intervalle.

Pour la majorité des environnements, investissez d'abord dans le modèle de tiers Tier 0 et accès privilégiés, les Privileged Access Workstations et le durcissement des approbations décrit dans cet article : vous fermez ainsi la plupart des chemins d'attaque visés par l'ESAE, pour une fraction du coût opérationnel.

Ce que cela casse

• Les accès inter-forêts ou inter-domaines qui reposaient sur une approbation ouverte (non sélective). Les applications, partages de fichiers ou comptes de service qui s'authentifient à travers l'approbation depuis le domaine partenaire échoueront tant que vous n'aurez pas accordé explicitement « Allowed to Authenticate » sur chaque objet ordinateur cible. Inventoriez les flux d'accès à travers l'approbation (via les événements d'ouverture de session 4624/4625 filtrés par domaine source) avant d'activer l'authentification sélective en production.
• Les migrations qui dépendent de l'historique des SID échoueront si vous désactivez enablesidhistory pendant qu'une migration est encore en cours. Ne mettez l'historique des SID en quarantaine qu'une fois les travaux de migration liés à cette approbation entièrement terminés.
• Les approbations héritées vers des domaines partenaires décommissionnés ou à l'hygiène douteuse doivent parfois simplement être supprimées plutôt que durcies : netdom trust /remove est souvent la bonne réponse une fois confirmé que l'approbation n'a plus de dépendances actives.

Associez cette démarche au durcissement des contrôleurs de domaine et à la sécurité des objets et des ACL : le durcissement des approbations limite ce qu'un domaine partenaire compromis peut atteindre, mais ne remplace pas le durcissement des DC et des objets de votre côté de l'approbation.