Compte Active Directory bloqué : audit, diagnostic et déverrouillage pas à pas

Un compte utilisateur AD qui reste verrouillé peut paralyser la productivité ; cet article détaille une méthode complète pour tracer la source du verrouillage, corriger la cause et éviter la récidive, tout en maintenant un haut niveau de sécurité dans votre forêt.

Sommaire

Vue d’ensemble de la problématique

Lorsqu’un utilisateur Active Directory est bloqué, la réaction naturelle consiste à déverrouiller le compte ou à réinitialiser le mot de passe depuis la console « Utilisateurs et ordinateurs Active Directory ». Pourtant, lorsque la cause profonde n’est pas résolue (sessions persistantes, services ou tâches utilisant un ancien mot de passe), le compte se reverrouille immédiatement, générant un cercle vicieux qui :

désorganise l’utilisateur et le service support,
augmente la charge sur les contrôleurs de domaine,
risque de masquer de véritables tentatives d’intrusion.

La seule approche fiable est donc de mettre en place un audit détaillé, d’identifier le contrôleur de domaine verrouilleur puis la machine émettrice, avant de corriger la configuration côté client.

Activer un audit détaillé sur tous les contrôleurs de domaine

Sans journaux complets, toute investigation est vouée à l’échec. Deux niveaux d’audit coexistent ; si vous activez le paramétrage avancé, il écrase la configuration traditionnelle.

Audit traditionnel (catégorie “Paramètres de sécurité › Stratégies locales › Stratégies d’audit”)

Audit Account Logon Events : Échecs
Audit Account Management : Succès et échecs
Audit Logon Events : Échecs

Audit avancé (recommandé)

Chemin : Configuration ordinateur › Stratégies › Paramètres Windows › Paramètres de sécurité › Stratégie d’audit avancée

Logon/Logoff
- Audit Account Lockout : Échec
- Audit Logon : Échec
- Audit Kerberos Authentication Service : Échec
- Audit Credential Validation : Échec
Account Management
- Audit User Account Management : Succès et échec

Après modification, exécutez :

gpupdate /force
auditpol /get /category:*   &lt;!-- Vérifier l'état réel côté DC --&gt;

Identifier le contrôleur de domaine ayant réellement verrouillé le compte

Téléchargez (ou récupérez depuis un share interne) les Account Lockout and Management Tools de Microsoft.
Lancez LockoutStatus.exe, saisissez ou sélectionnez le compte concerné.
Repérez le DC dont la colonne Bad PWD Count > 0 : c’est le premier récepteur de la tentative erronée, donc la clef de l’investigation.

Note : Sur les grandes forêts, un script PowerShell (Invoke-LockoutStatusReport.ps1) peut paralléliser la requête WMI sur chaque DC pour les mêmes informations.

Analyser les journaux de sécurité du DC concerné

Ouvrez l’Observateur d’évènements : Journaux Windows › Sécurité. Les ID suivants sont essentiels :

Event ID	Description	Informations clés
4740	Account locked out	Nom du compte, DC verrouilleur, adresse d’origine
4771	Kerberos pre-authentication failed	Code d’erreur `0x18` (mauvais mot de passe) ou `0x12` (ticket expiré)
4776	NTLM authentication failed	Code `C000006A` (mauvais mot de passe) ou `C0000234` (compte verrouillé)

La corrélation manuelle peut être fastidieuse ; créez une Vue personnalisée filtrant sur ces trois ID et un intervalle de temps de ± 5 minutes autour du premier 4740. Dans chaque 4771/4776, notez :

Client Address (IP de la station),
Workstation Name (nom NetBIOS),
éventuellement le Process Information › Process Name.

Rechercher la cause côté client

Une fois la machine incriminée identifiée, plusieurs scénarios sont fréquents :

Informations d’identification obsolètes
Gestionnaire d’identifiants Windows › Identifiants Windows : supprimez toute entrée liée au compte.
Tâches planifiées et services
Utilisez Get-ScheduledTask -TaskName "*" | Get-ScheduledTaskInfo puis la console services.msc pour détecter un compte de service configuré manuellement.
Lecteurs réseau mappés via GPO ou scripts
Vérifiez les scripts de connexion (NET USE en invite de commandes).
Logiciels tiers
Agents de sauvegarde, clients VPN, ERP : ils conservent parfois un mot de passe en base SQLite ou dans le registre.
Sessions RDP persistantes
L’utilisateur a pu laisser une session ouverte sur un serveur avec un vieux mot de passe ; fermez les sessions via quser /server:ServerName puis logoff.

Si l’IP source pointe vers un Controlleur de domaine lui‑même, suspectez des Replication Drives (DFS), des scripts de supervision ou un HealthCheck désuet.

Audit local pour identifier le processus fautif

Sur la machine cliente problématique :

Auditpol /set /subcategory:&quot;Logon&quot; /failure:enable

