Verrouillage AD : réplication urgente, PDC Emulator et lastBadPasswordTime — diagnostic & remédiation

Les comptes verrouillés ou déverrouillés ne se synchronisent pas entre vos DC ? Ce guide explique pourquoi, comment diagnostiquer précisément la cause (réplication urgente, PDC Emulator, horloge, topologie) et comment corriger durablement avec des commandes et scripts prêts à l’emploi.

Sommaire

Verrouillage/déverrouillage de comptes Active Directory non répliqué sur l’ensemble des contrôleurs de domaine (DC)

Vue d’ensemble de la question

Un administrateur constate que l’état « verrouillé » ou « déverrouillé » d’un compte utilisateur ne s’aligne pas rapidement sur tous les contrôleurs de domaine. Dans la foulée, l’attribut lastBadPasswordTime semble « en retard » par rapport au moment réel du verrouillage. Ce comportement est typique d’un écart entre la réplication urgente des attributs de sécurité (ex. lockoutTime) et la réplication normale d’attributs moins critiques (ex. lastBadPasswordTime), aggravé par une latence de réplication, une topologie mal optimisée ou un PDC Emulator injoignable.

Ce qu’il faut comprendre avant de dépanner

Qui décide du verrouillage ? Le PDC Emulator du domaine est l’arbitre ultime : c’est lui qui confirme le dépassement du lockoutThreshold et qui publie le lockoutTime en réplication urgente.
Réplication urgente vs normale :
- Urgente : certaines mises à jour de sécurité (dont lockoutTime et les changements de mot de passe) déclenchent des notifications immédiates. Dans un environnement sain, l’harmonisation intrasite est quasi instantanée et intersite dépend de la configuration des liaisons et notifications.
- Normale : d’autres attributs (dont lastBadPasswordTime) suivent l’intervalle classique (souvent perçu comme ~15 min quand les change notifications intersite ne sont pas activées). Un décalage n’est donc pas forcément une anomalie.
Attributs à ne pas surinterpréter : badPwdCount est local à chaque DC (non répliqué). Ne l’utilisez pas pour déduire une chronologie globale.
Horloge et Kerberos : un écart d’horloge > 5 min perturbe à la fois Kerberos et la réplication ; cela suffit à expliquer des verrouillages « fantômes » ou des délais.

Réponses & solutions proposées

Axe d’analyse	Points de contrôle	Commandes / actions utiles
Latence ou échec de réplication AD	Urgent Replication (`lockoutTime`) doit être quasi‑immédiat ; si ce n’est pas le cas, suspecter une latence excessive ou des erreurs de réplication.	`repadmin /showrepl`, `repadmin /replsummary`, `repadmin /syncall`, consulter les journaux Directory Service & DNS Server
Topologie et planification de site	Liaisons de site désactivées ou horaires restreints → retards.	Vérifier AD Sites and Services, s’assurer que la KCC génère bien les liaisons IP et qu’aucun horaire de réplication n’est bloquant.
Rôle du PDC Emulator	Le verrouillage est confirmé par le PDC et répliqué en mode urgent. S’il est indisponible/injoignable, les autres DC conservent un état obsolète.	`netdom query fsmo` pour identifier le PDC, tests ICMP/ports 135‑139/445, surveillance des événements 2103, 5719.
Horloge	Écart de temps > 5 min = pb Kerberos & réplication.	`w32tm /query /status` puis corriger NTP si nécessaire.
Conflits de réplication / autorisations	Conflits éventuels ou ACL restreignant la réplication des attributs de sécurité.	`repadmin /showobjmeta <DN> lockoutTime`, audit des ACL sur les partitions AD.
Spécificité de `lastBadPasswordTime`	Attribut non répliqué en urgence. Un décalage est attendu et n’indique pas forcément une anomalie.	Surveiller sur le DC local ou le PDC Emulator.

Checklist de diagnostic express

