Audit de sécurité Active Directory

Pour mener un audit de sécurité active directory solide, il faut partir des preuves plutôt que d’une checklist générique. Un audit Active Directory défendable doit montrer quelles identités peuvent contrôler l’annuaire, quelles permissions peuvent répliquer des secrets ou réécrire des frontières de confiance, quels paramètres de protocole ou de certificat créent encore des chemins d’attaque courts, et quelles preuves vous conserverez pour vérifier ensuite la remediation.

Ce guide reste centré sur Active Directory on-prem. Si vos opérateurs, vos rôles privilégiés ou vos workflows de reprise dépendent aussi de Microsoft Entra, il faut mener cette revue en parallèle d’une évaluation Entra distincte au lieu de fusionner les deux périmètres dans un rapport flou. L’objectif ici est plus précis : montrer ce qu’un audit AD doit couvrir en premier, quels constats méritent une remediation prioritaire, et comment prouver qu’une correction a réellement modifié le plan de contrôle.

Un audit AD utile doit produire cinq sorties :

un inventaire cadré des surfaces de l’annuaire qui comptent réellement
une liste d’identités et de permissions capables de contrôler des actifs privilégiés ou de répliquer des secrets
une liste plus courte de chemins d’attaque qui exigent une remediation immédiate
des preuves que les contrôles de durcissement sont bien appliqués en production
un pack de validation comparable au cycle d’audit suivant

Audit de sécurité Active Directory : que signifie réellement cet audit ?

Un audit Active Directory n’est ni un simple contrôle de politique de mot de passe, ni un rapport d’état ponctuel. C’est une revue fondée sur des preuves des identités, permissions, services, stratégies et télémétries qui déterminent qui peut contrôler l’annuaire et à quelle vitesse ce contrôle pourrait être abusé.

Autrement dit, la sortie de l’audit doit répondre à des questions concrètes :

Quels utilisateurs, groupes, comptes de service ou ordinateurs disposent d’un contrôle sur l’ensemble du domaine, ou presque ?
Quels droits peuvent répliquer des données sensibles de l’annuaire ou réécrire des frontières de confiance ?
Quels paramètres de protocole et de délégation réduisent le coût d’attaque pour un adversaire ?
Quels constats relèvent seulement de la dérive de configuration, et lesquels créent de vrais chemins d’escalade ?
Quelles exportations, quels journaux et quels snapshots d’état prouvent qu’une correction est réelle ?

Si la revue ne peut pas répondre à ces questions, elle reste une checklist, pas un audit. Cette distinction compte, car un environnement peut sembler acceptable dans un tableur de conformité tout en exposant encore des chemins courts vers Domain Admin via des droits de réplication, la délégation, des comptes privilégiés obsolètes ou l’abus de certificats.

Définir le périmètre avant de revoir les constats

La manière la plus rapide de perdre du temps consiste à analyser les constats avant d’avoir défini le périmètre.

Décisions de périmètre obligatoires

Décidez d’abord quelles surfaces de l’annuaire sont réellement en jeu :

le domaine ou la forêt examinés
les contrôleurs de domaine et les groupes d’administration privilégiés
les groupes d’administration déléguée et les comptes de service à fort impact
les droits de réplication, les objets sensibles du point de vue ACL, et les frontières d’héritage
la délégation Kerberos et l’exposition des service principals
les Group Policy, la posture LDAP, Windows LAPS et la policy d’audit
AD CS, mais uniquement s’il existe dans la forêt

Le périmètre doit rester honnête. Si AD CS n’est pas déployé, il faut l’indiquer comme hors périmètre et passer à la suite. Si une équipe PKI séparée en est propriétaire mais qu’AD CS existe bien dans la forêt, il fait partie de l’audit parce que l’émission de certificats peut encore modifier l’exposition privilégiée. La même règle vaut pour l’identité hybride : si Microsoft Entra affecte des opérateurs privilégiés, des chemins de reprise ou l’administration applicative, notez la dépendance, mais ne prétendez pas qu’une revue Entra remplace une revue AD.

