Account Active Directory bloccato e impossibile da sbloccare: guida completa al troubleshooting

Hai un account Active Directory che si blocca di continuo e ogni tentativo di “Unlock” o reset password fallisce? In questa guida operativa ti mostro come diagnosticare in profondità la causa reale del lockout ricorrente e come risolverla in modo definitivo, con comandi, eventi e checklist pronti all’uso.

Indice

Panoramica del problema

Quando un account Active Directory risulta bloccato e, nonostante lo sblocco manuale e la reimpostazione della password, torna immediatamente allo stato locked, nella quasi totalità dei casi c’è un dispositivo o un processo (PC, server, servizio, attività pianificata, app, sessione RDP, dispositivo mobile, VPN/Wi‑Fi 802.1X, applicazione legacy, script, stampante di rete) che continua a inviare credenziali obsolete. Ogni tentativo errato incrementa il contatore di bad logon fino a raggiungere la soglia imposta dalla Account Lockout Policy. Il blocco viene applicato dal Domain Controller (DC) che elabora il tentativo di autenticazione e si propaga agli altri DC tramite replica.

Per risolvere in modo affidabile occorrono tre mosse: registrare correttamente gli eventi sui DC, identificare il DC e il client che causano il lockout, intervenire sul client responsabile eliminando le credenziali memorizzate o correggendo la configurazione. Di seguito trovi un playbook completo, basato sulle best practice di auditing e su esempi reali.

Percorso rapido di troubleshooting

Se hai urgenza e vuoi arrivare in fretta alla radice del problema, segui questo percorso “fast track” prima di estendere l’analisi:

Trova il DC coinvolto con LockoutStatus.exe (Account‑Lockout and Management Tools): cerca il dominio\utente e individua il DC che ha registrato il lockout e l’IP/hostname di origine.
Apri i log di Sicurezza su quel DC: evento 4740 (Account locked out) nell’orario esatto; attorno ad esso cerca 4771 (Kerberos) e/o 4776 (NTLM) per la causa e il client.
Raggiungi il client indicato da Client Address (Kerberos) o Source Workstation (NTLM) e rimuovi vecchie credenziali, servizi o task che usano l’account.
Conferma monitorando nuovi eventi di fallimento (4625) direttamente sul client per capire quale processo invia la password errata.

Abilitare la registrazione completa degli eventi sui DC

Un auditing incompleto è la causa principale di diagnosi lente. Imposta una Advanced Audit Policy specifica sui Domain Controller per vedere tutto ciò che serve.

Policy consigliata

Categoria	Sottocategoria	Successo	Fallimento	Eventi chiave
Account Logon	Kerberos Authentication Service, Kerberos Service Ticket Operations	Sì	Sì	4768, 4769, 4771
Logon/Logoff	Logon	Sì	Sì	4624, 4625
Account Management	User Account Management	Sì	Sì	4720–4738, 4740
DS Access	Directory Service Changes (opz.)	Sì	No	Eventi di modifica oggetti
Policy Change	Authentication Policy Change (opz.)	Sì	Sì	4800+

Come configurare

In una GPO linkata all’OU Domain Controllers:

Percorso: Configurazione Computer → Criteri → Impostazioni di Windows → Impostazioni di sicurezza → Criteri di controllo avanzati.
Abilita Success e Failure per le sottocategorie elencate sopra.

Applica e verifica:

gpupdate /force
auditpol /get /category:*

Conferma che le sottocategorie mostrino Success and Failure attivi sui DC.

Individuare il Domain Controller che ha bloccato l’account

Il DC che registra il blocco (4740) è quello che ha elaborato il tentativo errato; può coincidere con il PDC Emulator, ma non necessariamente. Strumenti e comandi utili:

LockoutStatus.exe: File → Select Target → dominio\utente. Nella griglia visualizzi i DC, il Bad Pwd Count, l’orario dell’ultimo bad password, il DC che ha eseguito il lockout e l’IP/hostname di origine.
PowerShell (modulo ActiveDirectory): # Trova l'utente bloccato e i tempi utili Get-ADUser <SamAccountName> -Properties LockedOut,LastBadPasswordAttempt,BadLogonCount,LastLogonDate | Select-Object SamAccountName,LockedOut,BadLogonCount,LastBadPasswordAttempt,LastLogonDate Elenco sintetico di account bloccati Search-ADAccount -LockedOut | Select-Object Name,SamAccountName,LastLogonDate
FSMO e replica (sanity check): netdom query fsmo repadmin /replsummary Assicurati che non ci siano ritardi o errori di replica che possano confondere l’analisi dei tempi.