Qui est PDC ? netdom query fsmo. Noter le nom du DC.
Le PDC répond‑il ? ping, Test-NetConnection PDC -Port 135,389,445 et vérifier les règles firewall (y compris plage RPC dynamique).
Réplication globale : repadmin /replsummary. Zéro échec attendu.
Réplication de l’objet utilisateur : repadmin /showobjmeta "CN=Utilisateur,...,DC=..." (focus lockoutTime) et comparer les DC d’origine/horodatages.
Horloge : w32tm /query /status sur tous les DC ; corriger toute dérive > 5 min.
Événements 4740/4767 (verrouillage/déverrouillage) sur tous les DC : identifier celui qui traite l’opération.

Procédure de remédiation recommandée

État de santé global : exécuter dcdiag /e /v et corriger toutes les erreurs DNS, Netlogon, ou réplication.
Forcer une synchronisation complète pour valider qu’aucune erreur bloquante n’existe : repadmin /syncall /AdeP.
Surveiller les événements 4740 (verrouillage) et 4767 (déverrouillage) pour savoir quel DC effectue l’écriture.
Stabilité du PDC Emulator : vérifier connectivité constante (ICMP et ports RPC/LDAP/SMB). En cas d’instabilité matérielle/réseau, envisager de déplacer le rôle FSMO PDC vers un DC sain.
Aligner l’heure sur une source fiable (NTP externe au sommet de la forêt, PDC root comme source interne). w32tm /config si nécessaire.
Confirmer la réplication urgente : après un nouveau verrouillage de test, lockoutTime doit être identique sur chaque DC en ≲ 30 s dans un environnement sain (intrasite). Intersite dépend des notifications/horaires configurés.
Opérationnaliser : documenter et planifier un contrôle quotidien via PowerShell (Get-ADReplicationPartnerMetadata, Get-ADUser -Properties lockoutTime) pour détecter de manière proactive tout décalage inhabituel.

Scripts PowerShell prêts à l’emploi

1) Photographier l’état des attributs de verrouillage sur tous les DC

$ErrorActionPreference = 'Stop'

# Paramètres

\$UserSam = Read-Host 'sAMAccountName de l’utilisateur à analyser'

# Fonctions utilitaires

function Convert-FileTime {
param(\[long]\$Value)
if (\$Value -gt 0) { \[DateTime]::FromFileTimeUtc(\$Value) } else { \$null }
}

# Récupère tous les DC du domaine

\$DCs = Get-ADDomainController -Filter \* | Sort-Object HostName

# Collecte par DC

\$rows = foreach (\$dc in \$DCs) {
try {
\$u = Get-ADUser -Identity \$UserSam -Server \$dc.HostName -Properties lockoutTime,lastBadPasswordTime,badPwdCount,whenChanged
\[PSCustomObject]@{
DC                     = \$dc.HostName
LockoutTime            = Convert-FileTime \$u.lockoutTime
LastBadPasswordTime    = Convert-FileTime \$u.lastBadPasswordTime
BadPwdCount\_LocalDC    = \$u.badPwdCount
WhenChanged            = \$u.whenChanged
}
} catch {
\[PSCustomObject]@{
DC                     = \$dc.HostName
LockoutTime            = \$null
LastBadPasswordTime    = \$null
BadPwdCount\_LocalDC    = \$null
WhenChanged            = \$null
}
}
}

\$rows | Format-Table -AutoSize

# Indicateur rapide : écart de LockoutTime

\$ref = (\$rows | Where-Object { \$*.LockoutTime } | Select-Object -First 1).LockoutTime
if (\$ref) {
\$drift = \$rows | Where-Object { \$*.LockoutTime } | ForEach-Object {
\[PSCustomObject]@{ DC = \$*.DC; DriftSeconds = \[math]::Round( (New-TimeSpan -Start \$ref -End \$*.LockoutTime).TotalSeconds, 1 ) }
}
'--- Ecart LockoutTime (s) vs référence ---'
\$drift | Format-Table -AutoSize
} else {
'Aucun LockoutTime trouvé (compte non verrouillé).'
}

2) Retrouver le DC qui a réellement verrouillé (ID 4740) ou déverrouillé (ID 4767)

$UserSam = Read-Host 'sAMAccountName'
$Since   = (Get-Date).AddDays(-2)  # fenêtre de recherche

