Audit sécurité Active Directory : checklist pratique

Un audit de sécurité Active Directory doit faire plus que lister des mauvaises configurations. Il doit aider votre équipe à répondre à trois questions très concrètes :

Quelles découvertes exposent Tier 0 ou des identités privilégiées ?
Quels chemins peuvent réellement être exploités ensuite ?
Quelles remédiations doivent être traitées en premier ?

Si vous voulez aller au plus court, commencez par un workflow dédié Active Directory security audit et lancez le collecteur localement via ETC Collector. Si vous préférez d’abord la checklist complète, utilisez le guide ci-dessous.

1. Commencer par les identités privilégiées et le Tier 0

La plupart des programmes d’audit AD perdent du temps parce qu’ils commencent par l’hygiène générale au lieu de l’exposition privilégiée. Le premier passage doit se concentrer sur :

les groupes intégrés privilégiés comme Domain Admins, Enterprise Admins et Schema Admins
les chemins d’administration déléguée
les comptes disposant de droits de réplication
les comptes privilégiés avec mots de passe anciens ou protections faibles
les anomalies adminCount et protections orphelines

À ce stade, l’objectif est de savoir quelles identités peuvent modifier les limites de confiance du domaine, pas seulement quelles options semblent mal rangées.

2. Examiner Kerberos et les chemins d’abus de délégation

Les faiblesses Kerberos restent au cœur de nombreuses découvertes à fort impact dans AD. Un audit pratique doit rechercher :

les comptes kerberoastables
les comptes AS-REP roastables
la délégation non contrainte
la délégation contrainte avec cibles risquées
l’abus de délégation contrainte basée sur les ressources
les comptes privilégiés portant des SPN
les comptes encore dépendants de chiffrements faibles

Ces contrôles comptent parce qu’ils relient directement le vol d’identifiants, le mouvement latéral et l’escalade de privilèges.

3. Vérifier la politique de mot de passe et l’hygiène des comptes

La revue des politiques de mot de passe reste utile, mais elle doit être reliée à l’exposition et à l’impact de remédiation. Concentrez-vous sur :

password never expires
password not required
reversible encryption
les comptes privilégiés obsolètes
les comptes désactivés présents dans des groupes d’administration
la couverture insuffisante des fine-grained password policies

Si votre environnement contient encore des exceptions, documentez si elles sont justifiées, temporaires et portées par un owner identifié.

4. Auditer ADCS et les chemins d’abus de certificats

ADCS est souvent oublié dans les revues internes alors qu’il peut créer des chemins d’escalade directs. Votre audit doit couvrir :

les modèles de certificats vulnérables
les ACL dangereuses sur les templates
l’abus d’enrollment agent
le certificate mapping faible
les flags de CA risqués et certains réglages RPC

Si votre processus actuel n’évalue pas les chemins d’abus de certificats de type ESC, l’audit reste incomplet pour une défense AD moderne.

5. Inspecter les ACL, droits de réplication et chemins d’attaque

Une simple revue brute des ACL ne suffit pas. Il faut comprendre quelles permissions peuvent s’enchaîner en abus réellement exploitables. Un audit solide doit faire ressortir :

l’abus de GenericAll, WriteDacl, WriteOwner et des droits étendus
les droits de réplication et les principaux capables de DCSync
les permissions dangereuses sur les OU, les GPO et AdminSDHolder
les attack paths qui atteignent des actifs de niveau domaine en un ou deux sauts

C’est là qu’une analyse approfondie se distingue d’un simple contrôle de posture.

6. Inclure les GPO, la journalisation et le hardening

Les GPO et le hardening du plan de contrôle restent des sources de gains rapides. Vérifiez notamment :

une politique de mot de passe trop faible dans la Default Domain Policy
l’absence de LDAP signing ou de channel binding
une journalisation PowerShell insuffisante
un UNC path hardening manquant
des scripts d’ouverture de session risqués
une exposition SMB et TLS trop faible sur les contrôleurs de domaine

Ces découvertes semblent parfois purement opérationnelles, mais ce sont précisément les contrôles qui modifient le coût d’attaque dans la réalité.

7. Prioriser la remédiation selon l’impact sur l’identité

Ne traitez pas les remédiations comme une file plate. Groupez plutôt la sortie par impact :

critique : exposition privilégiée directe, raccourcis d’attack path, abus de certificats, capacité DCSync
élevé : abus de délégation, comptes privilégiés roastables, ACL risquées, protocoles anciens ou paramètres faibles
moyen : dérive d’hygiène et de politique qui augmente la surface d’attaque
faible : nettoyage informatif avec valeur d’exploitation limitée

Si vous avez besoin d’un workflow aligné sur ce modèle, la page Active Directory security audit montre comment structurer la revue, et EtcSec pricing explique quand la couche SaaS de suivi devient utile en complément de ETC Collector.

