Comment structurer Active Directory et déléguer sans escalade

Active Directory concentre identités, postes, serveurs, politiques et droits d’administration dans le même graphe de confiance. Cette concentration rend l’exploitation confortable, puis rend la compromission spectaculaire quand une délégation mal posée ouvre un chemin vers le contrôle du domaine.

→ Lire l’explication complète de la marmotte

Forêt, domaine et unités d’organisation : choisir les vraies frontières

Une forêt Active Directory est la frontière de sécurité principale : elle partage un schéma, une configuration et des relations de confiance internes. Un domaine fournit un espace de noms, des contrôleurs de domaine et une base d’identités répliquée. Une unité d’organisation, ou OU (Organizational Unit), ne fournit aucune frontière de sécurité intrinsèque : elle sert à organiser les objets, appliquer des stratégies et déléguer des droits.

Le compromis central est net : une forêt unique réduit les coûts d’exploitation, les synchronisations et les bricolages de fédération ; plusieurs forêts réduisent l’impact d’une compromission d’administration. La recommandation est de maintenir un seul domaine dans une forêt lorsque les mêmes opérateurs administrent les mêmes actifs et que les exigences de sécurité sont homogènes. Créer des domaines pour séparer des sites, des langues ou des directions produit surtout des contrôleurs de domaine supplémentaires et des réunions plus longues.

Créer une forêt distincte lorsqu’une compromission de l’environnement principal ne doit pas donner de contrôle administratif sur un périmètre donné : administration de crise, réseau industriel, environnement de sécurité élevé ou annuaire de gestion des identités. Une relation d’approbation entre forêts restaure toutefois une partie de la surface d’attaque. Une frontière que l’on traverse avec des comptes privilégiés permanents est une frontière décorative, ce qui convient très bien aux slides, moins aux incidents.

Les OU doivent refléter les responsabilités opérationnelles, pas l’organigramme. Une arborescence par type d’actif et niveau d’administration fonctionne : Postes, Serveurs, Comptes de service, Comptes privilégiés, puis sous-OU par périmètre exploité. Éviter les profondeurs excessives : chaque héritage de liste de contrôle devient alors un jeu de piste où le Minotaure possède WriteDacl.

Les comptes d’administration doivent être séparés des comptes bureautiques. Un administrateur de domaine ne lit pas ses courriels, n’ouvre pas de navigateur généraliste et ne se connecte pas à un poste utilisateur avec son identité privilégiée. Le protocole NTLM (NT LAN Manager) reste particulièrement dangereux dans ce scénario ; ses vulnérabilités et son durcissement sont détaillés dans l’analyse de NTLM.

Délégations ACL : accorder une action, jamais un pouvoir diffus

Une délégation Active Directory est une modification de liste de contrôle d’accès, ou ACL (Access Control List), sur un objet, généralement une OU. Chaque entrée de contrôle d’accès, ou ACE (Access Control Entry), accorde ou refuse une opération à un identifiant de sécurité, ou SID (Security Identifier). La liste discrétionnaire, ou DACL (Discretionary Access Control List), décide qui peut modifier l’objet et ses attributs.

La règle opérationnelle est stricte : déléguer à un groupe dédié, sur une OU dédiée, avec un droit précis, sur une classe d’objet précise. Ne jamais déléguer à un compte nominatif ni à un groupe générique de support. La révocation doit consister à retirer un membre d’un groupe, pas à fouiller des ACL héritées comme un archéologue sous caféine.

Les droits GenericAll, GenericWrite, WriteDacl et WriteOwner ne sont pas des droits de délégation ordinaires. Ils autorisent respectivement un contrôle complet, la modification large d’attributs, la modification de la DACL et la prise de propriété. Sur un objet utilisateur, GenericWrite peut permettre d’ajouter un nom de service, ou SPN (Service Principal Name), puis de demander un ticket Kerberos associé afin de tenter une attaque hors ligne sur le secret du compte. Sur un groupe, WriteDacl permet souvent de s’accorder le droit de modifier les membres. Le droit semble local, le chemin vers l’administration de domaine ne l’est pas.

