Active Directory 12 min de lecture

Verrouillage de compte Active Directory : le guide de dépannage PowerShell

Un compte AD se verrouille en boucle ? Ce guide vous montre comment traquer la source avec PowerShell (Event 4740), déverrouiller le compte et prévenir les récidives avec les Fine-Grained Password Policies.

Editorial Team

Pourquoi les comptes Active Directory se verrouillent (et pourquoi ça tombe toujours au pire moment)

Si vous bossez au helpdesk, vous connaissez forcément la scène : un utilisateur appelle, paniqué, parce qu'il ne peut plus se connecter. Son compte est verrouillé. Vous le déverrouillez, et dix minutes plus tard… rebelote. Le ticket reste ouvert, l'utilisateur s'impatiente, et vous voilà à chercher une aiguille dans une botte de foin.

Honnêtement, c'est l'un des problèmes les plus frustrants du support IT.

Le verrouillage de compte dans Active Directory est un mécanisme de sécurité essentiel — il protège contre les attaques par force brute en bloquant temporairement un compte après un certain nombre de tentatives échouées. Mais voilà le truc : la grande majorité des verrouillages n'ont absolument rien à voir avec une attaque. Ce sont des identifiants périmés qui traînent quelque part dans l'environnement, bien planqués, et qui continuent d'envoyer l'ancien mot de passe au contrôleur de domaine.

Ce guide vous donne une méthodologie structurée, avec des commandes PowerShell prêtes à l'emploi, pour identifier la source du verrouillage, déverrouiller le compte et empêcher que ça se reproduise. Après avoir passé pas mal de temps à traquer ce genre de problèmes, je peux vous dire que la clé, c'est d'avoir une approche systématique.

Les causes les plus fréquentes de verrouillage intempestif

Avant de foncer tête baissée dans le dépannage, prenons une minute pour comprendre pourquoi un compte se verrouille en boucle. Dans 90 % des cas, c'est l'une de ces causes :

  • Sessions déconnectées sur un autre poste — L'utilisateur a changé son mot de passe, mais une session reste ouverte sur un PC distant avec l'ancien. Chaque tentative de reconnexion automatique génère un échec. C'est de loin la cause la plus courante.
  • Lecteurs réseau mappés avec d'anciens identifiants — Un lecteur réseau configuré avec des credentials sauvegardés qui n'ont pas été mis à jour après le changement de mot de passe.
  • Applications mobiles (Outlook, Teams sur smartphone) — L'appli mobile continue de tenter l'authentification avec l'ancien mot de passe, parfois toutes les quelques minutes. Un classique.
  • Tâches planifiées exécutées sous un compte de service — Le mot de passe du compte a été changé, mais la tâche planifiée utilise toujours l'ancien. Ça peut passer inaperçu pendant des semaines.
  • Identifiants enregistrés dans le Gestionnaire d'informations d'identification Windows — Des credentials obsolètes stockés localement, envoyés automatiquement au contrôleur de domaine sans que personne ne s'en rende compte.
  • Scripts ou services configurés avec des mots de passe en dur — Des comptes de service dont le mot de passe a été modifié dans AD mais pas dans la config du service.
  • Attaques par force brute ou password spraying — La cause la plus préoccupante, mais statistiquement la moins fréquente pour les verrouillages répétitifs d'un même compte. Si c'est ça, vous avez un tout autre problème à gérer.

Prérequis : préparer votre environnement PowerShell

Pour suivre ce guide, vous aurez besoin du module ActiveDirectory pour PowerShell. Il est installé par défaut sur les contrôleurs de domaine et disponible via les outils RSAT sur les postes d'administration.

Vérifier que le module est disponible

Get-Module -ListAvailable -Name ActiveDirectory

Si le module n'est pas installé sur votre poste Windows 10/11, installez les RSAT :

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Puis importez le module :

Import-Module ActiveDirectory

Vérifier vos permissions