Exigences de preuve avant le premier export

C’est aussi à ce moment qu’il faut décider quelles preuves seront conservées entre les cycles. Si l’audit doit plus tard démontrer qu’un groupe privilégié a été nettoyé ou qu’un droit dangereux a été retiré, cette exigence doit être capturée avant le premier export.

Revoir d’abord les accès privilégiés et le Tier 0

Commencez par le plan de contrôle de l’annuaire, souvent désigné opérationnellement comme le Tier 0. Cela signifie revoir les identités et les chemins d’administration qui peuvent modifier directement le domaine, les contrôleurs de domaine, les frontières de confiance ou les objets qui les protègent.

Ce qu’il faut revoir au premier passage

Revoir au minimum :

les groupes privilégiés natifs et personnalisés
les groupes d’administration déléguée et les chaînes d’imbrication de groupes
les comptes privilégiés obsolètes et les anciens comptes d’exception
les comptes de service privilégiés qui conservent encore des droits permanents
la séparation administrative entre identités utilisateur standard et identités d’administration

C’est le bon point de départ parce que les mauvaises pratiques d’administration et le cloisonnement insuffisant sont précisément là où les compromissions AD prennent racine. Le guide ANSSI 2023 sur l’administration des SI reposant sur AD indique explicitement que les compromissions AD résultent de mauvaises pratiques d’administration et d’un cloisonnement insuffisant, puis décrit comment des attaquants utilisent les mouvements latéraux et l’escalade de privilèges pour prendre le contrôle complet de l’annuaire.

Ce que cette section doit prouver

Le test pratique est simple : pouvez-vous expliquer qui administre l’annuaire, depuis où, avec quel type de compte, et pourquoi cet accès existe encore ? Si ce n’est pas le cas, l’audit doit s’arrêter ici en premier. Un annuaire avec une politique de mot de passe propre mais une conception faible des accès privilégiés reste un annuaire faible.

Pour les schémas de dérive associés, appuyez-vous sur Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits et Stale Privileged Accounts: Hidden Risk in Active Directory.

Auditer les droits de réplication, l’abus d’ACL et les chemins d’attaque courts

Après les groupes privilégiés, il faut revoir les permissions qui peuvent les contourner silencieusement. Un audit AD sérieux doit inclure les principaux capables de répliquer des secrets et ceux qui disposent d’un contrôle large sur des objets sensibles.

Les droits qui méritent une revue immédiate

Microsoft documente DS-Replication-Get-Changes-All comme un droit de contrôle d’accès permettant la réplication de données secrètes du domaine. Cela suffit à faire des droits de réplication un sujet d’audit de premier ordre, pas un edge case avancé. Si vous ne savez pas précisément quels principaux détiennent des droits liés à la réplication, l’audit est incomplet.

La même logique vaut pour le contrôle des objets. Il ne s’agit pas uniquement de repérer l’appartenance évidente à des groupes admins. Il faut identifier les chemins de modification, de gestion des permissions ou de prise de propriété sur des objets à forte valeur tels que :

la racine du domaine
les groupes privilégiés
AdminSDHolder
les OU qui hébergent des administrateurs sensibles, des serveurs ou des GPO
les conteneurs liés à des GPO capables de modifier la posture de sécurité à grande échelle

Quelle télémétrie aide à valider les changements

La journalisation est utile ici, mais elle doit être décrite avec précision. Event 5136 est généré lorsqu’un objet de service d’annuaire est modifié, mais seulement si l’objet possède l’entrée SACL pertinente. Event 4662 enregistre les opérations réalisées sur un objet AD, mais là encore uniquement si la SACL appropriée existe et si l’opération la déclenche. Aucun de ces événements n’est un détecteur magique. Ce sont des points de preuve utiles pour valider des changements à forte valeur ou surveiller des objets précis une fois le périmètre correctement cadré.