Les droits étendus doivent être préférés aux droits génériques. Réinitialiser un mot de passe n’exige pas de modifier tous les attributs d’un utilisateur. Créer un ordinateur dans une OU n’exige pas de gérer les stratégies de groupe. Chaque permission doit être justifiée par une opération observable et testable.

Attention aux groupes protégés par AdminSDHolder. Les comptes membres de groupes administratifs protégés reçoivent périodiquement une DACL contrôlée par le mécanisme SDProp (Security Descriptor Propagator). Une délégation sur leur OU peut donc sembler active puis disparaître, ou laisser une protection inattendue. Les comptes d’administration élevés doivent rester hors des OU déléguées.

Chemins d’attaque Active Directory à couper en priorité

Un attaquant ne cherche pas forcément un compte Domain Admins. Il cherche un chemin : modifier un groupe, contrôler une stratégie de groupe, changer une DACL, lire un secret de service ou répliquer l’annuaire. Les graphes de privilèges révèlent que les chemins les plus courts passent rarement par la porte officiellement marquée « administration ».

La modification d’une stratégie de groupe, ou GPO (Group Policy Object), est une élévation de privilèges potentielle. Une GPO liée à une OU de serveurs permet d’exécuter une tâche planifiée, de modifier une configuration de sécurité ou de déployer un script. Le partage SYSVOL, qui contient les fichiers de stratégie répliqués, doit être surveillé au même titre que l’objet GPO dans l’annuaire. Contrôler l’un sans l’autre laisse une porte entrouverte, ce qui est la position préférée des portes.

Les droits de réplication Replicating Directory Changes, Replicating Directory Changes All et Replicating Directory Changes In Filtered Set permettent une attaque dite DCSync : un compte demande aux contrôleurs de domaine de lui transmettre les données de réplication, y compris des secrets protégés. Ces droits ne doivent appartenir qu’aux contrôleurs de domaine et à des composants de synchronisation explicitement approuvés. Un outil de reporting qui les réclame n’est pas un outil de reporting, c’est une alarme avec une interface web.

Les objets ordinateurs méritent la même prudence que les comptes administrateurs. Le droit d’écriture sur l’attribut msDS-AllowedToActOnBehalfOfOtherIdentity peut activer la délégation Kerberos contrainte fondée sur une ressource, ou RBCD (Resource-Based Constrained Delegation). Avec un compte de machine contrôlé, cette configuration peut permettre l’usurpation d’un utilisateur vers un service cible. Restreindre également ms-DS-MachineAccountQuota, qui autorise par défaut certains utilisateurs authentifiés à créer des comptes ordinateurs.

L’accès LDAP (Lightweight Directory Access Protocol) anonyme ou en clair facilite l’inventaire initial d’un attaquant. Désactiver les liaisons anonymes et les authentifications simples non chiffrées fait partie du socle, avec la signature LDAP et la protection de canal lorsque les applications le supportent. Voir la désactivation des binds LDAP anonymes et en clair et l’énumération des métadonnées LDAP.

Exemple de délégation contrôlée avec DSACLS

Cet exemple délègue uniquement la réinitialisation de mot de passe et la création ou suppression d’utilisateurs dans une OU applicative. Il nécessite les outils RSAT (Remote Server Administration Tools), une session exécutée avec un compte autorisé à modifier la DACL de l’OU, et un groupe global déjà créé.

# Vérifier l'ACL existante avant toute modification.
dsacls "OU=Applications,DC=corp,DC=example,DC=com"

# Autoriser le groupe dédié à réinitialiser les mots de passe des objets utilisateur.
dsacls "OU=Applications,DC=corp,DC=example,DC=com" `
  /I:S `
  /G "CORP\GG-App-PasswordReset:CA;Reset Password;user"

# Autoriser la création et la suppression d'objets utilisateur, sans GenericWrite.
dsacls "OU=Applications,DC=corp,DC=example,DC=com" `
  /I:S `
  /G "CORP\GG-App-Provisioning:CCDC;user"

# Contrôler le résultat et archiver la sortie avec le dossier de changement.
dsacls "OU=Applications,DC=corp,DC=example,DC=com"

Tester avec un compte membre du groupe délégué et un compte qui n’en est pas membre. Vérifier la création d’un utilisateur, la réinitialisation d’un mot de passe, l’impossibilité de modifier les groupes privilégiés et l’impossibilité de changer la DACL. Une délégation sans test négatif valide seulement la moitié qui fait plaisir.