Pour déverrouiller des comptes, vous devez être membre du groupe Opérateurs de compte, Admins du domaine, ou disposer de droits délégués sur l'OU concernée. Et pour lire les journaux de sécurité sur le contrôleur de domaine, il vous faut les droits d'administrateur local sur ce serveur (oui, c'est un prérequis qu'on oublie souvent).

Étape 1 : détecter les comptes verrouillés

Bon, passons aux choses sérieuses. La première chose à faire, c'est confirmer le verrouillage et récupérer les détails du compte.

Lister tous les comptes verrouillés du domaine

Search-ADAccount -LockedOut -UsersOnly |
    Select-Object Name, SamAccountName, LockedOut, LastLogonDate |
    Format-Table -AutoSize

Cette commande interroge l'ensemble du domaine et retourne tous les comptes utilisateur actuellement verrouillés, avec leur nom, identifiant et dernière connexion réussie. Pratique pour avoir une vue d'ensemble rapide.

Vérifier un compte spécifique

Get-ADUser -Identity "jean.dupont" -Properties LockedOut, AccountLockoutTime, BadLogonCount, BadPasswordTime, LastLogonDate |
    Select-Object Name, SamAccountName, LockedOut, AccountLockoutTime, BadLogonCount,
        @{N="DernierEchecMdp"; E={[datetime]::FromFileTime($_.BadPasswordTime)}}, LastLogonDate

Cette commande retourne des infos cruciales : le nombre de tentatives échouées (BadLogonCount), l'heure du dernier échec de mot de passe et l'heure exacte du verrouillage. Ce sont ces détails qui vont vous guider pour la suite.

Étape 2 : identifier le contrôleur de domaine source

Dans un environnement multi-DC (et soyons honnêtes, c'est le cas de la plupart des entreprises), le verrouillage est enregistré sur le DC qui a traité la tentative d'authentification, puis répliqué vers le PDC Emulator. C'est donc sur le PDC que vous trouverez les informations les plus complètes.

Trouver le PDC Emulator

$PDC = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator : $PDC"

Vérifier le statut du compte sur chaque DC

Pour voir si le verrouillage a été répliqué sur tous les contrôleurs de domaine :

$Utilisateur = "jean.dupont"
Get-ADDomainController -Filter * | ForEach-Object {
    $DC = $_.HostName
    $Etat = Get-ADUser -Identity $Utilisateur -Server $DC -Properties LockedOut, AccountLockoutTime, BadLogonCount
    [PSCustomObject]@{
        DC              = $DC
        Verrouille      = $Etat.LockedOut
        HeureVerrouillage = $Etat.AccountLockoutTime
        TentativesEchouees = $Etat.BadLogonCount
    }
} | Format-Table -AutoSize

Ce script interroge chaque contrôleur de domaine individuellement. Petit conseil : si le BadLogonCount est plus élevé sur un DC spécifique, c'est probablement celui qui se trouve sur le même site AD que la machine source du problème. C'est un indice précieux.

Étape 3 : trouver la source exacte du verrouillage

C'est l'étape clé de tout le processus. On va analyser les journaux d'événements de sécurité sur le PDC Emulator pour trouver l'événement ID 4740 — celui qui enregistre chaque verrouillage de compte.

Rechercher les événements 4740 sur le PDC

$PDC = (Get-ADDomain).PDCEmulator
$Utilisateur = "jean.dupont"

Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = "Security"
    ID        = 4740
    StartTime = (Get-Date).AddDays(-1)
} | Where-Object { $_.Message -match $Utilisateur } |
    ForEach-Object {
        [PSCustomObject]@{
            Date           = $_.TimeCreated
            Utilisateur    = ($_.Properties[0]).Value
            OrdinateurSource = ($_.Properties[1]).Value
        }
    } | Format-Table -AutoSize

Le champ OrdinateurSource (Caller Computer Name), c'est la pièce manquante du puzzle. Il vous dit exactement depuis quelle machine les tentatives d'authentification échouées ont été émises. Une fois que vous avez ce nom, vous savez où aller chercher.

Cas particulier : le champ OrdinateurSource est vide

