Points clés
- Identifiez les sept event IDs Windows qui comptent pour l'audit des logons AD et pourquoi les vrais logoffs sont sur les postes.
- Construisez un script PowerShell parallélisé qui récupère l'historique de logon de chaque domain controller en quelques secondes.
- Planifiez la rétention des journaux avec une formule de dimensionnement, des paramètres GPO et Windows Event Forwarding vers un SIEM.
- Comparez l'audit natif, les auditeurs tiers et la prévention FIDO2 comme trois réponses à une seule question.
Suivre les logon et logoff d'utilisateurs dans Active Directory implique de combiner des paramètres d'audit Group Policy, les bons event IDs Windows (4624, 4625, 4634, 4647, 4768, 4769, 4776), du PowerShell à grande échelle, le forwarding des logs vers un SIEM et une stratégie de rétention alignée sur SOX, HIPAA, PCI DSS 4.0, NIS2 et DORA. Les domain controllers émettent des tickets Kerberos mais n'observent jamais la fin de session : le forwarding d'événements depuis les postes est non négociable dans tout parc hybride moderne.
Trois jours. C'est la profondeur typique des journaux de sécurité d'un domain controller avant écrasement, laissant les administrateurs aveugles dès qu'un account lockout, un incident interne ou une enquête sur des identifiants compromis arrive sur leur bureau. L'audit natif d'Active Directory a été conçu pour des postes statiques et des domaines on-prem, pas pour des fermes RDS, des tunnels VPN, l'identité hybride et des sessions SaaS exécutées en parallèle. Ce guide parcourt chaque couche : de l'event 4624 sur le domain controller à l'authentification FIDO2 phishing-résistante qui élimine, à la source, l'essentiel du bruit lié aux mots de passe dans votre pipeline d'audit.
Audit natif des logons AD : configuration GPO, event IDs et limites réelles
Activer l'audit Logon/Logoff via Advanced Audit Policy Configuration
Les paramètres par défaut d'audit logon sur un domaine fraîchement installé sont trop permissifs pour la forensique et trop silencieux pour la conformité. Ouvrez la Default Domain Controllers Policy et accédez à Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff. Activez Success et Failure sur Logon, Logoff, Account Lockout et Special Logon. Combinez avec Account Logon > Audit Kerberos Authentication Service et Audit Credential Validation pour capturer les tentatives de fallback NTLM.
Référence Event ID (4624, 4625, 4634, 4647, 4768, 4769, 4776) et pourquoi les domain controllers n'enregistrent pas de vrais événements de logoff
| Event ID | Signification | Où c'est journalisé |
|---|---|---|
| 4624 | Logon réussi | DC + poste |
| 4625 | Logon échoué | DC + poste |
| 4634 / 4647 | Logoff / logoff initié par l'utilisateur | Poste uniquement |
| 4768 / 4769 | TGT Kerberos / ticket de service | Domain controller |
| 4776 | Validation de credentials NTLM | Domain controller |
Les domain controllers émettent des tickets Kerberos mais ne voient jamais la fin de la session : les vrais logoffs vivent sur les endpoints, pas sur le DC. La référence event 4624 sur Microsoft Learn documente le schéma complet et les Logon Type codes qui changent l'interprétation en aval.
Scripts PowerShell pour récupérer l'historique de logon sur tous les domain controllers
Script moderne Get-WinEvent + FilterHashtable avec traitement parallèle
Get-EventLog est déprécié depuis PowerShell 5 et s'effondre sur les forêts importantes. Utilisez Get-WinEvent avec un FilterHashtable et interrogez chaque domain controller en parallèle :
powershell
$DCs = (Get-ADDomainController -Filter *).HostName
$DCs | ForEach-Object -Parallel {
Get-WinEvent -ComputerName $_ -FilterHashtable @{
LogName='Security'; ID=4624,4625; StartTime=(Get-Date).AddDays(-7)
} | Select TimeCreated, MachineName, @{n='User';e={$_.Properties[5].Value}}
} -ThrottleLimit 10 | Export-Csv .\logons.csv -NoTypeInformation
Ajoutez un try/catch autour de chaque appel distant pour gérer les DC injoignables sans interrompre l'exécution.
Corréler les paires 4624/4634 et suivre les sessions RDS/VPN
La véritable durée de session exige d'apparier chaque 4624 avec son 4634/4647 correspondant via LogonID (Properties[7]). Pour RDS, interrogez Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (IDs 21, 23, 25) sur les session hosts. Pour VPN, parsez RRAS ou les logs de votre concentrateur et joignez sur le nom d'utilisateur et le timestamp.
Centraliser et conserver les logs de logon sans perte de données
Les plafonds par défaut du log Sécurité (souvent 128 Mo) expliquent pourquoi les administrateurs sur Spiceworks rapportent régulièrement que « les logs ne remontent qu'à trois jours ». La rétention se conçoit, elle ne se présume pas.
Formule de dimensionnement et paramètres GPO pour empêcher l'écrasement
Utilisez cette formule : événements/utilisateur/jour × utilisateurs × jours de rétention × 1,5 Ko = taille de log requise. Pour 500 utilisateurs générant ~80 événements/jour sur 90 jours, prévoyez ~5,4 Go par DC. Configurez via Computer Configuration > Policies > Windows Settings > Security Settings > Event Log : fixez la taille maximale, choisissez Archiver le log lorsqu'il est plein plutôt qu'écraser, et surveillez la pression disque sur les domain controllers.
Windows Event Forwarding (WEF) + SIEM/Splunk pour les environnements hybrides AD + Entra ID
Déployez un collecteur WEF, distribuez une GPO définissant l'URL du subscription manager et filtrez les event IDs 4624/4625/4634/4647/4776 via XPath. Forwardez vers Splunk via un heavy forwarder, puis ingérez les logs de sign-in Entra ID via la Graph API pour corréler les identités hybrides dans une seule vue.
De la détection à la prévention : comment FIDO2 et le passwordless réduisent votre surface d'audit
La détection croît linéairement avec le bruit des mots de passe. Le Verizon 2025 DBIR situe l'abus de credentials dans 22 % de toutes les violations, et les credentials volés ajoutés au phishing dépassent la moitié des incidents impliquant l'élément humain. Retirez le mot de passe et ce vecteur s'effondre à la source : brute force, password spraying et tentatives de downgrade NTLM disparaissent. Votre SOC cesse de trier les tempêtes de 4625 et commence à chasser de vraies anomalies.
Volume SIEM avant/après et recettes de patterns MITRE ATT&CK (T1078, T1110, T1558)
Sur un parc de 1 000 utilisateurs, attendez-vous à voir les événements 4625/4776 chuter d'un ordre de grandeur après un déploiement Hideez FIDO2. Les credentials liés au matériel neutralisent T1110 (brute force), T1558 (Kerberoasting) et la plupart des variantes T1078 (valid accounts), parce que la clé privée ne quitte jamais la security key.
Mappage de conformité : SOX, HIPAA, PCI DSS 4.0, NIS2 et DORA
PCI DSS 4.0 §8.4 et NIS2 Article 21 exigent explicitement une authentification phishing-résistante. FIDO2 satisfait les deux tout en produisant des enregistrements de logon inviolables que les auditeurs acceptent.
DORA Article 9 étend la même exigence aux entités financières de l'UE, et NIST SP 800-63B définit le niveau d'assurance AAL3 auquel les cinq cadres font finalement référence.
Cadre de décision : audit natif vs. auditeur tiers vs. solution de couche d'authentification
Choisir entre l'audit natif AD, un auditeur dédié et un contrôle au niveau de la couche d'authentification n'est pas une décision binaire. Chaque couche répond à une question distincte : ce qui s'est passé, ce qui se passe maintenant et ce qui ne devrait jamais arriver.
Matrice de notation : coût, couverture hybride, alerting temps réel et prévention vs. détection
| Critère | AD natif | Auditeur tiers | Hideez (couche d'authentification) |
|---|---|---|---|
| Coût | Gratuit | 3-8 $/utilisateur/an | Par clé + licence |
| Couverture hybride Entra ID | Partielle | Variable | Complète |
| Alerting temps réel | Non | Oui | N/A (prévient) |
| Approche | Détection | Détection | Prévention |
Quand ADAudit Plus, UserLock ou Netwrix suffisent — et pourquoi Hideez les complète
Si votre priorité est la preuve forensique et le reporting SOC 2, un auditeur tiers couvre bien la couche détection. Hideez ne les remplace pas ; il retire les événements liés aux credentials sur lesquels ils dépensent leurs cycles de triage, dans une architecture en couches, laissant les règles de l'auditeur se concentrer sur de vraies anomalies plutôt que sur le bruit des mots de passe.
Hideez remplace la surface d'attaque liée aux credentials par des logins FIDO2 phishing-résistants que les auditeurs acceptent et que les SOCs adorent. Réservez une démo pour voir comment cela s'intègre à votre parc AD ou Entra ID hybride, ou devenez partenaire Hideez pour offrir le même bénéfice à vos clients.
Questions fréquentes
Pourquoi Active Directory n'enregistre-t-il pas de vrais événements de logoff sur le domain controller ?
Le modèle de tickets Kerberos authentifie l'utilisateur une seule fois ; ensuite, la session vit sur le poste. Le DC émet un TGT mais ignore quand l'utilisateur ferme sa session d'accès. Les événements de logoff (4634, 4647) sont écrits localement sur l'endpoint, pas de manière centrale. Pour les capturer, forwardez les logs des postes via Windows Event Forwarding vers un collecteur ou un SIEM.
Comment obtenir l'historique de logon des utilisateurs AD avec PowerShell sur tous les domain controllers ?
Utilisez Get-WinEvent -FilterHashtable contre chaque DC retourné par Get-ADDomainController -Filter *, avec ForEach-Object -Parallel pour la mise à l'échelle. Filtrez sur l'event ID 4624 de logon, exportez en CSV, puis corrélez avec 4634 pour calculer la véritable durée de session.
Audit de logon vs. authentification sans mot de passe : laquelle réduit réellement le risque lié aux credentials ?
L'audit détecte après les faits. L'authentification FIDO2 matérielle élimine la surface d'attaque, neutralisant la brute force, le phishing et le password spraying à la racine.