\$DCs = Get-ADDomainController -Filter \* | Sort-Object HostName

foreach (\$dc in \$DCs) {
Write-Host "== \$(\$dc.HostName) ==" -ForegroundColor Cyan
Get-WinEvent -ComputerName \$dc.HostName -FilterHashtable @{LogName='Security'; Id=4740; StartTime=\$Since} -ErrorAction SilentlyContinue |
Where-Object { \$*.Properties\[0].Value -like "*\$UserSam*" } |
Select-Object TimeCreated, Id, @{n='TargetUser';e={\$*.Properties\[0].Value}}, @{n='CallerComputer';e={\$*.Properties\[1].Value}} |
Format-Table -AutoSize
Get-WinEvent -ComputerName \$dc.HostName -FilterHashtable @{LogName='Security'; Id=4767; StartTime=\$Since} -ErrorAction SilentlyContinue |
Where-Object { \$*.Properties\[0].Value -like "*\$UserSam*" } |
Select-Object TimeCreated, Id, @{n='TargetUser';e={$\_.Properties\[0].Value}} |
Format-Table -AutoSize
}

3) Vérifier la santé de la réplication et la topologie

repadmin /replsummary
repadmin /showrepl *
repadmin /showobjmeta "CN=Utilisateur,CN=Users,DC=contoso,DC=com" lockoutTime
# Synchronisation forcée (prudent en prod)
repadmin /syncall /AdeP

4) Tester la connectivité vers le PDC Emulator

$pdc = (Get-ADDomain).PDCEmulator
"Vérification du PDC&nbsp;: $pdc"
Test-Connection -ComputerName $pdc -Count 2
135,139,389,445,3268 | ForEach-Object {
  Test-NetConnection -ComputerName $pdc -Port $_
}

5) Normaliser l’heure (NTP)

w32tm /query /status
# Exemple&nbsp;: définir un pair NTP fiable (externe) sur le PDC de la forêt
# w32tm /config /manualpeerlist:"time.example.org" /syncfromflags:manual /update
# w32tm /resync /nowait

Table d’interprétation des attributs liés au verrouillage

Attribut	Réplication	Où la valeur est fiable « immédiatement » ?	Remarques
`lockoutTime`	Urgente	Sur le DC d’écriture et le PDC Emulator, puis rapidement partout	Référence pour savoir si le compte est verrouillé (`>0`) et quand.
`lastBadPasswordTime`	Normale	Sur le DC ayant vu l’échec de mot de passe ; le PDC en a souvent la vue la plus cohérente	Décalage attendu entre DC ; ne pas l’employer comme alerte de verrouillage « temps réel ».
`badPwdCount`	Non répliqué	Local à chaque DC uniquement	Utile pour comprendre où ont lieu les tentatives ; pas pour compter globalement.
`pwdLastSet`	Urgente (événement changement de mot de passe)	Rapide sur tous les DC	À corréler avec les journaux 4723/4724 (chgt/réin. de mot de passe).

Causes racines fréquentes et comment les prouver

Le PDC Emulator est lent, surchargé ou injoignable : pics CPU/IO, cluster hôte instable, firewall ou NAT cassant les RPC, DNS manquant. Preuves : événements Netlogon 5719, RPC/LSA, échecs Test-NetConnection sur 135/389/445, lenteur repadmin /replsummary avec ce DC.
Topologie intersite sous-optimisée : pas de change notification, plages de réplication trop espacées ou fenêtres fermées, bridge all site links mal configuré. Preuves : AD Sites and Services → options de liens de site, vérification KCC, absence de connexions IP redondantes.
Horloge dérive/chaîne NTP défectueuse : le PDC de la forêt n’est pas synchronisé sur une source stable ; des DC fils dérivent. Preuves : w32tm /query /status incohérent, erreurs Kerberos (KRB_AP_ERR_SKEW), tickets refusés.
Conflits de réplication/ACL restrictives : attributs de sécurité non répliqués vers certains DC à cause d’ACL custom ou d’un conflit d’USN. Preuves : repadmin /showobjmeta ne montre pas d’update sur certains DC, événements AD DS, objets persistants (lingering objects).
RODC et liaisons vers un écrivant lointain : vérif. de mot de passe qui transite par un lien intersite lent ; décisions de verrouillage retardées. Preuves : événements de verrouillage localisés sur un RODC ; latence élevée entre sites.
Clients et serveurs d’applications mal configurés : authentification contrainte sur un DC spécifique, caches d’identifiants, retry storms d’apps. Preuves : journaux applicatifs, corrélation CallerComputer des 4740 avec les horaires d’incident.