Si le champ Caller Computer Name est vide dans l'événement 4740, là, ça devient sérieux. Ça signifie que la source n'est pas une machine jointe au domaine — il peut s'agir d'une attaque par force brute externe, souvent via OWA, VPN ou ADFS.

Dans ce cas, recherchez les événements 4625 (échec de connexion) et 4771 (échec d'authentification Kerberos) pour obtenir l'adresse IP source :

Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = "Security"
    ID        = 4625
    StartTime = (Get-Date).AddHours(-2)
} | Where-Object { $_.Message -match $Utilisateur } |
    Select-Object TimeCreated, @{N="AdresseIP"; E={($_.Properties[19]).Value}} |
    Format-Table -AutoSize

Étape 4 : investiguer la machine source

OK, vous avez trouvé la machine coupable. Maintenant, connectez-vous dessus (à distance ou physiquement) et vérifiez les points suivants. Allez-y méthodiquement, dans l'ordre — c'est souvent le premier ou le deuxième point qui résout le mystère.

Vérifier le Gestionnaire d'informations d'identification

# Ouvrir le Gestionnaire d'informations d'identification
rundll32.exe keymgr.dll, KRShowKeyMgr

Ou via PowerShell, lister les identifiants enregistrés :

cmdkey /list

Supprimez tout identifiant obsolète lié au domaine. C'est le coupable numéro un dans mon expérience.

Vérifier les tâches planifiées

Get-ScheduledTask | Where-Object {
    $_.Principal.UserId -match "jean.dupont"
} | Select-Object TaskName, TaskPath, @{N="Utilisateur"; E={$_.Principal.UserId}} |
    Format-Table -AutoSize

Vérifier les services Windows

Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -match "jean.dupont"
} | Select-Object Name, DisplayName, StartName, State |
    Format-Table -AutoSize

Vérifier les sessions déconnectées

query user /server:NOM-DU-SERVEUR

Si vous trouvez des sessions déconnectées (Disc) de l'utilisateur concerné, forcez la déconnexion :

logoff ID_SESSION /server:NOM-DU-SERVEUR

Étape 5 : déverrouiller le compte

Une fois la source identifiée et corrigée (c'est important — ne déverrouillez pas avant d'avoir trouvé la cause, sinon vous allez rejouer le même scénario dans dix minutes), voici comment procéder :

Déverrouiller un compte spécifique

Unlock-ADAccount -Identity "jean.dupont"

Simple, efficace.

Déverrouiller tous les comptes verrouillés

Search-ADAccount -LockedOut -UsersOnly | Unlock-ADAccount

