Consolider les forêts et domaines Active Directory : méthodes, risques de l'historique SID et nettoyage des approbations
Domaine racine vide, domaines par pays, forêts issues de rachats reliées par des approbations : beaucoup d'annuaires Active Directory portent les traces de vingt ans de décisions successives. Chaque domaine et chaque approbation supplémentaires élargissent la surface d'attaque. La consolidation est un chantier lourd, mais souvent l'un des plus rentables en matière de sécurité.
Pourquoi ces architectures persistent
Au début des années 2000, il était courant de recommander un domaine racine vide et des domaines enfants par région ou par entité, au nom de l'isolation administrative. Les rachats ont ensuite ajouté des forêts entières, reliées par des approbations « provisoires » qui ne l'étaient pas. Ces architectures survivent parce que personne ne veut toucher à un ensemble qui fonctionne, et parce que les applications métier y ont accumulé des dépendances.
Or le postulat d'origine est faux : le domaine n'est pas une frontière de sécurité, la forêt l'est. Un administrateur d'un domaine enfant peut, par des techniques connues, obtenir des privilèges dans toute la forêt. Plusieurs domaines dans une forêt multiplient donc les comptes et les contrôleurs à protéger sans apporter d'isolation réelle.
Choisir la cible
La cible raisonnable est généralement une forêt, un domaine. Plusieurs forêts ne se justifient que pour une vraie séparation, par exemple une forêt d'administration dédiée ou une entité vouée à être cédée. Trois approches existent pour l'atteindre :
- restructuration inter-forêts : migrer comptes, groupes, ordinateurs et serveurs vers une forêt cible existante ou nouvelle ;
- restructuration intra-forêt : regrouper les domaines d'une même forêt dans un domaine survivant ;
- reconstruction : bâtir une forêt neuve et saine, puis y migrer progressivement, ce qui évite d'hériter des erreurs de configuration de l'ancienne.
Les outils historiques de Microsoft pour ces migrations ne sont plus activement développés ; de nombreuses organisations recourent à des outils tiers. Vérifiez l'état du support des outils envisagés avant de vous engager.
L'historique SID : indispensable pendant, dangereux après
Lors d'une migration, l'attribut sIDHistory permet à un compte migré de conserver l'accès aux ressources encore protégées par son ancien identifiant. C'est ce qui rend la transition invisible pour les utilisateurs. Mais c'est aussi un mécanisme puissant : un SID placé dans l'historique est traité comme s'il appartenait au compte.
Risque majeur. Un SID privilégié (administrateurs du domaine, administrateurs de l'entreprise) présent dans l'historique d'un compte ordinaire lui confère ces privilèges. C'est une technique de persistance connue. Tout historique SID doit être inventorié, justifié, puis supprimé une fois la migration achevée.
La fin de migration doit donc inclure une étape explicite : traduction des permissions sur les ressources (ACL des fichiers, partages, applications) vers les nouveaux SID, puis nettoyage de l'historique.
Les approbations : à réduire et à durcir
Chaque approbation est un chemin potentiel. Les points à examiner :
- Filtrage SID : il doit rester actif sur les approbations externes et de forêt. Le désactiver pour faciliter la migration ouvre la porte à l'injection d'historique SID depuis la forêt approuvée.
- Authentification sélective : elle limite les comptes de la forêt approuvée aux seules ressources explicitement autorisées.
- Délégation Kerberos à travers les approbations : elle doit rester désactivée sauf besoin démontré.
- Sens et transitivité : une approbation bidirectionnelle n'est souvent nécessaire que dans un sens.
Une approbation vers une forêt moins bien protégée revient à importer son niveau de risque. Nous rencontrons régulièrement des approbations vers des forêts dont plus personne ne connaît les administrateurs.
Décommissionner proprement
Un domaine migré n'est pas sécurisé tant qu'il existe. Le décommissionnement comprend la suppression des approbations, la rétrogradation des contrôleurs de domaine, le nettoyage du DNS et des objets restants, et la vérification qu'aucune application ne s'authentifie encore auprès de l'ancien domaine. Conserver « au cas où » un domaine vide avec ses contrôleurs non maintenus est l'un des pires compromis possibles.
Ce qu'un audit vérifie
- La carte des forêts, domaines et approbations, avec leur justification.
- L'état du filtrage SID et de l'authentification sélective sur chaque approbation.
- Les comptes porteurs d'un historique SID, en particulier de SID privilégiés.
- Les domaines ou forêts résiduels non maintenus.
- Les comptes et groupes privilégiés de chaque domaine, y compris le domaine racine.