Concevoir ses OU pour déléguer l'administration sans créer de chemins d'attaque
L'arborescence des unités d'organisation est souvent calquée sur l'organigramme, puis enrichie au fil des années de délégations ponctuelles. Le résultat : des droits que plus personne ne comprend et des chemins détournés vers les comptes les plus sensibles. Une conception pensée pour l'administration déléguée permet de reprendre la main.
Les OU servent l'administration, pas l'organigramme
Une unité d'organisation a deux fonctions techniques : porter des délégations de droits et recevoir des liens de stratégies de groupe. L'organigramme, lui, change à chaque réorganisation et se reflète mieux dans les attributs des utilisateurs (service, direction) ou dans des groupes. Une bonne arborescence répond donc à la question « qui administre quoi, et avec quelles stratégies ? », et non « qui travaille où ? ».
En pratique, on retrouve souvent un premier niveau par type d'objet ou par niveau d'administration, puis un découpage géographique ou par entité uniquement lorsque des équipes d'administration différentes le justifient.
Séparer les niveaux dès la racine
Les objets de niveau 0 (comptes d'administration du domaine, groupes privilégiés, serveurs AD CS, AD FS, Entra Connect, postes d'administration de niveau 0) doivent se trouver dans une branche dédiée, sur laquelle aucune délégation de niveau inférieur ne s'applique. Si les comptes d'administrateurs du domaine sont rangés dans la même OU que les utilisateurs, le support qui peut réinitialiser les mots de passe de cette OU peut, en théorie, prendre le contrôle d'un compte privilégié. Le même raisonnement s'applique aux niveaux 1 et 2 : les serveurs et leurs administrateurs ne cohabitent pas avec les postes de travail.
| Branche | Contenu | Administrée par |
|---|---|---|
| Niveau 0 | comptes et groupes d'administration du domaine, serveurs d'identité, PAW de niveau 0 | administrateurs de niveau 0 uniquement |
| Niveau 1 | serveurs, comptes de service applicatifs, administrateurs de serveurs | équipes serveurs |
| Niveau 2 | utilisateurs, postes de travail, groupes métier | support et équipes poste de travail |
Déléguer à des groupes, jamais à des personnes
Chaque délégation doit être accordée à un groupe de rôle (par exemple « Réinitialisation mots de passe - Utilisateurs Siège »), jamais à un compte nominatif. Les personnes changent de poste, les groupes restent. Un groupe nommé explicitement rend la délégation lisible dans les ACL et permet de revoir les membres sans toucher aux permissions. Les groupes locaux de domaine se prêtent bien à ce rôle de porteurs de droits.
Déléguez aussi finement que possible : réinitialiser un mot de passe et déverrouiller un compte ne nécessitent pas le contrôle total sur les objets utilisateurs. L'assistant Délégation de contrôle propose des tâches courantes, mais il est préférable de définir des modèles de délégation documentés et de les appliquer de manière cohérente.
Maîtriser l'héritage
Les droits posés sur une OU s'appliquent par défaut à tous ses descendants. Une délégation accordée sur une OU de haut niveau « pour simplifier » se propage à toutes les sous-OU, y compris celles créées plus tard. Plusieurs points méritent l'attention :
- déplacer un objet d'une OU à une autre change ses droits effectifs : c'est une opération à contrôler, et le droit de déplacer des objets est lui-même sensible ;
- les membres des groupes protégés sont soumis au mécanisme AdminSDHolder, qui remplace périodiquement leurs ACL et désactive l'héritage ; les anciens membres gardent souvent cette protection sans raison ;
- le propriétaire d'un objet dispose de droits implicites : les objets créés par un compte de support restent sa propriété, ce qui ouvre des chemins inattendus ;
- le blocage de l'héritage des stratégies de groupe n'a rien à voir avec l'héritage des permissions : ce sont deux mécanismes distincts.
Documenter et revoir
Une délégation non documentée devient invisible au bout de quelques années. Tenez un registre qui associe chaque délégation à un groupe, une OU, des droits précis, un responsable et une date de revue. Comparez-le régulièrement à la réalité des ACL, par exemple avec dsacls ou les cmdlets PowerShell de lecture des ACL, et supprimez les entrées orphelines (SID non résolus) ou accordées à des comptes nominatifs. Pensez aussi aux conteneurs par défaut CN=Users et CN=Computers, qui ne sont pas des OU : redirigez la création des nouveaux objets vers des OU gérées.
Test simple. Pour chaque groupe de délégation, posez la question : « Si un membre de ce groupe est compromis, jusqu'où l'attaquant peut-il aller ? » Si la réponse inclut un compte de niveau 0, la conception doit être revue.
Ce qu'un audit vérifie
- la séparation des objets de niveau 0 dans une branche sans délégation de niveau inférieur ;
- les ACL accordées à des comptes nominatifs ou à des SID orphelins ;
- les délégations de contrôle total ou d'écriture générique sur des OU entières ;
- les objets à
adminCount=1qui ne sont plus membres de groupes protégés ; - l'existence et l'actualité d'un registre des délégations.