Audit Active Directory : la stratégie d'audit avancée et les événements à surveiller
Après un incident, la première question est toujours la même : que s'est-il passé, et depuis quand ? Sans journalisation adaptée sur les contrôleurs de domaine, la réponse est souvent « on ne sait pas ». La configuration d'audit par défaut ne suffit pas.
Stratégie d'audit avancée plutôt que stratégie de base
Windows propose deux jeux de paramètres : les neuf catégories de la stratégie d'audit de base et la cinquantaine de sous-catégories de la stratégie avancée. Les mélanger produit des résultats imprévisibles. Il faut configurer uniquement la stratégie avancée, dans une GPO liée à l'OU Domain Controllers, et activer le paramètre « Forcer les paramètres de sous-catégorie de la stratégie d'audit » pour qu'elle prenne le pas sur la stratégie de base.
Le résultat se vérifie sur un contrôleur avec auditpol /get /category:*.
Les sous-catégories essentielles
- Account Logon : Kerberos Authentication Service, Kerberos Service Ticket Operations, Credential Validation.
- Account Management : User, Computer et Security Group Management.
- DS Access : Directory Service Access et Directory Service Changes, ces deux dernières nécessitant aussi des SACL sur les objets.
- Logon/Logoff : Logon, Special Logon, Account Lockout.
- Policy Change et Privilege Use selon le besoin.
Les événements clés
| ID | Signification |
|---|---|
| 4624 / 4625 | Ouverture de session réussie / échouée |
| 4672 | Privilèges spéciaux attribués à une session (compte administrateur) |
| 4720 | Compte utilisateur créé |
| 4728 / 4732 / 4756 | Membre ajouté à un groupe global / local / universel |
| 4738 | Compte utilisateur modifié |
| 4769 | Ticket de service Kerberos demandé |
| 4662 | Opération effectuée sur un objet de l'annuaire |
| 5136 | Objet de l'annuaire modifié (avec ancienne et nouvelle valeur) |
Taille des journaux et centralisation
Sur un contrôleur actif, le journal Sécurité peut tourner en quelques heures si sa taille n'a pas été augmentée. Il faut le dimensionner en fonction du volume réel et, surtout, ne pas compter sur la rétention locale : un attaquant qui obtient les droits d'administration peut effacer le journal (événement 1102).
La centralisation se fait via Windows Event Forwarding ou l'agent du SIEM. Elle garantit la conservation, permet la corrélation entre contrôleurs et fixe la rétention selon vos obligations de conformité.
Conseil. Mieux vaut dix règles d'alerte bien réglées et suivies qu'un SIEM qui reçoit tout et ne déclenche rien. Commencez par les changements rares et à fort impact.
Sur quoi alerter
- Ajout d'un membre à un groupe privilégié (4728, 4732, 4756 sur Domain Admins, Enterprise Admins, Administrators, opérateurs, DnsAdmins).
- Événement 4662 portant les GUID de réplication, émis par un compte qui n'est pas un contrôleur.
- Modification (5136) des GPO liées aux contrôleurs, de l'objet AdminSDHolder ou de l'ACL de la racine du domaine.
- Demandes 4769 en chiffrement RC4 en volume inhabituel, signe possible de Kerberoasting.
- Effacement du journal (1102) et pics d'échecs d'authentification (4625, 4771).
Ce qu'un audit vérifie
- La configuration effective de la stratégie d'audit avancée sur chaque contrôleur.
- Les SACL sur la racine du domaine et les objets sensibles.
- La taille des journaux et leur transfert vers une plateforme centrale.
- L'existence de règles d'alerte sur les événements critiques.