8. Répéter la revue après les changements

Un audit AD ne doit pas devenir un artefact annuel. Répétez les mêmes contrôles après :

des changements de rôles
des mises à jour de GPO
des changements sur les services de certificats
des modifications d’administration déléguée
des fusions, nouveaux sites ou nouveaux domaines

C’est aussi pour cette raison que des équipes évaluent une PingCastle alternative : le vrai problème n’est souvent pas le premier rapport, mais l’absence de boucle de revue répétable ensuite.

Conclusion

Un audit de sécurité AD efficace est une revue répétable de l’exposition privilégiée, pas juste un rapport de santé. Commencez par Tier 0, Kerberos, la délégation, ADCS et les chemins d’abus d’ACL. Ensuite, priorisez la remédiation en fonction de ce qui change réellement la portée d’un attaquant.

Si vous voulez un workflow dédié, partez de la page Active Directory security audit ou regardez comment ETC Collector exécute la collecte technique localement.

9. Constituer un pack de preuves pour chaque cycle de revue

Un audit AD utile devient plus rapide et plus cohérent dès que l’équipe s’accorde sur un pack de preuves récurrent. Au lieu de relancer des contrôles ad hoc à chaque changement d’administrateur, définissez à l’avance quels exports, captures et instantanés d’annuaire seront collectés à chaque revue. Cela facilite la comparaison d’un cycle à l’autre, la justification des priorités de remédiation et l’explication des constats encore ouverts.

Zone de revue	Preuves à collecter	Pourquoi c’est utile
Accès privilégié	Membres de Domain Admins, Enterprise Admins, groupes opérateurs et groupes d’admin déléguée	Montre les chemins les plus courts vers le Tier 0 et met en évidence les accès trop larges
Kerberos et délégation	Comptes avec SPN, comptes AS-REP roastables, délégation non contrainte et délégations contraintes risquées	Relie la mauvaise configuration au vol d’identifiants et au mouvement latéral
Réplication et abus d’ACL	Principaux capables de DCSync et ACL dangereuses sur les OU, GPO, AdminSDHolder et groupes clés	Fait ressortir des chemins d’abus qui ne paraissent pas toujours privilégiés au premier regard
ADCS	AC actives, modèles publiés, permissions risquées sur les templates et exposition d’enrollment agent	Couvre les escalades par certificats souvent oubliées en revue interne
Hardening et journalisation	LDAP signing, channel binding, journalisation PowerShell, réglages SMB et exposition de scripts	Vérifie si les contrôles compensatoires réduisent réellement la liberté d’un attaquant

L’objectif de ce pack de preuves n’est pas la bureaucratie, mais la cohérence. Lorsque les mêmes données sont exportées à chaque cycle, la revue devient comparable. L’équipe peut montrer qu’un chemin privilégié est nouveau, inchangé ou partiellement remédié au lieu de s’appuyer sur la mémoire. Il devient aussi plus simple de séparer les problèmes d’architecture des problèmes de nettoyage ou de gouvernance.

Une convention de nommage simple aide aussi. Stockez les exports par date de revue, domaine et zone de contrôle afin que le prochain analyste puisse rapidement comparer les résultats. Si plusieurs équipes participent, définissez qui collecte, qui valide les constats et qui signe les exceptions. L’audit devient alors un processus opératoire répétable au lieu d’un exercice technique ponctuel.

Audit de sécurité Active Directory : validation avant clôture

Une revue solide de Audit de sécurité Active Directory doit se terminer par des preuves de production, pas par l'hypothèse que le chemin risqué a disparu. Avant de clôturer le constat, revalidez les identités privilégiées, les délégations et les accès hérités, la portée réelle de la stratégie, de l'ACL, du groupe ou du GPO modifié et les logs ou la preuve de collecte liés au constat. Confirmez que l'état plus sûr s'applique bien au périmètre qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif ou le chemin de délégation et de confiance qu'un attaquant pourrait réellement exploiter. Documentez le propriétaire technique, la dépendance métier et la condition de retour arrière afin que le prochain cycle sache si l'état plus sûr a été maintenu.

Utilisez une checklist de clôture courte :

vérifier que l'état risqué a disparu du point de vue attaquant, pas seulement dans une capture d'écran admin
conserver un export avant/après ou un échantillon de log prouvant que la portée concernée a changé
documenter le propriétaire et la décision d'exception si le contrôle ne peut pas être appliqué complètement

Pour les expositions adjacentes, recoupez le résultat avec Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués, Supervision Sécurité AD : Événements Clés, Conformité AD & Azure : NIS2, ISO 27001, CIS, et Mots de passe dans les descriptions AD : détection et correction. Le même défaut de contrôle réapparaît souvent dans des chemins d'identité voisins, des manques de journalisation ou des délégations trop larges, d'où l'importance de cette validation finale.