C’est pourquoi il faut raisonner en chemins d’attaque. La question n’est pas seulement de savoir si un droit existe. La vraie question est de savoir si ce droit crée un chemin court vers le contrôle de l’annuaire. Pour une revue plus profonde, complétez avec ACL Abuse and DCSync: The Silent Paths to Domain Admin et Active Directory Attack Paths to Domain Admin.

Revoir Kerberos, la délégation et l’exposition des comptes de service

Kerberos reste central dans l’exposition AD, en particulier via les comptes de service et les paramètres de délégation.

Comptes et réglages à revoir en premier

Revoir au minimum :

les comptes utilisateur ou de service avec SPN
les comptes privilégiés qui exposent aussi des SPN
l’unconstrained delegation
la constrained delegation et la resource-based constrained delegation lorsqu’elles sont utilisées
les comptes de service sans propriétaire clair, sans revue récente, ou sur-privilégiés

Pourquoi l’exposition des comptes de service fait partie du cœur de l’audit

Les comptes portant des SPN entrent naturellement dans le périmètre parce que le Kerberoasting repose sur des tickets de service demandés pour ces SPN, ce qui explique pourquoi MITRE ATT&CK T1558.003 reste une référence utile de contexte détection pour un audit technique. L’audit n’a pas besoin d’un walkthrough d’exploitation. En revanche, il doit montrer quels comptes de service exposent une opportunité de cassage offline et si certains d’entre eux sont aussi privilégiés.

La délégation exige le même niveau de précision. Microsoft décrit la constrained delegation comme une forme plus restrictive de délégation que l’unconstrained delegation, parce qu’elle limite les services vers lesquels un serveur peut agir pour le compte d’un utilisateur. Cela ne rend pas automatiquement la constrained delegation sûre. Cela signifie seulement qu’elle doit être revue dans son contexte : quels services frontaux sont autorisés, quels services back-end leur font confiance, et si le besoin métier existe encore.

Si vous voulez l’analyse dédiée de la délégation, utilisez Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. Dans l’audit lui-même, gardez le focus sur l’ownership, le privilège et les chemins d’abus atteignables.

Inclure AD CS s’il existe dans la forêt

Si Active Directory Certificate Services est déployé quelque part dans la forêt, il faut l’inclure. Microsoft documente AD CS comme un rôle Windows Server permettant d’émettre et de gérer des certificats PKI utilisés dans des protocoles d’authentification et de communication sécurisée. Cela suffit à le traiter comme une brique d’identité, et non comme un sujet secondaire pour une future revue PKI.

Ce que la partie AD CS doit couvrir

Un audit AD pertinent doit donc revoir :

les CA d’entreprise qui émettent des certificats utiles à l’authentification
les templates de certificats publiés
qui peut s’enrôler et qui peut modifier les permissions des templates
si l’émission de certificats élargit l’exposition privilégiée
si des chemins certificats créent des routes d’escalade qui contournent le durcissement déjà réalisé sur les groupes et la délégation

Il ne faut pas supposer que tous les environnements AD ont AD CS. En revanche, si AD CS existe, il ne faut pas le sortir du périmètre. L’émission de certificats et les permissions de templates peuvent changer de manière concrète qui peut s’authentifier et en tant que qui. Pour le détail technique des chemins certificats, voir ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

Vérifier GPO, LDAP, LAPS et les contrôles de journalisation

Une fois les chemins privilégiés et les mécanismes d’escalade compris, il faut revoir les contrôles censés durcir l’environnement et produire la télémétrie sur laquelle l’équipe s’appuie.

Contrôles à valider directement