Bonnes pratiques préventives

Monitoring : alerte sur tout échec de réplication (repadmin), sur le backlog, et sur l’indisponibilité du PDC. Centraliser les 4740/4767.
DNS sain : DC enregistrés correctement (SRV), résolution interne rapide, pas de fuite vers des DNS externes.
NTP robuste : configurer une source fiable sur le PDC de la forêt ; propager par hiérarchie AD (NT5DS).
Topologie : au moins deux liaisons redondantes entre sites critiques, notifications de changement activées si nécessaire, pas de fenêtres fermées pendant les horaires d’activité.
PDC Emulator : héberger sur un matériel/VM performant, stockage rapide, antivirus excluant les chemins AD (Base NTDS, SYSVOL), sauvegardes cohérentes VSS.
Procédures : runbooks de déverrouillage (avec identification du DC d’origine), scripts de diagnostic standards, plan de bascule FSMO documenté.

Guide pas à pas (runbook)

Confirmer le symptôme : verrouiller un compte de test (mauvais mot de passe jusqu’au seuil). Observer lockoutTime sur 2‑3 DC différents via le script #1.
Isoler l’écrivain : avec le script #2, trouver le DC qui a logué l’événement 4740. Est‑ce le PDC ou un autre DC ?
Vérifier/forcer la réplication : repadmin /syncall /AdeP. Si des échecs apparaissent, corriger (DNS, RPC, authentification intersite, plages horaires fermées).
Écarter la dérive d’horloge : corriger la source NTP et resynchroniser (w32tm /resync), surtout sur le PDC.
Tester la reprise : déverrouiller le compte (4767), vérifier la propagation. Répéter côté intersite (si pertinent) à un moment où la réplication est autorisée.
Stabiliser : si le PDC est fautif, déplacer temporairement le rôle (Move-ADDirectoryServerOperationMasterRole) vers un DC sain jusqu’à résolution.
Industrialiser : planifier les scripts d’observabilité (journal quotidien ou SIEM) et activer des alertes (ex. écart lockoutTime > 60 s).

FAQ

Q : Pourquoi lastBadPasswordTime est différent d’un DC à l’autre ?
R : Parce qu’il suit la réplication normale. Le DC qui a vu la tentative échouée l’écrit immédiatement, les autres l’apprennent plus tard. Ce n’est pas un indicateur « temps réel » partagé comme lockoutTime.

Q : Combien de temps prend la réplication urgente ?
R : Intrasite : quelques secondes en général. Intersite : ça dépend des notifications de changement et des plages horaires ; si la liaison est fermée ou très lente, la réplication peut attendre la prochaine fenêtre.

Q : Déverrouiller côté « mauvais DC » suffit‑il ?
R : Le déverrouillage doit toujours atteindre le PDC Emulator et se répliquer en urgence. Si le PDC est injoignable, le symptôme réapparaîtra ailleurs.

Q : Dois‑je m’appuyer sur badPwdCount pour déclencher des alertes ?
R : Non. Le compteur est local au DC. Utilisez plutôt les événements 4740/4767 centralisés et la valeur lockoutTime côté PDC.

Q : Les RODC compliquent‑ils la donne ?
R : Un RODC ne peut pas écrire le verrouillage ; il doit contacter un DC écrivant (souvent le PDC). Sur des liens WAN lents ou filtrés, cela peut allonger le temps d’observation.

Points d’attention opérationnels

