Active Directory: sincronizzazione lock‑out account fra Domain Controller (DC) – guida completa a replica, badPwdTime e lockoutTime

Quando lo stato di lock‑out/unlock non si allinea su tutti i Domain Controller e “Last Bad Password” mostra date incoerenti, la causa è quasi sempre replica AD, skew dell’orologio o policy divergenti. In questa guida vediamo come funziona il lock‑out in Active Directory e un runbook operativo completo per risolvere.

Indice

Panoramica della domanda

Un amministratore nota che:

lo stato di account lock‑out / unlock non viene replicato su tutti i DC;
l’attributo Last Bad Password mostra un timestamp incoerente rispetto al giorno in cui l’account è stato bloccato.

Come funziona davvero il lock‑out in Active Directory

Capire il flusso interno aiuta a distinguere ciò che deve replicare da ciò che è, per design, locale a ciascun Domain Controller (DC):

badPwdCount e badPwdTime (visualizzato in ADUC come Last Bad Password) sono attributi non replicati. Vengono aggiornati sul DC che ha processato il tentativo errato.
lockoutTime si replica e determina lo stato di blocco globale dell’oggetto. Quando si raggiunge la soglia (Account Lockout Threshold), il DC che rileva la violazione imposta lockoutTime e notifica il PDC Emulator; la replica propaga l’informazione agli altri DC.
Il PDC Emulator ha un ruolo speciale: coordina password/lock‑out e viene interrogato dai DC in caso di incertezza per evitare falsi positivi.
lastLogon è per‑DC (non replica), mentre lastLogonTimestamp replica con cadenza “lenta” (finestra di aggiornamento predefinita), quindi non va usato per ricostruire eventi immediati.

Conseguenza pratica: è normale vedere Last Bad Password diverso sui vari DC. Se però lockoutTime non si allinea o l’utente resta sbloccato su alcuni DC, allora c’è un problema di replica, orario o policy.

Sintomi tipici e come interpretarli

Utente sbloccato su un DC ma ancora bloccato altrove: la replica di lockoutTime non è arrivata ovunque.
Timestamp “Last Bad Password” fuori scala: stai guardando un DC che non ha ricevuto l’ultimo tentativo errato; confronta il PDC e i DC che autenticano quell’utente (sito/RODC).
Lock‑out ricorrenti “misteriosi”: spesso credenziali memorizzate in servizi, agent, stampanti o device mobili; individua il Caller Computer Name negli eventi di sicurezza.

Risposta e soluzioni

Problema individuato	Causa probabile	Azioni consigliate
Ritardi o errori di replica	Replica AD lenta, pianificazione ristretta, link di sito saturi o errori in coda replicazione.	1. Eseguire `repadmin /showrepl * /csv` per una fotografia completa. 2. Usare `repadmin /queue` per verificare code. 3. Verificare che i siti AD, i costi dei link e i bridgehead server siano configurati correttamente. 4. Controllare l’Event Viewer (log Directory Service e DFSR) per Event ID 1988, 2042, 4012, 4612.
Conflitti di replica (USN/Versione attributo)	Due DC ricevono modifiche simultanee; la più “recente” sovrascrive la precedente.	Analizzare gli attributi `uSNChanged`, `whenChanged` e `versionNumber` dell’oggetto utente su ciascun DC con `repadmin /showobjmeta`. Se un DC non incrementa correttamente i valori, forzare replica o avviare un autoreseeding.
Problemi di autorizzazione	Account dei DC o NTDS Settings con permessi ridotti, ACL corrotti.	Verificare che il gruppo Enterprise Domain Controllers possieda i diritti “Replicating Directory Changes” e “Replicating Directory Changes All” su radice dominio e CN=Configuration.
Skew dell’orologio	Differenze >5 minuti fra DC impediscono Kerberos e la replica protetta.	Controllare NTP (W32Time) con `w32tm /query /status`. Fare in modo che tutti i DC puntino a un’unica fonte attendibile (idealmente il PDC Emulator).
Impostazioni eterogenee di “Account Lockout Threshold”	Policy divergenti fra siti o OU fanno sì che un DC non consideri un tentativo errato un “badPwdCount” valido.	Allineare GPO di dominio: stesso valore di Lockout Threshold, Observation Window, Lockout Duration.