Puis observez l’event ID 4625 (Logon Failure) dans le journal Sécurité local. Le champ Process Name (ou Caller Process Name) révèle l’exécutable envoyant les identifiants erronés.

Déverrouillage et réinitialisation du mot de passe

Une fois la cause supprimée, vous pouvez :

Déverrouiller le compte : Unlock-ADAccount -Identity "SamAccountName"
Exiger un changement de mot de passe à la prochaine connexion : Set-ADUser "SamAccountName" -ChangePasswordAtLogon $true
Forcer la synchronisation des DC (petites structures) : Repadmin /syncall /AdeP

Dans de rares cas, un ordinateur joint au domaine mais hors réseau depuis longtemps conserve un secret d’ordinateur expiré ; exécutez côté client :

Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential)

Résolution constatée dans ce cas concret

Dans l’incident qui a déclenché cet article, le compte utilisateur John.Doe était toujours mémorisé sur un ancien portable de test. À chaque démarrage, un service propriétaire lançait une tâche planifiée avec le mot de passe périmé, provoquant :

4771 Kerberos pre-authentication failure (0x18) sur DC3
Propagation de l’état au reste des DC (AD Site Replication)
4740 Account locked out pour l’utilisateur

Après suppression des identifiants dans le gestionnaire et désactivation du service sur la machine, aucun nouvel événement 4740 n’est apparu durant dix jours d’observation – signe d’une résolution définitive.

Bonnes pratiques de prévention

Action	Objectif
Outils Microsoft « Account Lockout and Management Tools »	Automatiser la collecte d’informations (LockoutStatus, ALockout.dll, etc.)
Stratégie de verrouillage adaptée	Fixer un seuil (p. ex. 10 tentatives) et un délai de réinitialisation (15 min) appropriés au contexte de risque
Gestion centralisée des mots de passe de service	Utiliser Group Managed Service Account (gMSA) ou Azure Key Vault
Rotation de secrets synchronisée	Après chaque réinitialisation de mot de passe, informer les équipes et vérifier toutes les dépendances applicatives
Surveillance proactive	Configurer des alertes en temps réel (Event ID 4740) corrélées avec l’IP source ; SIEM, Azure Sentinel, ou script PowerShell de veille

Cheat‑sheet des codes d’erreur courants

Code	Signification	Action recommandée
0x18	Mauvais mot de passe (Kerberos)	Vérifier les identifiants stockés
C000006A	Mauvais mot de passe (NTLM)	Même logique que ci‑dessus
C0000234	Compte verrouillé	Attendre la fenêtre ou déverrouiller manuellement
0x12	Ticket expired	Heures déréglées ; vérifier NTP / synchronisation

Script PowerShell d’automatisation (exemple)

Le script suivant génère un rapport CSV et envoie un mail HTML si un verrouillage est détecté :

$User = &quot;John.Doe&quot;
$Report = @()
Import-Module ActiveDirectory
(Get-ADDomainController -Filter *).Name | ForEach-Object {
    $Events = Get-WinEvent -ComputerName $_ -FilterHashtable @{
        LogName='Security'; ID=4740; StartTime=(Get-Date).AddHours(-1)
    } | Where-Object { $_.Properties[0].Value -like &quot;$User*&quot; }
    if ($Events) {
        $Events | ForEach-Object {
            $Report += [PSCustomObject]@{
                DC=$_
                Time=$_.TimeCreated
                Ip=$_.Properties[1].Value
            }
        }
    }
}
if ($Report) {
    $Report | Export-Csv &quot;C:\Temp\Lockout_$($User).csv&quot; -NoType
    Send-MailMessage -From 'siem@domain.local' -To 'soc@domain.local' -Subject &quot;Lockout $User&quot; `
        -Body ($Report | ConvertTo-Html -Fragment) -SmtpServer 'smtp.domain.local' -BodyAsHtml
}

Adapté : changez l’utilisateur, le chemin et le serveur SMTP.

FAQ rapide

Pourquoi ne pas simplement augmenter le seuil de verrouillage ?
Parce que vous masqueriez un problème sous-jacent et fragiliseriez la sécurité.
Un redémarrage des DC aide‑t‑il ?
Non ; tant que la source du mauvais mot de passe existe, la réplication AD propage instantanément le compteur.
Quel outil graphique conseillez‑vous ?
« AD Administrative Center » (Windows Server 2012+) intègre un filtre de verrouillages, mais LockoutStatus reste plus précis.

Conclusion

Traiter un compte utilisateur verrouillé dans Active Directory revient toujours à suivre la chaîne DC > Event ID > Client Source. Sans audit avancé, vous naviguez à vue ; avec les bonnes catégories et une méthodologie claire, la résolution devient rapide, documentée et reproductible. Pensez prévention : gMSA pour les services, rotation de secrets et alerting proactif éviteront la plupart des verrouillages à l’avenir.

Compte Active Directory bloqué : audit, diagnostic et déverrouillage pas à pas