Analizzare i log di sicurezza sul DC interessato

Una volta identificato il DC “incriminato”, apri il Registro Sicurezza e filtra gli eventi nell’intervallo temporale del lockout.

Evento cardine

4740 – A user account was locked out: contiene TargetUserName e informazioni su chi ha bloccato l’account. Usa l’Event Viewer o PowerShell: $user = '<SamAccountName>' Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-1)} | Where-Object {$_.Message -match "TargetUserName:\s+$user"} | Select TimeCreated,Id,Message

Eventi che spiegano la causa

4771 – Kerberos pre-authentication failed: indica errori Kerberos; fondamentale il campo Client Address (origine) e il Failure Code.
4776 – The DC attempted to validate the credentials for an account (NTLM): controlla Source Workstation e Status/Sub Status.

Mappatura rapida dei codici errore

Contesto	Codice	Significato	Azione suggerita
Kerberos (4771)	0x18	Pre-authentication failed (password errata)	Individua e correggi il client che usa credenziali obsolete
NTLM (4776/4625)	0xC000006A	Wrong password	Rimuovi password salvate in servizi/task/share/app
NTLM	0xC0000234	Account locked out	Evento conseguenza; concentrati sulla sorgente che ha generato errori prima del lock
NTLM	0xC0000071	Password expired	Reimposta password e aggiorna ovunque venga usata
NTLM	0xC0000193	Account expired	Verifica scadenza account o criteri
NTLM	0xC000006F	Invalid logon hours	Controlla orari di accesso dell’account
NTLM	0xC0000070	Invalid workstation	Verifica restrizioni workstation su AD

Kerberos o NTLM? Come interpretarli

Se vedi 4771 con Client Address valorizzato, stai osservando un fallimento Kerberos lato DC; se trovi 4776, la sorgente usa NTLM (tipico di applicazioni o dispositivi legacy). Nei client, l’evento 4625 rivela il processo che ha tentato l’accesso: è essenziale abilitarlo per scovare servizi o task “colpevoli”.

Intervenire sul client responsabile

Una volta identificato il computer di origine, procedi con questa checklist. Esegui i passi finché il contatore di fallimenti non si azzera e il lockout cessa di riproporsi.

Credenziali memorizzate

Credential Manager (Windows): Pannello di Controllo → Gestione credenziali. Rimuovi credenziali Windows e generiche legate a share, siti, applicazioni.
Da prompt: cmdkey /list cmdkey /delete:<target> # es.: cmdkey /delete:TERMSRV/<server>

Servizi e attività pianificate

Servizi: apri services.msc, ordina per Accedi come e verifica se l’account utente viene usato per l’avvio. Se sì, aggiorna la password o, meglio, usa un service account dedicato.
Task Scheduler: in taskschd.msc, filtra per attività che eseguono con l’account interessato. Aggiorna la password e riesegui il task in modo interattivo per confermare.

Share e unità mappate

Controlla unità mappate persistenti, script di logon, collegamenti a UNC e applicazioni che accedono a condivisioni usando credenziali salvate.

Applicazioni e sessioni

Outlook/OneDrive/Teams: se l’account AD è usato anche per SSO, forza un nuovo sign-in.
Sessioni RDP: su server Terminal/Remote Desktop, termina sessioni disconnesse dell’utente e cancella eventuali credenziali memorizzate (TERMSRV in cmdkey).
Browser/Proxy: rimuovi credenziali HTTP/Proxy memorizzate.
Dispositivi mobili (ActiveSync/Company Portal): aggiorna la password o rimuovi/reaggiungi l’account aziendale.
Wi‑Fi o VPN legati a credenziali AD (802.1X/RADIUS, client VPN): aggiorna o rigenera il profilo per evitare tentativi in background.

Abilitare il tracciamento dei fallimenti sul client

Se non è ovvio quale processo stia inviando la password errata, abilita l’audit dei fallimenti di accesso sul client e “segui” l’evento 4625 per identificare Process Name e Logon Type.

# Abilita auditing Logon/Logoff: Failure (via GPO o local policy)
Poi analizza:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-6)} |
  Select TimeCreated, Id, Message

Pulizia dei ticket e riavvio servizi

In caso di Kerberos, ripulisci i ticket: klist purge
Chiudi le sessioni e riesegui il login dopo l’aggiornamento password.

Caso reale risolto

