Les groupes privilégiés oubliés : opérateurs, DnsAdmins et autres portes dérobées d'AD
La revue des comptes privilégiés s'arrête souvent à Domain Admins. Or plusieurs groupes intégrés, hérités des débuts de Windows NT, offrent des chemins directs vers le contrôle des contrôleurs de domaine. Ils sont rarement surveillés et parfois généreusement peuplés.
Pourquoi ces groupes posent problème
Les groupes « opérateurs » ont été conçus pour déléguer des tâches d'exploitation sans donner les pleins pouvoirs. Dans les faits, leurs droits sur les contrôleurs de domaine sont suffisants pour obtenir un contrôle complet. Ils sont protégés par AdminSDHolder, ce qui confirme que Microsoft les considère comme sensibles.
Groupe par groupe
| Groupe | Pourquoi il est dangereux |
|---|---|
| Account Operators | Crée et modifie la plupart des comptes et groupes non protégés, et peut ouvrir une session locale sur les contrôleurs par défaut. |
| Server Operators | Ouvre une session sur les contrôleurs, gère les services, sauvegarde et restaure des fichiers : modifier un service exécuté en SYSTEM suffit. |
| Backup Operators | Le privilège de sauvegarde permet de lire tout fichier, y compris la base NTDS et les ruches du registre d'un contrôleur. |
| Print Operators | Ouvre une session sur les contrôleurs et gère les pilotes d'impression, historiquement associé au chargement de pilotes. |
| DnsAdmins | Peut configurer le service DNS, qui tourne en SYSTEM sur les contrôleurs hébergeant le DNS ; un paramètre de plugin permet d'y charger du code. |
| Schema Admins | Modifie le schéma de la forêt, une opération rare et en grande partie irréversible. |
| Enterprise Admins | Contrôle total de tous les domaines de la forêt. |
| Group Policy Creator Owners | Crée des GPO et en devient propriétaire ; combiné à un droit de liaison, cela devient un chemin d'attaque. |
La cible : des groupes vides
La recommandation courante, reprise par Microsoft dans ses guides de sécurisation d'AD, est que Account Operators, Server Operators, Backup Operators et Print Operators restent vides. Les tâches correspondantes se délèguent de façon fine sur des OU ou via des outils dédiés. Schema Admins et Enterprise Admins ne doivent être peuplés que pendant une intervention planifiée, puis vidés.
DnsAdmins est un cas à part : il faut le traiter comme un groupe de niveau 0, limité à quelques comptes d'administration dédiés. Même logique pour les comptes de sauvegarde : l'agent de sauvegarde des contrôleurs a besoin de privilèges élevés, il doit donc être protégé comme un compte de niveau 0.
Piège fréquent. Les appartenances imbriquées. Un groupe « IT-Infra » membre de Server Operators rend tous ses membres, et les membres de ses sous-groupes, capables d'administrer les contrôleurs. Contrôlez toujours l'appartenance récursive.
'Account Operators','Server Operators','Backup Operators',
'Print Operators','DnsAdmins','Schema Admins','Enterprise Admins',
'Group Policy Creator Owners' | ForEach-Object {
$g = $_
Get-ADGroupMember -Identity $g -Recursive |
Select-Object @{n='Group';e={$g}}, SamAccountName, objectClass
}
Surveiller les changements
Tout ajout à l'un de ces groupes doit générer une alerte : événements 4728, 4732 et 4756 selon l'étendue du groupe. Un ajout légitime est rare et planifié ; un ajout inattendu est un signal fort.
Ce qu'un audit vérifie
- L'appartenance récursive de chaque groupe intégré privilégié.
- Les comptes orphelins dont
adminCountvaut encore 1. - La présence d'alertes sur les modifications de ces groupes.
- La justification écrite de chaque membre restant.