Pour LDAP, Microsoft indique que LDAP signing signe cryptographiquement les communications LDAP pour en vérifier l’authenticité et l’intégrité, tandis que channel binding lie la sécurité applicative à la session TLS sous-jacente. En pratique, l’audit doit confirmer la stratégie réellement appliquée sur les contrôleurs de domaine, pas seulement le standard visé. Ce point est encore plus important aujourd’hui parce que Microsoft documente clairement les frontières de version : les nouveaux déploiements Active Directory sur Windows Server 2025 exigent LDAP signing par défaut, tandis que les environnements mis à niveau conservent leur stratégie existante. Cela signifie qu’il faut auditer la posture effective, pas supposer le défaut. Pour les détails de configuration et de validation, utilisez LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

Pour Windows LAPS, Microsoft documente le fait que la fonctionnalité gère automatiquement et sauvegarde les mots de passe administrateur locaux, et qu’elle peut aussi sauvegarder le mot de passe DSRM des contrôleurs de domaine Active Directory. Un audit AD doit donc vérifier non seulement si LAPS est présent, mais aussi si la population visée est bien couverte, où les mots de passe sont sauvegardés, qui peut les lire, et si la protection DSRM est configurée là où elle est nécessaire. Pour l’angle opérationnel, voir Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

La journalisation qui prouve les changements de contrôle

Pour la journalisation, la formulation doit rester exacte :

Audit Security Group Management couvre les changements tels que la création, la suppression ou l’ajout et la suppression de membres dans les groupes.
Event 5136 aide à valider les modifications d’objets lorsque la bonne SACL existe.
Event 4662 aide à surveiller les opérations sur des objets AD sensibles quand l’audit directory service access et les SACL sont bien configurés.

Microsoft indique également que les advanced audit policy settings peuvent être gérés via Group Policy afin que les organisations puissent modifier, tester et déployer un audit plus granulaire sur les utilisateurs et groupes qui comptent réellement. C’est la bonne posture opérationnelle : tester la policy, confirmer le volume d’événements et leur rétention, puis vérifier que l’équipe exploite réellement les preuves produites. Pour les événements les plus importants après déploiement, voir Active Directory Monitoring: Security Event IDs That Matter.

Les preuves à conserver entre les cycles d’audit

Un audit AD utile laisse derrière lui un pack de preuves réutilisable, pas seulement un slide deck.

Pack de preuves minimal

Zone de revue	Preuves à conserver	Pourquoi c’est important
Accès privilégiés	Exports des groupes admins natifs, des groupes d’administration déléguée et des groupes imbriqués à fort impact	Prouve si le privilège permanent a réellement changé d’un cycle à l’autre
Réplication et exposition ACL	Principaux avec droits liés à la réplication, plus exports ACL sur la racine du domaine, `AdminSDHolder`, les OU clés et les groupes privilégiés	Montre si des chemins de réplication de secrets ou de contrôle d’objet ont vraiment disparu
Kerberos et délégation	Comptes avec SPN, paramètres de délégation et inventaire des comptes de service privilégiés	Confirme si le risque comptes de service et délégation a réellement diminué
AD CS	Inventaire des CA, templates publiés et snapshots de permissions des templates quand AD CS existe	Évite que l’exposition certificats disparaisse dans une revue séparée
Durcissement et télémétrie	État LDAP signing, couverture Windows LAPS, exports GPO et policies d’audit, plus métadonnées d’exécution de l’audit	Prouve que les contrôles de durcissement et de supervision sont réels et répétables

Conservez la date, le périmètre, la source et le propriétaire avec chaque artefact. Si le cycle suivant ne peut pas comparer des exports strictement comparables, l’équipe passera son temps à débattre pour savoir si un constat est nouveau au lieu de prouver qu’un chemin a disparu.

Remediation : prioriser selon l’impact sur l’identité

Il ne faut pas remédier en file plate. Il faut commencer par ce qui change le plus directement la portée d’un attaquant.

Les corrections qui doivent généralement passer en premier

Les remediations de première priorité incluent généralement :