Passi operativi rapidi

Verificare replica immediata repadmin /syncall /AdeP Controllare che non compaiano messaggi tipo Last attempt @ … failed with status 8452.
Diagnosticare DC dcdiag /c /v /e /f:dcdiag.log Esaminare le sezioni Replications, Advertising, FrsEvent.
Riconfigurare i siti In Active Directory Sites and Services, assicurarsi che:
- ogni subnet sia assegnata al sito corretto (evita autenticazioni cross‑site);
- esista almeno un link di replica con schedulazione “Always” per i DC critici.
Controllare attributi dell’account Con Attribute Editor o con PowerShell confermare i valori su più DC: # Se la versione del modulo lo supporta: Get-ADUser <SamAccountName> -IncludeAccountLockoutTime -Server <DC> ` | Select-Object Name,lockoutTime,badPwdCount,lastLogonTimestamp In alternativa, metodo universale: Get-ADUser -Properties lockoutTime,badPwdTime,badPwdCount,lastLogon,lastLogonTimestamp ` -Server | Select Name,lockoutTime,badPwdCount,badPwdTime,lastLogon,lastLogonTimestamp Convertire badPwdTime da FILETIME: ([datetime]::FromFileTime((Get-ADUser -Properties badPwdTime).badPwdTime))
- lockoutTime (0 = sbloccato);
- badPwdCount (per‑DC, non replicato);
- lastLogonTimestamp (replica differita: non usarlo per eventi immediati).
Allineare orari Sul PDC Emulator: w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org" /update Poi forzare la risincronizzazione sugli altri DC/domino: w32tm /resync /nowait w32tm /query /status

Analisi approfondita: replica AD e lock‑out

Controlli “repadmin” utili

repadmin /showrepl * /csv &gt; repl.csv      # fotografia completa delle relazioni
repadmin /replsummary                    # errori e latenza media
repadmin /failcache &lt;DC&gt;                 # partner in errore
repadmin /queue &lt;DC&gt;                     # richieste in coda
repadmin /showobjmeta &lt;DC&gt; &lt;DN_utente&gt;   # metadati, versioni attributo

Se lockoutTime presenta versioni diverse fra DC, la replica non è aggiornata: forzala verso/da il PDC e dal PDC verso gli altri DC finché la versione coincide.

Eventi da cercare

Security: 4740 (Account locked out), 4771/4776 (Kerberos/NTLM failure) – mostreranno il Caller Computer Name per risalire alla fonte delle credenziali errate.
Directory Service: 1988 (lingering object), 2042 (non authoritative restore), 4012/4612 (replica ritardata/riconnessione).
DFSR: 4012/5002/5014 in presenza di problemi sul SYSVOL (che può influire su GPO di lock‑out e orari di applicazione).
System – Time‑Service: 35/36, 47 (problemi di sincronizzazione NTP).

Kerberos e skew dell’orologio

Il lock‑out è protetto da Kerberos. Se l’orologio differisce oltre la tolleranza (5 minuti di default), l’autenticazione fallisce generando falsi “bad password” e, a cascata, lock‑out e repliche bloccate. Allinea sempre gli orologi secondo la gerarchia del dominio: tutti i membri e DC sincronizzano con i propri DC; il PDC Emulator del dominio radice sincronizza con un’origine esterna affidabile.

Policy di lock‑out coerenti

Valori non allineati fra GPO di dominio e GPO di sito/OU inducono comportamenti diversi. Consolidare in una GPO di dominio i parametri:

Account lockout threshold (soglia);
Account lockout duration (durata);
Reset account lockout counter after (observation window).

Assicurati che i DC ricevano la GPO: usa gpresult /h sui DC e verifica l’OU dove risiedono gli oggetti Domain Controllers.

Strumenti e script che fanno risparmiare tempo

