Active Directory : configurer une stratégie d'audit avancée avec GPO

Dans un environnement Active Directory, les journaux de sécurité des contrôleurs de domaine constituent la source de détection primaire de la grande majorité des incidents de cybersécurité. Authentifications suspectes, modifications d'objets AD, élévations de privilèges, verrouillages de comptes, tentatives de déchiffrement Kerberos : tout ce qui se passe sur le domaine laisse une trace dans les Event Logs — à condition que l'audit soit correctement configuré. Sans configuration d'audit, les journaux restent muets et les attaquants peuvent agir en toute discrétion pendant des semaines ou des mois. Les réglementations et référentiels tels que la directive NIS 2, le RGPD, ISO 27001, et les recommandations du CIS (Center for Internet Security) imposent ou recommandent fortement la mise en place d'un audit de sécurité Active Directory complet et centralisé. L'ANSSI, dans ses guides de sécurisation des SI, insiste particulièrement sur la nécessité de journaliser tous les événements d'authentification et de modification d'objets AD. Ce guide vous explique comment passer de l'audit de base (souvent trop limité) à l'audit avancé d'Active Directory, comment configurer les 9 catégories d'audit via GPO ou auditpol.exe, quels Event IDs surveiller en priorité, comment dimensionner et centraliser vos journaux vers un SIEM, et comment valider que votre configuration d'audit fonctionne correctement.

Audit de base vs audit avancé — différences et recommandations ANSSI/CIS

Windows Server propose deux niveaux de configuration d'audit : l'audit de base (Basic Audit Policy) et l'audit avancé (Advanced Audit Policy).

L'audit de base, accessible via Computer Configuration → Windows Settings → Security Settings → Local Policies → Audit Policy, offre 9 catégories grossières : Account Logon, Account Management, Directory Service Access, Logon Events, Object Access, Policy Change, Privilege Use, Process Tracking, System Events. Chaque catégorie se configure avec une valeur unique (Success, Failure, ou les deux). Ce niveau manque de granularité et peut générer des volumes de logs très importants sans informations utiles.

L'audit avancé, accessible via Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration, offre 53 sous-catégories réparties en 10 catégories. Il permet une configuration fine : par exemple, auditer uniquement les échecs de Kerberos Pre-Authentication sans auditer tous les succès, réduisant le volume de logs tout en conservant les événements pertinents.

Lorsque les deux politiques sont configurées, l'audit avancé prend la priorité si la clé de registre HKLM\System\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy = 1 est définie (ce qui est le cas par défaut depuis Windows 7/2008 R2). Le CIS Benchmark et le guide ANSSI recommandent explicitement d'utiliser exclusivement l'audit avancé pour les contrôleurs de domaine en production.

Il est important de noter que la configuration d'audit s'applique sur les DC qui génèrent les événements, pas sur un DC central. Chaque DC doit avoir la même politique d'audit via une GPO liée au niveau de l'OU "Domain Controllers".

Les 9 catégories d'audit avancé (Account Logon, Account Management, DS Access...)

Les catégories d'audit avancé sont organisées de façon logique et couvrent l'ensemble des activités sensibles :

1. Account Logon : Authentifications via Kerberos (événements 4768, 4769, 4770, 4771, 4772) et NTLM (4776). Critique pour détecter les attaques Pass-the-Hash, Kerberoasting et AS-REP Roasting.

2. Account Management : Création, modification, suppression et réinitialisation de comptes et de groupes (4720, 4722-4729, 4731-4734, 4740). Essentiel pour détecter la création de comptes backdoor et les modifications de groupes privilégiés.

3. Detailed Tracking : Création et fin de processus (4688, 4689), activité DPAPI (4692, 4693). Utile pour détecter l'exécution de malwares et d'outils d'attaque.

4. DS Access : Accès aux objets Active Directory (4662), modification d'objets AD (5136), déplacement d'objets (5137). Fondamental pour détecter les attaques DCSync, les modifications de permissions AD et l'exploitation de délégations.