les droits liés à la réplication qui exposent des données secrètes du domaine
les chemins ACL ou d’héritage qui créent des routes courtes vers des objets privilégiés
l’unconstrained delegation et les comptes de service privilégiés très exposés
les mauvaises configurations AD CS qui créent des abus d’authentification ou d’enrôlement

Les contrôles qui renforcent le cycle suivant

Ensuite viennent les contrôles qui réduisent la liberté de l’attaquant et améliorent la validation future :

la posture LDAP signing et channel binding
la couverture Windows LAPS et l’hygiène des mots de passe privilégiés
les lacunes de policy d’audit qui rendent les objets à forte valeur effectivement non surveillés

Ce n’est qu’après cela qu’il faut consacrer de l’énergie à des tâches de nettoyage qui améliorent la gouvernance sans raccourcir de manière significative un chemin d’attaque. C’est aussi pour cela qu’une revue répétable compte davantage qu’un rapport statique. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works couvre le modèle opératoire, tandis que Active Directory Security Audit Tools: What to Compare Before You Choose traite la question outillage.

Validation après remediation

Un constat n’est pas clos parce qu’un ticket dit qu’il est clos. Il faut valider depuis la même surface de contrôle qui a exposé le problème.

Après un nettoyage d’accès privilégiés, relancez les exports de groupes et d’administration déléguée et confirmez que l’identité ne détient plus le chemin effectif. Après un nettoyage de droits de réplication, confirmez que le principal n’apparaît plus dans l’ensemble de revue réplication. Après un durcissement LDAP, vérifiez la policy effective et validez que les binds non signés sont bien rejetés comme prévu. Après un déploiement Windows LAPS, confirmez l’application de la policy et l’état de sauvegarde des mots de passe sur la population visée. Après une correction AD CS, vérifiez que le template risqué, le périmètre d’enrôlement ou le chemin de permission ont réellement disparu.

Ce qu’un constat clos doit contenir

La télémétrie doit aussi être validée. Si vous comptez sur 5136 ou 4662 pour produire des preuves de futurs changements sur des objets sensibles, il faut démontrer que le modèle de SACL et la policy d’audit génèrent réellement les événements attendus. Si les changements de groupes sont critiques, il faut démontrer que les événements correspondants sont bien présents dans la chaîne de journalisation et conservés assez longtemps pour être utiles.

Le pack de clôture final doit inclure :

l’état avant et après
le propriétaire du changement
la méthode de validation
l’exception résiduelle éventuelle
la date de recontrôle du constat

C’est ce qui transforme un audit AD en contrôle répétable plutôt qu’en document qui devient obsolète dès que le changement de délégation suivant arrive.

Comment EtcSec aide à structurer un audit AD répétable

EtcSec doit s’inscrire dans ce workflow, pas le remplacer par du langage marketing. La partie utile, c’est la répétabilité.

Où le produit s’insère, et où il ne s’insère pas

Un audit AD répétable a besoin de relancer les mêmes contrôles sur les mêmes surfaces afin de montrer si un chemin privilégié est nouveau, inchangé ou réellement corrigé. EtcSec aide à structurer cela en gardant la revue ancrée sur des constats concrets comme EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED et LAPS_NOT_DEPLOYED.

Le modèle de déploiement actuel permet aussi une collecte locale au lieu d’obliger l’audit à démarrer comme un exercice purement SaaS. C’est important sur le plan opérationnel, parce que les preuves AD sont meilleures quand le chemin de collecte reste stable, quand les mêmes contrôles sont remesurés après remediation, et quand les sorties peuvent être conservées entre les cycles.

La valeur pratique reste donc étroite et testable : structurer l’audit, garder l’ensemble des constats mesurable, et rendre les reruns plus faciles à défendre. Si la question porte sur le choix d’outil plutôt que sur la méthode d’audit, utilisez Active Directory Security Audit Tools: What to Compare Before You Choose.

Audit de sécurité Active Directory : quoi vérifier d’abord et comment prouver la remediation