Nel caso riportato dall’autore del thread originale, la causa era un vecchio computer ancora associato all’account che tentava in background l’accesso con la password precedente. Dopo aver rimosso/disaccoppiato tale macchina, i tentativi errati sono cessati e l’account non si è più bloccato.

Approfondimenti e ottimizzazioni

Rivedere la Account‑Lockout Policy

Policy troppo aggressive aumentano i falsi positivi. Valuta, ad esempio:

Account lockout threshold: evitare valori troppo bassi (es. 3); un intervallo 5–10 è più tollerante in ambienti con molte integrazioni.
Account lockout duration: non mettere Forever se non strettamente necessario; un valore ragionevole evita lunghe interruzioni operative.
Reset account lockout counter after: adegua alla realtà del traffico autenticazioni.

Kerberos ticket lifetime e scadenze password

Se registri lockout ripetuti su più account allo stesso orario, verifica ticket lifetime/renewal e la scadenza password di service account usati da script o applicazioni (spesso rinnovati di rado e dimenticati).

Azure AD Password Protection e ambienti ibridi

In presenza di sincronizzazione ibrida, l’uso di Password Protection riduce l’uso di password deboli o riutilizzate. Valuta anche metodi d’accesso moderni (autenticazione a più fattori, passkeys, Windows Hello for Business) per mitigare tentativi ripetuti dovuti a leaking di credenziali.

Quando abilitare il Netlogon logging

In casi ostinati, il Netlogon debug log lato DC/cliente può aiutare a cogliere tentativi NTLM sfuggenti. Ricorda di disabilitarlo al termine dell’analisi per non generare log estremamente verbosi.

Playbook operativo completo

Stabilisci il perimetro: l’utente è bloccato su ogni postazione o solo su alcune? Conferma che il reset password è avvenuto sul PDC Emulator senza errori (netdom query fsmo).
Assicurati di avere auditing adeguato sui DC (vedi sezione dedicata) e forza gpupdate /force.
Individua il DC del lockout con LockoutStatus.exe e annota Bad Pwd Time, Origine e DC.
Correla gli eventi sul DC: trova il 4740 e attorno ad esso i 4771/4776 per IP/host e codice errore.
Raggiungi il client sorgente e rimuovi credenziali memorizzate (Credential Manager, cmdkey), aggiorna servizi e task, verifica share e applicazioni.
Abilita 4625 sul client e osserva quale processo genera nuovi tentativi falliti. Correggi o disinstalla il componente responsabile.
Ripulisci ticket (klist purge), chiudi sessioni RDP e riaccredita l’utente. Monitora per 24–48 ore.
Rivedi le policy: lockout threshold, durata, reset counter; valuta protezioni password e inventaria i service account.
Sanity check AD: repadmin /replsummary, dcdiag /v, time sync coerente (PDC <→> NTP) per evitare anomalie Kerberos.

Strumenti e comandi utili

Scopo	Strumento/Comando	Note operative
Identificare DC e origine lockout	LockoutStatus.exe	Mostra per-DC: Bad Pwd Count/Time, Origine, DC che ha bloccato
Utente e stato lock	Get-ADUser, Search-ADAccount	Richiede RSAT/Modulo ActiveDirectory
Replica/ruoli FSMO	repadmin, netdom	Controlla salute replica e PDC Emulator
Eventi di sicurezza	Get-WinEvent	Filtra 4740, 4771, 4776 con finestre temporali
Pulizia credenziali	cmdkey, Credential Manager	Elimina credenziali Windows/Generiche
Ticket Kerberos	klist	Pulisce TGT/TGS obsoleti

Esempi di query PowerShell per velocizzare l’analisi

Ricerca rapida di 4740 per utente nelle ultime 48 ore

$user = '&lt;SamAccountName&gt;'
$start = (Get-Date).AddHours(-48)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740; StartTime=$start} |
  Where-Object {$_.Message -match "TargetUserName:\s+$user"} |
  Select-Object TimeCreated, MachineName, Id, Message

Correlare 4740 con 4771/4776 in finestra di ±60 secondi

$user = '<SamAccountName>'
$lookbackHours = 24
$events4740 = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddHours(-$lookbackHours)} |
  Where-Object {$_.Message -match "TargetUserName:\s+$user"}

foreach($e in $events4740){
$t0 = $e.TimeCreated.AddSeconds(-60)
$t1 = $e.TimeCreated.AddSeconds(60)
"----"
$e | Select TimeCreated,Id
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=@(4771,4776); StartTime=$t0; EndTime=$t1} |
Where-Object {$_.Message -match "Account Name:\s+$user"} |
Select TimeCreated, Id, Message
}