5. Logon/Logoff : Connexions et déconnexions (4624, 4625, 4634, 4647, 4648, 4649). Source principale des Event IDs les plus surveillés en SOC.

6. Object Access : Accès aux fichiers, dossiers, registre, imprimantes, handles. Nécessite une configuration SACL sur les objets à surveiller en plus de la politique d'audit.

7. Policy Change : Modifications des politiques d'audit, de Kerberos, de confiance (4670, 4715, 4719, 4739, 4865-4867). Détecte les tentatives de désactivation de l'audit ou de modification des politiques de sécurité.

8. Privilege Use : Utilisation de privilèges spéciaux (4672, 4673, 4674). Permet de suivre l'utilisation de droits administratifs sensibles.

9. System : Démarrage/arrêt du système (4608, 4616, 4621), changements d'heure système, état du service d'audit (4612). Important pour détecter les manipulations anti-forensiques.

Configurer l'audit via GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy)

La configuration via GPO est la méthode recommandée car elle garantit la cohérence sur tous les DC et est versionnée dans SYSVOL.

Créez une GPO dédiée liée à l'OU "Domain Controllers" :

1. Ouvrez la Console de Gestion des Stratégies de Groupe (GPMC)
2. Naviguez vers votre domaine → Domain Controllers
3. Clic droit → Créer un GPO dans ce domaine et le lier ici → nommez "Audit Policy - Domain Controllers"
4. Modifiez la GPO → Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration

Configuration recommandée pour chaque catégorie :

Account Logon :

• Audit Credential Validation : Success, Failure
• Audit Kerberos Authentication Service : Success, Failure
• Audit Kerberos Service Ticket Operations : Success, Failure

Account Management :

• Audit Computer Account Management : Success
• Audit Other Account Management Events : Success
• Audit Security Group Management : Success
• Audit User Account Management : Success, Failure

DS Access :

• Audit Directory Service Access : Success, Failure
• Audit Directory Service Changes : Success

Logon/Logoff :

• Audit Account Lockout : Failure
• Audit Logoff : Success
• Audit Logon : Success, Failure
• Audit Other Logon/Logoff Events : Success, Failure
• Audit Special Logon : Success

Policy Change :

• Audit Audit Policy Change : Success
• Audit Authentication Policy Change : Success
• Audit Authorization Policy Change : Success

Privilege Use :

• Audit Sensitive Privilege Use : Success, Failure

Après modification, forcez l'application sur tous les DC :