Éviter l’assistant graphique de délégation lorsque le résultat doit être auditable : il peut ajouter des droits hérités difficiles à distinguer lors d’une revue. Le résultat attendu est une ACL courte, reproductible et exportable, pas une forêt de cases cochées dont personne ne connaît la généalogie.

Exploitation : secrets, journalisation et reprise de forêt

La sécurité de l’annuaire dépend d’abord des secrets de ses comptes les plus puissants : compte krbtgt, comptes de contrôleurs de domaine, comptes de synchronisation, comptes de sauvegarde et comptes de service. Le mot de passe de krbtgt signe les tickets Kerberos. Après compromission de domaine, sa rotation doit être effectuée deux fois, avec validation de la réplication entre les deux rotations. Une seule rotation laisse généralement des tickets forgés exploitables avec l’ancienne clé.

Les comptes de service gérés de groupe, ou gMSA (group Managed Service Account), réduisent l’exposition des mots de passe statiques lorsque les applications Windows les supportent. Ils ne compensent pas une DACL permettant de modifier leurs attributs, ni une administration locale ouverte sur les serveurs qui les utilisent.

Activer une journalisation centralisée des modifications de groupes, de GPO, de DACL et des droits de réplication. Les événements Windows 4662, 4728, 4729, 4732, 4733, 5136 et 5141 sont particulièrement utiles, mais 4662 exige une liste de contrôle d’audit système, ou SACL (System Access Control List), correctement définie. Journaliser sans collecter, c’est fabriquer des confettis numériques.

Les sauvegardes doivent inclure l’état système des contrôleurs de domaine, être isolées des privilèges ordinaires et être testées via une procédure de récupération de forêt. Une sauvegarde accessible avec les mêmes identifiants que l’annuaire compromettra l’annuaire une seconde fois, avec une copie historique en prime. La reprise exige aussi la conservation documentée des clés de récupération, des comptes d’urgence et de l’ordre de reconstruction des services dépendants.

🐝 Ce qui arrive si on s’en passe

Sans structure d’OU ni délégations nommées, les autorisations s’empilent par héritage et deviennent impossibles à réviser : plus personne ne distingue un droit justifié d’un résidu laissé par un projet clos, et la révocation suppose une fouille d’ACL au lieu d’un retrait de membre. L’imputabilité disparaît aussi : quand une délégation repose sur un groupe générique de support, les journaux désignent une action valide sans permettre d’identifier l’opérateur. Côté attaquant, l’asymétrie est nette : un graphe de privilèges calcule un chemin vers le contrôle du domaine en quelques minutes, là où un inventaire manuel des ACE demande des semaines. Enfin, toute remise en ordre ultérieure coûte plus cher qu’une conception initiale, car retirer un droit en production casse des automatisations dont la dépendance n’a jamais été documentée.

🦫 Explication de la marmotte 🍫

Active Directory est le système qui conserve les comptes, les ordinateurs, les groupes et les autorisations d’une organisation. Il est organisé en ensembles très larges appelés forêts, en domaines qui regroupent des identités, puis en dossiers logiques appelés unités d’organisation. Ces dossiers servent à ranger les objets et à donner des droits limités à certaines équipes.

Une délégation autorise une équipe à faire une action précise, par exemple créer un compte ou réinitialiser un mot de passe. Cette autorisation est enregistrée dans une liste attachée au dossier concerné. Si cette liste donne le droit de modifier toutes les règles, de changer les droits ou de contrôler un groupe puissant, une personne qui obtient ce compte peut progressivement prendre le contrôle d’autres comptes et serveurs.

Les attaques suivent donc les permissions disponibles : modifier une règle appliquée aux serveurs, ajouter un compte dans un groupe, récupérer un secret ou demander la copie des données réservées aux serveurs centraux. La protection consiste à limiter chaque autorisation, séparer les comptes ordinaires des comptes d’administration, surveiller les modifications et supprimer les droits trop larges.

Si un serveur central est compromis, certains secrets doivent être remplacés dans un ordre précis. Les sauvegardes doivent aussi être protégées, car elles contiennent une copie des mêmes informations sensibles.