Audit de sécurité Active Directory : preuves à conserver pour le prochain cycle

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez la preuve qui justifiait le constat initial, la preuve que le changement a été appliqué, et la note qui explique pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export courant des identités, groupes ou chemins délégués concernés, la preuve avant/après de la configuration ou du contrôle modifié et le ticket, le propriétaire et la note d'exception expliquant l'état final. Ce paquet compact accélère fortement les revues trimestrielles ou après changement et permet d'expliquer si le problème a été supprimé, réduit ou accepté formellement.

À conserver	Pourquoi c'est utile
Export d'identités, de groupes ou de chemins	Montre la portée concernée et les objets qui ont changé
Preuve de configuration ou de permission	Prouve que le contrôle est appliqué en production
Propriétaire, ticket et registre d'exception	Préserve la responsabilité et la justification métier

Si un changement d'admin, de politique ou d'application rouvre plus tard le chemin, cet historique permet aussi de démontrer précisément ce qui a dérivé. C'est ce qui transforme Audit de sécurité Active Directory en processus d'assurance répétable plutôt qu'en contrôle ponctuel.

FAQ

À quelle fréquence lancer un audit de sécurité AD ?

La plupart des équipes internes devraient relancer la revue de base au moins une fois par trimestre et après tout changement important d’identité. Cela inclut les fusions, restructurations de domaine, changements sur les services de certificats, nouveaux modèles d’administration déléguée ou refontes importantes de GPO. Si l’environnement change vite ou si plusieurs administrateurs interviennent, des contrôles mensuels sur l’exposition Tier 0 et les groupes privilégiés sont souvent justifiés.

Que faut-il corriger en premier après l’audit ?

Commencez par les constats qui donnent un accès privilégié direct ou presque direct. Une appartenance excessive à des groupes privilégiés, des comptes capables de DCSync, la délégation non contrainte, des modèles de certificats dangereux et des attack paths très courts doivent passer avant l’hygiène générale. Les problèmes d’ancienneté de mots de passe, les comptes obsolètes et les lacunes de journalisation restent importants, mais ils ne méritent pas la première place lorsqu’un chemin d’escalade domaine existe déjà.

Qui doit porter la remédiation ?

L’équipe sécurité doit généralement piloter la priorisation et la validation, mais le propriétaire de la remédiation doit être l’équipe capable de changer réellement la configuration risquée. Cela peut être l’équipe AD, l’équipe poste de travail, les propriétaires PKI ou les équipes applicatives dépendantes de comptes de service. L’audit devient plus efficace lorsque chaque constat majeur a un owner nommé, une date cible et une décision explicite si le risque ne peut pas être supprimé immédiatement.

ADCS doit-il toujours être dans le périmètre ?

Si ADCS existe quelque part dans la forêt, il doit être dans le périmètre. Les chemins d’escalade par certificats peuvent annuler des efforts pourtant solides sur les groupes, la politique de mot de passe ou le durcissement de la délégation. Les équipes internes laissent souvent ADCS à une revue PKI séparée, mais cette séparation crée des angles morts. Un audit AD est plus solide lorsqu’il traite les templates, les droits d’enrôlement et les réglages de CA comme faisant partie de la même exposition privilégiée.

Quelles preuves conserver entre deux cycles d’audit ?

Conservez assez d’éléments pour montrer ce qui a changé, ce qui reste ouvert et ce qui a été accepté comme exception. En pratique, cela signifie généralement les exports utilisés dans la revue, la liste finale des constats, le tracker de remédiation et le registre des exceptions avec owner et date de relecture. Garder uniquement le rapport final ne suffit pas, car cela ralentit la revue suivante et affaiblit la démonstration de progrès.

Quand faut-il coupler l’audit AD avec une revue Entra ID ?

Si des administrateurs privilégiés s’authentifient aussi à des services cloud, si la synchro hybride ou la gestion d’applications influence des identités critiques, ou si les procédures de reprise dépendent de rôles cloud, la revue AD doit être couplée à une revue Entra. Beaucoup d’équipes découvrent que la posture on-prem semble plus propre que le plan de contrôle d’identité global. Combiner la vue Active Directory security audit et la vue Microsoft Entra ID security audit aide à éviter ces angles morts.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a Outils d’audit de sécurité Active Directory : quoi comparer avant de choisir, Chemins d'Attaque AD : Mauvaises Configurations en Chaîne, Supervision Sécurité AD : Événements Clés, Mots de Passe AD : Erreurs de Configuration Critiques et Conformité AD & Azure : NIS2, ISO 27001, CIS. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

Ces liens internes gardent la remediation centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Audit de sécurité Active Directory : checklist pratique