Pare‑feu : ouvrir et surveiller les ports AD (LDAP 389/636, GC 3268/3269, RPC 135 + plage dynamique, SMB 445). Les blocages aléatoires expliquent de nombreux symptômes « fantômes ».
DNS : le moindre défaut SRV (enregistrement manquant, zone incohérente entre DC) casse la découverte de partenaires de réplication et l’emplacement du PDC.
Antivirus : exclure les chemins AD (base NTDS.dit, journaux, SYSVOL) et les processus (lsass.exe) selon les recommandations de l’éditeur.
Change management : tout déplacement FSMO ou modification de liaisons de site doit être documenté, testé hors heures de pointe et validé par repadmin.

Exemple de rapport automatisé quotidien

# Génère un CSV d’état pour le SIEM / l’Ops
$now = Get-Date -Format "yyyyMMdd-HHmmss"
$out = "C:\Reports\AD-Lockout-Drift-$now.csv"
$UserList = 'user1','user2' # à remplacer par une liste pertinente
$DCs = Get-ADDomainController -Filter * | Sort-Object HostName

\$result = foreach (\$name in \$UserList) {
foreach (\$dc in \$DCs) {
try {
\$u = Get-ADUser -Identity \$name -Server \$dc.HostName -Properties lockoutTime,lastBadPasswordTime
\[PSCustomObject]@{
User                  = \$name
DC                    = \$dc.HostName
LockoutTimeUtc        = if(\$u.lockoutTime -gt 0){ \[DateTime]::FromFileTimeUtc(\$u.lockoutTime) } else { \$null }
LastBadPasswordTimeUtc= if(\$u.lastBadPasswordTime -gt 0){ \[DateTime]::FromFileTimeUtc(\$u.lastBadPasswordTime) } else { \$null }
}
} catch {
\[PSCustomObject]@{ User=\$name; DC=\$dc.HostName; LockoutTimeUtc=\$null; LastBadPasswordTimeUtc=\$null }
}
}
}

\$result | Export-Csv -NoTypeInformation -Path \$out
Write-Host "Rapport écrit : \$out"

Synthèse

Quand les états de verrouillage/déverrouillage ne se propagent pas vite, suspectez en priorité : (1) la réplication urgente qui n’aboutit pas (repadmin à l’appui), (2) un PDC Emulator indisponible, (3) une topologie intersite trop restrictive, (4) une dérive d’horloge. Traitez ces axes dans l’ordre : vérification de santé AD, correction DNS/ports/horaires, stabilisation du PDC, alignement NTP. Acceptez enfin que lastBadPasswordTime ne soit pas un indicateur temps réel global : basez vos automatisations sur lockoutTime et sur les événements 4740/4767. En appliquant cette méthode, vous retrouverez une propagation quasi instantanée des verrouillages dans tout le domaine, y compris entre sites.

Annexe : commandes utiles (mémo)

netdom query fsmo
nltest /dclist:&lt;Domaine&gt;
repadmin /replsummary
repadmin /showrepl *
repadmin /showobjmeta "&lt;DN utilisateur&gt;" lockoutTime
repadmin /syncall /AdeP
dcdiag /e /v
w32tm /query /status
Get-ADReplicationPartnerMetadata -Target * | Select Server,Partner,ConsecutiveReplicationFailures,LastReplicationSuccess
Get-ADUser -Identity &lt;samAccountName&gt; -Properties lockoutTime,lastBadPasswordTime,badPwdCount | fl *

Rappel important

lockoutTime et pwdLastSet sont répliqués en urgence et doivent converger rapidement entre DC.
lastBadPasswordTime n’est pas répliqué en urgence et suit le cycle normal : le décalage observé est attendu.
Dans un environnement multi‑sites, dimensionnez correctement les liaisons et, si besoin, activez les change notifications intersite pour réduire la latence perçue.

Avec cette démarche — contrôle de santé AD, correction de la topologie, surveillance du PDC Emulator et alignement de l’horloge — la propagation des états de verrouillage redeviendra fiable et rapide à l’échelle de tous vos contrôleurs de domaine.

Verrouillage AD : réplication urgente, PDC Emulator et lastBadPasswordTime — diagnostic & remédiation