Elenco account bloccati e DC coinvolti

$dcs = (Get-ADDomainController -Filter *).HostName
$user = "<SamAccountName>"

foreach($dc in $dcs){
$u = Get-ADUser $user -Server $dc -Properties lockoutTime,badPwdTime,badPwdCount
[PSCustomObject]@{
DC              = $dc
LockoutTime     = $u.lockoutTime
BadPwdCount     = $u.badPwdCount
LastBadPassword = if($u.badPwdTime){ [datetime]::FromFileTime($u.badPwdTime) } else { $null }
}
} | Sort-Object DC | Format-Table -Auto

Forzare replica mirata del solo oggetto utente

repadmin /replicate &lt;DCDestinazione&gt; &lt;DCSorgente&gt; &lt;NamingContext&gt; /object:&lt;DN_utente&gt;

Utile quando lockoutTime è aggiornato su un DC ma non sugli altri e vuoi evitare di far fluire tutto il naming context.

Trovare client/servizi che causano lock‑out

# Security Log sul DC che autentica l’utente
Get-WinEvent -LogName Security -FilterXPath "*[System[(EventID=4740)]]" `
| Where-Object { $_.Properties[0].Value -like "&lt;SamAccountName&gt;" } `
| Select-Object TimeCreated,
                @{n='Utente';e={$_.Properties[0].Value}},
                @{n='CallerComputer';e={$_.Properties[1].Value}} `
| Sort-Object TimeCreated -Descending | Format-Table -Auto

Correla con 4771/4776 per capire se è Kerberos o NTLM e qual è il dispositivo/servizio responsabile (stampanti, task schedulati, agent, app legacy).

RODC, filiali e Password Replication Policy

Nelle topologie HUB/SPOKE con Read‑Only DC (RODC) in filiale:

Valuta la Password Replication Policy (PRP): consenti la cache solo degli account necessari in filiale per ridurre lock‑out remoti se il collegamento WAN è instabile.
Pre‑popola la cache per gli utenti critici prima di lavori programmati (migrazioni/password reset) per evitare raffiche di autenticazioni cross‑site.
Controlla la replica inter‑site: se la frequenza è elevata (es. ogni 180 min) abilita Change Notification sui link tra siti sensibili.

Autorizzazioni e sicurezza della replica

Se ACL o deleghe sono state alterate, i DC potrebbero non leggere/scrivere gli attributi necessari:

Verifica che il gruppo Enterprise Domain Controllers possegga i diritti Replicating Directory Changes e Replicating Directory Changes All su CN=Configuration e radice del dominio.
Controlla che gli oggetti NTDS Settings dei DC non abbiano permessi personalizzati che impediscono la replica in ingresso/uscita.

Patch, antivirus e rete

Aggiorna driver di rete dei DC: latenze e packet‑loss impattano RPC/SMB usati dalla replica.
Escludi dai controlli in tempo reale le cartelle NTDS e SYSVOL sugli antivirus endpoint‑server.
Se usi ispezione firewall o IPS su RPC endpoint mapper e SMB, applica eccezioni per il traffico DC‑to‑DC.

Runbook di riferimento (da stampare)

Conferma il PDC Emulator: netdom query fsmo. Lavora prima su quel DC.
Stato replica: repadmin /replsummary, quindi repadmin /showrepl *. Se errori, correggi DNS, connettività, orari.
Allinea orologi come descritto; verifica con w32tm /query /status su ogni DC.
Forza la replica: repadmin /syncall /AdeP. Controlla le code.
Verifica GPO di lock‑out e che i DC ricevano la GPO corretta (gpresult /h).
Confronta gli attributi su 2‑3 DC inclusi PDC e DC del sito utente (lockoutTime, badPwdCount, badPwdTime).
Trova l’origine dei tentativi errati (eventi 4740/4771/4776) e correggi le credenziali memorizzate.
Ripeti i test di accesso e monitora per 24‑48h con alert (vedi sezione successiva).

Monitoraggio proattivo

Log forwarding dal canale Security dei DC verso un SIEM: crea regole per 4740, 4771, 4776 con aggregazione per utente e per “Caller Computer”.
Script PowerShell pianificati che eseguono repadmin /replsummary e segnalano latenze > 15 minuti o code non vuote.
Health agent (es. AD Connect Health, System Center, ecc.) per tenere d’occhio replica, orologi e servizi Netlogon/Time Service.

Domande frequenti

Perché “Last Bad Password” segna un giorno diverso rispetto al blocco?
Perché badPwdTime è locale al DC che ha visto il tentativo errato (non si replica). Il blocco avviene quando la somma dei tentativi su quel DC raggiunge la soglia; il lockoutTime invece si replica a tutti.

È normale che badPwdCount sia diverso fra DC?
Sì. È per‑DC. Per indagini guarda il PDC e i DC del sito dell’utente.

Posso “azzerare” manualmente badPwdCount?
No: si azzera dopo un accesso riuscito o allo scadere della observation window. Puoi però sbloccare impostando lockoutTime = 0 (via interfaccia o PowerShell), operazione che replica rapidamente.

Perché l’utente si ri‑blocca subito dopo lo sblocco?
Ci sono credenziali memorizzate altrove (servizi, app, device). Trova la sorgente con 4740/4771/4776 e correggi prima di sbloccare definitivamente.

Checklist finale

PDC Emulator individuato e allineato all’NTP esterno.
Replica senza errori; latenza sotto soglia e code vuote.
GPO di lock‑out coerente a livello di dominio.
Subnets assegnate ai siti corretti; autenticazioni locali al sito.
Eventi Security monitorati; origine tentativi errati identificata e sanata.
Attributi utente coerenti (lockoutTime) su tutti i DC; consapevolezza che Last Bad Password (badPwdTime) è per‑DC.
Esclusioni antivirus su NTDS e SYSVOL applicate; driver e patch aggiornati.

Informazioni supplementari utili

Topologia HUB/SPOKE: se i DC non parlano fra loro (es. filiali), impostare una Password Replication Policy adeguata su RODC per ridurre i lock‑out remoti.
Monitoraggio proattivo: usa agent o script PowerShell per avvisi tempo‑reale sullo stato replica.
Patch & antivirali: driver di rete obsoleti o antivirus che ispezionano RPC/SMB possono rallentare la replica; escludere le cartelle SYSVOL e NTDS.

Esempi di comandi riassuntivi

# Stato replica
repadmin /replsummary
repadmin /showrepl *

Sincronizzazione completa e diagnostica

repadmin /syncall /AdeP
repadmin /queue

Diagnostica DC

dcdiag /c /v /e /f:dcdiag.log

Time Service

w32tm /query /status
w32tm /config /syncfromflags:manual /manualpeerlist:"pool.ntp.org" /update
w32tm /resync /nowait

Attributi utente (per-DC)

Get-ADUser  -Properties lockoutTime,badPwdTime,badPwdCount,lastLogon,lastLogonTimestamp -Server  `
| Select Name,lockoutTime,badPwdCount, @{n="LastBadPwd";e={[datetime]::FromFileTime($_.badPwdTime)}}, lastLogon,lastLogonTimestamp

Conclusione

La desincronizzazione dello stato di lock‑out tra Domain Controller nasce quasi sempre da replica lenta/errata, orologi non allineati o policy incoerenti. Con il flusso operativo e gli script di questa guida puoi riportare lockoutTime in stato consistente su tutti i DC, capire perché i timestamp di Last Bad Password non coincidono e prevenire il ripetersi del problema.

Nota operativa veloce

repadmin /syncall /AdeP senza errori 8452 → OK.
Eventi 4740/4771/4776 → individua la sorgente dei tentativi errati.
Allinea NTP via PDC Emulator → niente skew, niente falsi “bad password”.
Uniforma le GPO di lock‑out → comportamento prevedibile su tutti i DC.

Seguendo queste verifiche l’allineamento dello stato di blocco/sblocco e la corretta registrazione del Last Bad Password torneranno a funzionare in maniera consistente su tutti i controller di dominio.