Elenco servizi che usano un dato account (su un client)

$acct = 'DOMINIO\utente'
Get-WmiObject Win32Service | Where-Object { $.StartName -eq $acct } |
  Select-Object Name, DisplayName, StartMode, State, PathName

Attività pianificate che eseguono con l’account

$acct = 'DOMINIO\utente'
$tasks = schtasks /Query /V /FO CSV | ConvertFrom-Csv
$tasks | Where-Object { $_."Run As User" -eq $acct } |
  Select-Object TaskName, Status, "Run As User", "Next Run Time"

Diagnosi differenziale: dove guardare in base al Logon Type

Logon Type	Descrizione	Indizio pratico
2 (Interactive)	Accesso locale	Credenziali salvate o app locale
3 (Network)	Accesso a risorse di rete	Share, unità mappate, servizi remoti
4 (Batch)	Attività pianificate	Controlla Task Scheduler
5 (Service)	Servizi Windows	services.msc → Accedi come
7 (Unlock)	Sblocco sessione	Sessione in cache che tenta con password vecchia
10 (RemoteInteractive)	RDP/Terminal	Sessioni disconnesse, credenziali TERMSRV
11 (CachedInteractive)	Accesso con cache credenziali	Laptop offline/ibrido, cambiare password e riaccedere

Buone pratiche per prevenire lockout ricorrenti

Service account separati per servizi/attività; mai usare account utente personali.
Password non scadenti o gestite con Password Vault per service account; documenta dove sono usati.
Riduci la dipendenza da NTLM, preferisci Kerberos; blocca NTLM dove possibile.
Inventario integrazioni: mantieni un elenco di dispositivi/app che autenticano con AD (VPN, Wi‑Fi 802.1X, stampanti, applicazioni).
Policy di lockout equilibrate: soglia e durata commisurate al rischio/operatività.
Monitoraggio proattivo: alert su 4740 e 4625 per reagire prima dell’impatto utente.

Domande frequenti

Perché lo sblocco e il reset password non funzionano?

Perché esiste ancora almeno una sorgente che tenta l’accesso con la vecchia password. Fino a quando non la elimini o la aggiorni, i tentativi errati ripartono e l’account si riblocca.

Devo controllare il PDC Emulator?

È buona prassi perché è spesso coinvolto in password change e account lockout, ma il blocco può essere registrato da qualsiasi DC che riceve i tentativi errati. Usa LockoutStatus.exe per precisione.

La replica può falsare i tempi?

Di solito no per i lockout (replicano rapidamente), ma controlla sempre repadmin /replsummary per escludere ritardi o errori che rendano ambigua la timeline.

Checklist finale di risoluzione

Auditing avanzato attivo sui DC e verificato con auditpol.
DC del lockout identificato e 4740 correlato a 4771/4776.
Client sorgente isolato e bonificato (credential manager, servizi, task, share, app, RDP, device mobili, VPN/Wi‑Fi).
Eventi 4625 sul client analizzati per processo e logon type.
Conferma a posteriori: nessun nuovo bad password e contatori azzerati.
Policy di dominio ribilanciate e service account separati documentati.

Riepilogo della soluzione proposta

Abilita auditing completo sui DC (Account Logon, Logon Events, Account Management; Kerberos/NTLM con fallimenti). Aggiorna e verifica con gpupdate /force e auditpol /get /category:*.
Trova il DC che ha bloccato con LockoutStatus.exe, annotando IP/hostname di origine.
Analizza gli eventi 4740 (lockout), 4771/4776 (errore e sorgente). Presta attenzione a Client Address (Kerberos) e Source Workstation (NTLM) e ai codici 0x18 / 0xC000006A.
Intervieni sul client rimuovendo credenziali obsolete, correggendo servizi/task/app. Se necessario, abilita 4625 per scoprire il processo responsabile.
Conferma: il caso reale risolto era dovuto a un vecchio computer ancora associato all’account; rimosso quello, nessun lockout successivo.

In sintesi: un account Active Directory che si riblocca subito dopo lo sblocco non è un problema “del dominio”, bensì un effetto collaterale di un client o processo che insiste con la password precedente. Con auditing mirato, correlazione degli eventi giusti e una checklist sistematica sul client, la risoluzione è rapida e ripetibile.

Metti in pratica quanto sopra e trasforma un incidente ricorrente in un’operazione standardizzata di pochi minuti.