Invoke-Command -ComputerName (Get-ADDomainController -Filter *).HostName `
  -ScriptBlock { gpupdate /force }

Configurer avec auditpol.exe (ligne de commande, vérification)

auditpol.exe est l'outil en ligne de commande pour gérer les politiques d'audit. Il est particulièrement utile pour vérifier la configuration réelle appliquée sur un DC (qui peut différer de la GPO en cas de conflit) et pour les scripts d'automatisation.

# Voir la configuration d'audit actuelle (toutes catégories)
auditpol /get /category:*

# Voir une catégorie spécifique
auditpol /get /category:"Logon/Logoff"

# Résultat exemple:
# System audit policy
# Category/Subcategory               Setting
# Logon/Logoff
#   Logon                            Success and Failure
#   Logoff                           Success
#   Account Lockout                  Failure
#   ...

# Configurer une sous-catégorie spécifique
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Vérifier la configuration effective vs GPO
auditpol /get /category:* /r > C:\logs\audit-config.csv

Pour vérifier si la politique avancée écrase la politique de base :

# Vérifier la clé de registre
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "SCENoApplyLegacyAuditPolicy"
# Valeur 1 = audit avancé prioritaire (correct)

# Si absent ou = 0, forcer via GPO:
# Computer Config → Windows Settings → Security Settings → Local Policies → Security Options
# "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" = Enabled

Il est important de noter que auditpol configure la politique locale du DC. Si une GPO est appliquée, elle peut écraser la configuration auditpol lors du prochain cycle GPO. Utilisez toujours la GPO comme source de vérité et auditpol uniquement pour la vérification ou les ajustements temporaires d'urgence.

Les événements de sécurité critiques à surveiller

Parmi les centaines d'Event IDs possibles, voici les plus critiques pour la sécurité Active Directory :

Authentification :

4624 — Logon réussi. Filtrez par Logon Type : 2 (interactif), 3 (réseau), 10 (remote interactif/RDP). Cherchez les connexions inhabituelles (heure, poste source, compte).

4625 — Logon échoué. Le code Sub Status indique la raison : 0xC000006A (mauvais mot de passe), 0xC0000064 (compte inexistant), 0xC000006D (mauvais username ou mdp). Un volume élevé de 4625 sur un compte = tentative de brute-force.

4648 — Tentative de logon avec credentials explicites (runas). Souvent utilisé par les attaquants pour changer de contexte.

4672 — Logon de compte avec privilèges spéciaux (SeDebugPrivilege, SeImpersonatePrivilege...). Doit être surveillé de près : tout compte non-admin avec 4672 est suspect.

4768 / 4771 — Demande de TGT Kerberos réussie/échouée. Le code 0x12 dans 4771 indique un compte désactivé. Le code 0x25 une horloge désynchronisée.

4769 — Demande de Service Ticket Kerberos. Type de chiffrement RC4 (0x17) = suspicion Kerberoasting.

Gestion des comptes et groupes :

4720 — Création d'un nouveau compte utilisateur. Toute création hors processus standard est suspecte.

4728 — Membre ajouté à un groupe de sécurité global. Alerte si le groupe est Domain Admins, Enterprise Admins, Schema Admins.

4732 — Membre ajouté à un groupe de sécurité local. Idem pour les groupes Administrators locaux sur les serveurs sensibles.

4756 — Membre ajouté à un groupe de sécurité universel.

4740 — Compte utilisateur verrouillé. Un pic de 4740 sur plusieurs comptes simultanément = attaque brute-force ou spray.

Modifications d'objets Active Directory :

5136 — Modification d'un attribut d'objet AD. Crucial pour détecter les attaques DCSync (modification de permissions sur la partition domaine) et les AdminSDHolder abuse.

4662 — Opération sur un objet AD (accès LDAP). Nécessite une SACL configurée sur les objets cibles. Utile pour détecter les énumérations AD massives.

Pour les environnements SIEM, créez des règles de corrélation croisant ces Event IDs : par exemple, 4625 x 10 en moins de 5 minutes sur le même compte = alerte brute-force ; 4672 + compte non-admin = alerte escalade de privilèges ; 4728 sur Domain Admins = alerte critique.

Dimensionner la taille des journaux de sécurité

La configuration par défaut des journaux de sécurité Windows (20 Mo, politique d'écrasement automatique) est totalement inadaptée à un environnement d'entreprise. Un DC actif peut générer des centaines de milliers d'événements par jour.

# Voir la configuration actuelle du journal Security
wevtutil gl Security

# Configurer la taille maximale (1 GB) et la politique de rétention
wevtutil sl Security /ms:1073741824 /rt:false

# Via PowerShell
$log = [System.Diagnostics.EventLog]::new("Security")
$log.MaximumKilobytes = 1048576  # 1 GB

# Via GPO (recommandé)
# Computer Configuration → Windows Settings → Security Settings → Event Log
# → Maximum security log size : 1048576 KB (1 GB)
# → Retention method for security log : Overwrite events as needed

Dimensionnez selon le volume d'événements observé. Pour un DC de production avec 500 utilisateurs actifs et l'audit complet activé, comptez typiquement 500 Mo à 2 Go par jour selon l'activité. Si vous centralisez les logs vers un SIEM, une rétention locale de 2-7 jours est suffisante. Sans SIEM, visez 30 jours minimum pour permettre les investigations post-incident.

Configurez également des alertes sur le remplissage du journal de sécurité : Event ID 1104 (log plein) ou 1105 (log auto-effacé). Ces événements peuvent indiquer une tentative d'anti-forensique consistant à générer massivement des événements pour vider les logs.

Centraliser les logs vers un SIEM (Wazuh, Elastic, Splunk)

La centralisation des logs Active Directory vers un SIEM est indispensable pour une détection efficace. Les logs locaux sur chaque DC sont dispersés et difficiles à corréler manuellement.

Option 1 : Windows Event Forwarding (WEF) — solution native Microsoft, sans agent, configurable via GPO. Les DC envoient leurs événements vers un Windows Event Collector (WEC) centralisé :

# Sur le collecteur WEC
winrm quickconfig

# Sur les DC (via GPO)
# Computer Configuration → Administrative Templates → Windows Components → Event Forwarding
# Configure the forwarder server address: wec.ayinedjimi.fr
# Subscription queries pour les Event IDs critiques

Option 2 : Agent Wazuh — SIEM open source très complet pour les environnements on-premise :

# Installer l'agent Wazuh sur chaque DC
# Configurer dans /var/ossec/etc/ossec.conf (serveur Wazuh)
# Les règles Windows prédéfinies couvrent les Event IDs AD critiques
# Tableaux de bord disponibles dans Wazuh/Kibana pour l'authentification AD

Option 3 : Elastic Stack + Winlogbeat — solution flexible et scalable :

# Installer Winlogbeat sur les DC
# Configuration winlogbeat.yml pour collecter les logs Security
winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4648, 4672, 4720, 4728, 4732, 4740, 4768, 4769, 5136
  - name: System
  - name: Application

Quelle que soit la solution choisie, créez des dashboards dédiés à Active Directory : nombre de logons par heure, top des comptes en échec d'authentification, timeline des modifications de groupes privilégiés, géolocalisation des connexions (si le périmètre inclut des accès distants). Des règles de détection prébuilties pour les techniques MITRE ATT&CK associées à AD (T1110 Brute Force, T1003 Credential Dumping, T1207 DCShadow) sont disponibles dans les communautés Sigma et Elastic.

Tester et valider l'audit (générer des événements de test)

Une configuration d'audit ne vaut que si elle génère effectivement les événements attendus. Testez systématiquement après chaque modification de la politique.

# Test 4625 (logon failed) : tentative de connexion avec mauvais mdp
# Depuis une autre machine du domaine
$cred = New-Object PSCredential("ayinedjimi\testuser", (ConvertTo-SecureString "WrongPassword" -AsPlainText -Force))
$session = New-PSSession -ComputerName dc01.ayinedjimi.fr -Credential $cred -ErrorAction SilentlyContinue

# Vérifier dans les logs du DC
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4625] and EventData[Data[@Name='TargetUserName']='testuser']]" -MaxEvents 5

# Test 4728 (ajout dans groupe privilégié)
Add-ADGroupMember -Identity "Domain Admins" -Members testuser
# Vérifier l'event 4728 dans les logs
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4728]]" -MaxEvents 5

# Retirer le compte test
Remove-ADGroupMember -Identity "Domain Admins" -Members testuser -Confirm:$false

Pour tester les Event IDs liés aux objets AD (5136, 4662), modifiez un attribut d'un objet AD et vérifiez la génération de l'événement :

# Modifier un attribut sur un compte test
Set-ADUser -Identity testuser -Description "Test audit 5136"

# Vérifier l'événement 5136
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=5136]]" -MaxEvents 5 |
  Select-Object TimeCreated, @{n='Message';e={$_.Message -replace '\s+',' '}} |
  Format-List

Documentez les résultats de ces tests dans un rapport de validation que vous conservez et mettez à jour à chaque révision de la politique d'audit. Ce document constitue une preuve de conformité précieuse lors d'audits ISO 27001 ou NIS 2. Pour un audit approfondi de votre posture de sécurité Active Directory, consultez notre service de pentest Active Directory, qui inclut une évaluation complète de la configuration d'audit et de la détection. Retrouvez aussi notre article sur les stratégies d'audit et événements de sécurité AD pour approfondir ce sujet.

La documentation Microsoft sur les stratégies d'audit et le CIS Benchmark Windows Server fournissent des recommandations détaillées et des valeurs de référence pour chaque paramètre d'audit.

FAQ — Audit avancé Active Directory

Pourquoi l'audit avancé n'est-il pas activé par défaut sur les contrôleurs de domaine ?

Windows Server inclut une politique d'audit de base activée par défaut, mais l'audit avancé doit être configuré manuellement. Microsoft a fait ce choix pour éviter de surcharger les systèmes de logs dès l'installation, car l'audit complet peut multiplier par 10 ou 20 le volume d'événements générés. Sans infrastructure de collecte de logs dimensionnée (SIEM, stockage dédié), cette quantité d'événements serait ingérable. C'est pourquoi l'audit avancé fait partie d'une approche de sécurité planifiée, accompagnée d'une infrastructure de collecte et d'analyse appropriée, plutôt que d'un paramètre par défaut.

L'activation de l'audit avancé impacte-t-elle les performances des contrôleurs de domaine ?

L'impact est mesurable mais généralement acceptable. Des études Microsoft et des tests de terrain indiquent une consommation CPU supplémentaire de 1 à 5% sur les DC, avec des pics lors d'opérations intensives (authentification massive en début de journée). L'impact le plus significatif concerne les I/O disque liées à l'écriture des logs. Sur des DC dont les disques sont sollicités, préférez des disques SSD pour les logs d'événements. L'audit des accès aux objets AD (DS Access) avec SACL sur de nombreux objets peut être plus coûteux — activez-le uniquement sur les objets vraiment sensibles (OU des comptes administrateurs, groupes privilégiés, objets GPO).

Comment détecter une attaque DCSync avec les Event IDs ?

DCSync est une technique permettant à un attaquant de simuler les droits d'un DC pour extraire des hashes de mots de passe via la réplication AD. La détection repose principalement sur l'Event ID 4662 (opération sur un objet AD), filtré sur les accès aux droits "Replicating Directory Changes" (GUID 1131f6aa...) et "Replicating Directory Changes All" (1131f6ad...) sur la partition domaine. Un compte non-DC qui génère ces événements est suspect. Le framework Sigma dispose de règles de détection précises pour DCSync. L'Event ID 5136 peut également révéler des modifications de permissions permettant à un compte de réaliser DCSync (ajout de droits de réplication sur un compte non-privilégié).

Combien de temps conserver les logs de sécurité Active Directory selon NIS 2 ?

La directive NIS 2 (et son implémentation française via la LPM 2024) ne fixe pas de durée précise de rétention des logs, mais les recommandations de l'ANSSI et des autorités de supervision sectorielles convergent vers une rétention minimale de 12 mois pour les logs de sécurité, dont au moins 3 mois en accès rapide (hot storage) et le reste en archivage (cold storage). ISO 27001 recommande également une durée alignée avec les délais légaux d'investigation. Pour les secteurs critiques (énergie, finance, santé), certains régulateurs imposent des durées de 3 à 5 ans. Vérifiez les exigences spécifiques à votre secteur avec votre DPO et vos équipes juridiques.

Peut-on auditer les modifications d'attributs sensibles comme adminCount, msDS-AllowedToDelegateTo ou SIDHistory ?

Oui, ces attributs particulièrement sensibles sont couverts par l'Event ID 5136 (Directory Service Object Modification), à condition que la politique d'audit "Audit Directory Service Changes" soit activée en Success. L'événement 5136 inclut le nom de l'attribut modifié (attribute name), les anciennes et nouvelles valeurs, le compte ayant effectué la modification, et le DC où la modification a eu lieu. Des règles SIEM ciblant 5136 + attribut = "adminCount" OR "SIDHistory" OR "msDS-AllowedToDelegateTo" permettent une détection fine des modifications d'attributs à haut risque, souvent utilisés dans les attaques de persistance AD.