Délégations Active Directory : repérer et nettoyer les droits excessifs sur les OU et les objets

m365expertise·1 octobre 2026·8 min·1 726 vues

Les groupes privilégiés d'Active Directory sont généralement surveillés. Les permissions posées sur les unités d'organisation et les objets le sont beaucoup moins. Au fil des années, délégations au support, droits laissés par des produits installés puis oubliés et permissions accordées « temporairement » s'accumulent, et finissent par ouvrir des chemins directs vers les comptes les plus sensibles.

Comment une ACL devient un chemin d'attaque

Chaque objet de l'annuaire porte une liste de contrôle d'accès. Certains droits équivalent en pratique à la prise de contrôle de l'objet :

GenericAll : contrôle total, y compris réinitialiser le mot de passe d'un utilisateur ou ajouter des membres à un groupe ;
WriteDacl : modifier les permissions, donc s'accorder ensuite n'importe quel droit ;
WriteOwner : devenir propriétaire, ce qui donne implicitement le droit de modifier les permissions ;
GenericWrite ou écriture sur des attributs ciblés : par exemple servicePrincipalName pour rendre un compte vulnérable au Kerberoasting, msDS-KeyCredentialLink pour y ajouter des informations d'identification fictives, ou l'attribut de délégation contrainte basée sur les ressources d'un ordinateur ;
Droits étendus : réinitialisation du mot de passe, ou, sur l'objet domaine, les droits de réplication qui permettent une attaque DCSync.

Un attaquant n'a pas besoin d'être administrateur : il lui suffit de compromettre un compte qui détient l'un de ces droits sur un objet plus privilégié, puis d'enchaîner.

Les sources habituelles de droits excessifs

Dans les annuaires que nous auditons, les mêmes causes reviennent :

des délégations de réinitialisation de mot de passe posées à la racine du domaine ou sur une OU qui contient aussi des comptes d'administration ;
des permissions héritées d'anciennes versions d'Exchange, parfois très larges sur l'objet domaine, jamais réduites ;
des droits accordés à des comptes individuels plutôt qu'à des groupes, impossibles à suivre ;
des objets dont le propriétaire est un utilisateur standard, par exemple l'auteur d'une jonction de poste au domaine ;
l'usage des groupes intégrés comme Opérateurs de compte, dont les droits sont plus étendus qu'on ne le pense.

AdminSDHolder ne protège pas tout. Les membres des groupes protégés reçoivent régulièrement les permissions du modèle AdminSDHolder, ce qui écrase les délégations posées sur leur OU. Mais un compte retiré de ces groupes conserve un héritage désactivé, et un compte d'administration qui n'est membre d'aucun groupe protégé (droits accordés par délégation) hérite de toutes les permissions de son OU. Et si AdminSDHolder lui-même est modifié, la modification se propage à tous les comptes protégés.

Les outils d'analyse

Lire les ACL une à une n'est pas réaliste. Les outils d'analyse des chemins d'attaque, comme BloodHound, collectent les permissions et les appartenances, puis calculent les enchaînements possibles vers les groupes privilégiés. PingCastle, Purple Knight ou ADACLScanner signalent les délégations dangereuses et permettent de comparer des états successifs. Ces outils doivent être utilisés avec l'accord de l'équipe de sécurité et l'équipe de surveillance prévenue, puisqu'ils sont aussi utilisés par les attaquants.

Assainir sans casser

Le nettoyage suit une démarche prudente :

sauvegarder les descripteurs de sécurité des OU et objets concernés avant toute modification ;
définir le modèle de délégation cible : quels groupes, quels droits, sur quelles OU, en cohérence avec le modèle en niveaux ;
séparer physiquement les comptes d'administration dans des OU dédiées, sans délégation au support ;
remplacer les droits accordés à des comptes individuels par des groupes ;
réattribuer la propriété des objets sensibles aux administrateurs du domaine ;
traiter les permissions Exchange héritées selon les recommandations actuelles de Microsoft.

Puis relancer l'analyse : le nombre de chemins vers les groupes privilégiés doit diminuer, et rester à ce niveau dans le temps.

Pour que le nettoyage tienne, il faut aussi détecter les nouvelles dérives. L'audit des modifications du service d'annuaire, associé à des listes de contrôle d'audit système sur les objets sensibles, produit des événements lorsqu'un descripteur de sécurité est modifié (événement 5136 sur les contrôleurs de domaine). Remontés vers le SIEM, ils permettent d'alerter sur toute modification des permissions de l'objet domaine, d'AdminSDHolder ou des OU du Tier 0. Une analyse des chemins d'attaque relancée à intervalle régulier, par exemple chaque trimestre, complète ce dispositif et fournit un indicateur simple à suivre.

Ce qu'un audit vérifie

Les droits de contrôle (GenericAll, WriteDacl, WriteOwner, GenericWrite) sur l'objet domaine, AdminSDHolder et les OU sensibles.
Les droits de réplication accordés hors des contrôleurs de domaine et comptes légitimes.
Les délégations de réinitialisation de mot de passe et leur périmètre réel.
Les propriétaires des objets privilégiés et des comptes d'ordinateur sensibles.
Le nombre de chemins d'attaque vers les groupes privilégiés et son évolution.

Cet article vous a-t-il été utile ?

4,3 / 5 · 168 avis