À utiliser avec précaution en production — vous ne voulez pas déverrouiller un compte qui a été verrouillé pour une bonne raison (tentative d'intrusion, par exemple).

Vérifier que le déverrouillage a été répliqué

Get-ADDomainController -Filter * | ForEach-Object {
    $Etat = Get-ADUser -Identity "jean.dupont" -Server $_.HostName -Properties LockedOut
    [PSCustomObject]@{
        DC         = $_.HostName
        Verrouille = $Etat.LockedOut
    }
} | Format-Table -AutoSize

Stratégie de prévention : les Fine-Grained Password Policies

La politique de verrouillage par défaut d'Active Directory s'applique à tous les utilisateurs du domaine, sans distinction. Et c'est un vrai problème quand vous avez des comptes de service qui ont besoin de règles différentes des comptes utilisateur standard.

Les Fine-Grained Password Policies (FGPP), disponibles depuis Windows Server 2008 et toujours pleinement supportées dans Windows Server 2025, permettent de définir des politiques de verrouillage différentes par groupe de sécurité. C'est un outil que trop peu d'admins utilisent, à mon avis.

Créer une FGPP pour les comptes de service

New-ADFineGrainedPasswordPolicy -Name "PSO-ComptesService" `
    -Precedence 10 `
    -LockoutThreshold 0 `
    -LockoutDuration "00:00:00" `
    -LockoutObservationWindow "00:00:00" `
    -MinPasswordLength 20 `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -MaxPasswordAge "365.00:00:00" `
    -MinPasswordAge "1.00:00:00"

Le LockoutThreshold est à 0 ici (pas de verrouillage) parce que les comptes de service n'ont pas d'interaction utilisateur — un verrouillage causerait une interruption de service, ce qui est bien pire. En contrepartie, on exige un mot de passe de minimum 20 caractères. C'est un compromis raisonnable.

Appliquer la FGPP à un groupe

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ComptesService" `
    -Subjects "GRP-ComptesDeService"

Vérifier quelle politique s'applique à un utilisateur

Get-ADUserResultantPasswordPolicy -Identity "svc.backup" |
    Select-Object Name, LockoutThreshold, LockoutDuration, MinPasswordLength

Environnements hybrides : Active Directory et Microsoft Entra ID

Si votre organisation utilise Microsoft Entra Connect (anciennement Azure AD Connect) pour synchroniser les identités vers le cloud, les verrouillages AD peuvent avoir des implications supplémentaires. C'est un aspect que beaucoup de guides oublient de couvrir.

Smart Lockout de Microsoft Entra

Microsoft Entra ID dispose de son propre mécanisme de verrouillage appelé Smart Lockout. Il fonctionne indépendamment de la politique AD on-premises et utilise l'intelligence artificielle pour distinguer les tentatives légitimes des attaques.

Le point important à retenir : si vous utilisez l'authentification pass-through (PTA) ou la fédération ADFS, une attaque ciblant le portail cloud peut provoquer des verrouillages dans votre AD on-premises. Le Smart Lockout d'Entra est justement conçu pour atténuer ce risque en bloquant les tentatives suspectes avant qu'elles n'atteignent votre AD.

Vérifier la synchronisation après un déverrouillage

Après avoir déverrouillé un compte dans AD, la synchronisation vers Entra ID peut prendre jusqu'à 30 minutes (cycle par défaut). Si l'utilisateur n'a vraiment pas la patience d'attendre (et avouons-le, qui l'a ?), forcez une synchro immédiate :

Start-ADSyncSyncCycle -PolicyType Delta

Script complet : diagnostic automatisé de verrouillage

Voici un script PowerShell prêt à l'emploi qui automatise l'ensemble du processus de diagnostic. Copiez-le et exécutez-le sur votre contrôleur de domaine ou un poste avec les RSAT installés. C'est le genre de script que vous allez garder dans votre boîte à outils pendant des années.

param(
    [Parameter(Mandatory=$true)]
    [string]$NomUtilisateur
)

Import-Module ActiveDirectory

Write-Host "=== DIAGNOSTIC DE VERROUILLAGE ===" -ForegroundColor Cyan
Write-Host "Utilisateur : $NomUtilisateur" -ForegroundColor Cyan
Write-Host ""

# 1. Statut du compte
$User = Get-ADUser -Identity $NomUtilisateur -Properties LockedOut, AccountLockoutTime,
    BadLogonCount, BadPasswordTime, LastLogonDate, PasswordLastSet
Write-Host "--- Statut du compte ---" -ForegroundColor Yellow
Write-Host "Verrouille       : $($User.LockedOut)"
Write-Host "Heure verrouillage : $($User.AccountLockoutTime)"
Write-Host "Tentatives echouees : $($User.BadLogonCount)"
Write-Host "Dernier echec MdP : $([datetime]::FromFileTime($User.BadPasswordTime))"
Write-Host "Derniere connexion : $($User.LastLogonDate)"
Write-Host "MdP modifie le   : $($User.PasswordLastSet)"
Write-Host ""

# 2. Recherche sur tous les DC
Write-Host "--- Statut par controleur de domaine ---" -ForegroundColor Yellow
Get-ADDomainController -Filter * | ForEach-Object {
    $DC = $_.HostName
    $Etat = Get-ADUser -Identity $NomUtilisateur -Server $DC -Properties LockedOut, BadLogonCount
    [PSCustomObject]@{
        DC                  = $DC
        Verrouille          = $Etat.LockedOut
        TentativesEchouees  = $Etat.BadLogonCount
    }
} | Format-Table -AutoSize

# 3. Recherche de la source sur le PDC
$PDC = (Get-ADDomain).PDCEmulator
Write-Host "--- Evenements 4740 sur le PDC ($PDC) ---" -ForegroundColor Yellow
try {
    Get-WinEvent -ComputerName $PDC -FilterHashtable @{
        LogName   = "Security"
        ID        = 4740
        StartTime = (Get-Date).AddDays(-1)
    } | Where-Object { $_.Message -match $NomUtilisateur } |
        Select-Object TimeCreated,
            @{N="OrdinateurSource"; E={($_.Properties[1]).Value}} |
        Format-Table -AutoSize
} catch {
    Write-Host "Impossible de lire les evenements sur $PDC. Verifiez vos permissions." -ForegroundColor Red
}

Write-Host "--- Diagnostic termine ---" -ForegroundColor Cyan

Enregistrez ce script sous le nom Diagnostic-Verrouillage.ps1 et exécutez-le :

.\Diagnostic-Verrouillage.ps1 -NomUtilisateur "jean.dupont"

Les événements clés à surveiller

Pour une surveillance proactive (et croyez-moi, la proactivité vous épargnera beaucoup de stress), voici les ID d'événements à monitorer dans vos journaux de sécurité :

ID événementDescriptionUtilité
4740Compte utilisateur verrouilléDétecte le verrouillage et la machine source
4625Échec de connexionDétaille la raison de l'échec et l'adresse IP
4771Échec pré-authentification KerberosIdentifie les échecs Kerberos avec adresse IP
4776Validation des identifiants NTLMIdentifie les échecs NTLM
4767Compte utilisateur déverrouilléTrace les déverrouillages manuels

FAQ

Comment trouver la source d'un verrouillage de compte Active Directory ?

Recherchez l'événement ID 4740 dans le journal de sécurité du contrôleur de domaine qui détient le rôle PDC Emulator. Le champ « Caller Computer Name » indique la machine d'où proviennent les tentatives échouées. La commande Get-WinEvent -FilterHashtable @{LogName="Security"; ID=4740} sur le PDC automatise cette recherche en quelques secondes.

Pourquoi un compte se verrouille-t-il immédiatement après le déverrouillage ?

C'est presque toujours dû à des identifiants périmés stockés quelque part : dans le Gestionnaire d'informations d'identification Windows, dans une tâche planifiée, un service Windows, une appli mobile, ou un lecteur réseau mappé. Tant que ces anciennes credentials ne sont pas supprimées, le compte continuera de se verrouiller en boucle. C'est le problème numéro un que je vois en production.

Quelle est la différence entre la politique de verrouillage du domaine et une Fine-Grained Password Policy ?

La politique du domaine (GPO Default Domain Policy) s'applique à tous les utilisateurs sans exception. Une FGPP permet de définir des règles de verrouillage différentes pour des groupes spécifiques — par exemple, un seuil plus élevé pour les comptes de service ou un verrouillage plus strict pour les comptes à privilèges. C'est beaucoup plus flexible, et franchement indispensable dans un environnement de taille moyenne ou grande.

Le verrouillage dans Active Directory affecte-t-il aussi Microsoft Entra ID ?

Oui, si vous utilisez Microsoft Entra Connect avec l'authentification pass-through ou la fédération ADFS, un verrouillage dans AD on-premises bloque également l'accès aux services cloud Microsoft 365. Inversement, le Smart Lockout d'Entra ID peut bloquer des tentatives cloud avant qu'elles ne provoquent un verrouillage AD. Les deux systèmes sont interconnectés, donc il faut les considérer ensemble.

Comment surveiller les verrouillages de comptes de manière proactive ?

Configurez une alerte sur l'événement ID 4740 dans votre SIEM ou utilisez un script PowerShell planifié qui envoie un email quand un verrouillage est détecté. Vous pouvez aussi utiliser des outils comme Netwrix Account Lockout Examiner pour centraliser la surveillance. L'important, c'est d'être prévenu avant que l'utilisateur ne vous appelle.

À propos de l'auteur Editorial Team

Our team of expert writers and editors.