Ti capita mai che un tuo cliente ti chiami perché ha l’utente bloccato in Active Directory?
Immagino che a volte tu riesca subito a capire dove risiede il problema, altre volte il troubleshooting risulta più complesso perché gli utenti sembrano bloccati senza un apparente motivo.
Le cause di un blocco utente possono essere diverse, dal malware che conduce un attacco brute force al semplice cambiamento della password dell'utente in AD, per cui eventuali utilizzi precedenti di quell'account per far girare servizi o processi causano un fallimento di autenticazione.
Queste situazioni sono piuttosto scomode da gestire perché comportano blocchi sistematici e la semplice operazione di unlock dell’account viene resa inutile dai successivi fallimenti.
Come fare a capire cosa è successo?
Il primo passo, in questi casi, è l’analisi del log eventi del DC, che registra un evento
Security – 4740 – Success Audit
in caso di lock dell’account. Poco prima di questo evento vedremo diversi eventi
Security – 4625 – Failure Audit
Security – 4771 – Failure Audit
a seconda della tipologia di login eseguito, che registrano il tentativo di logon fallito.
Il numero di eventi di questo tipo che causano il lock dell’account è di default 5. Va da sé che aumentare questo limite non è consigliabile, anche perché normalmente non risolve la problematica.
Andando ad analizzare gli eventi di failed logon, ci troviamo spesso in una situazione paradossale.
Nella descrizione dell'evento troviamo l'account che ha fallito l'autenticazione, ma molto spesso (anzi, per esperienza oserei dire quasi sempre) troviamo vuoto il campo che identifica la macchina colpevole del tentativo.
Come analizzare la situazione?
Ci viene in aiuto l'utility nltest.exe, ossia Logon Server Test Utility, che permette di eseguire diversi test per identificare problematiche a livello di domain controller. L'utility viene infatti installata insieme al ruolo AD.
Utilizzando da un prompt amministrativo sul DC il comando
nltest /dbflag:0x2080FFFF
eventualmente seguito dal riavvio del servizio netlogon, è possibile abilitare il logging verboso di netlogon.exe.
Al prossimo lock di un utente, apriamo quindi il file:
%systemroot%debugnetlogon.log
Il log presenta diverse informazioni sui tentativi di accesso, identificati da codici di errore specifici. Riporto qui una lista di stati significativi:
0xC0000064 STATUS_NO_SUCH_USER
0xC000006A STATUS_WRONG_PASSWORD
0xC000006F STATUS_INVALID_LOGON_HOURS
0xC0000071 STATUS_PASSWORD_EXPIRED
0xC0000072 STATUS_ACCOUNT_DISABLED
0xC0000193 STATUS_ACCOUNT_EXPIRED
0xC0000234 STATUS_ACCOUNT_LOCKED_OUT
0xC0000224 STATUS_PASSWORD_MUST_CHANGE
Possiamo quindi cercare le occorrenze del nostro account lockato
28/10 16:43:12 [LOGON] ACHABDOM: SamLogon: Network logon of achabdommyadmin from (via nbachabtest) Entered
28/10 16:43:12 [LOGON] ACHABDOM: SamLogon: Network logon of achabdommyadmin from (via nbachabtest) Returns 0xC000006A
Da queste due righe di log riceviamo almeno due informazioni importanti:
- il codice di errore 0xC000006A, che – confrontato con la tabellina qui sopra – ci conferma che si tratta di un tentativo di accesso con password errata;
- la macchina dalla quale il tentativo è stato eseguito (nbachabtest).
A questo punto possiamo identificare il device in rete e verificare se ci sono processi che eseguono tentativi di accesso. Le cause più diffuse sono:
- sessioni RDP abbandonate senza logout reale (sui server);
- servizi di Windows associati ad un utente specifico per l'esecuzione;
- operazioni pianificate eseguite con password cablata;
- unità di rete;
- applicazioni (ad esempio agent RMM) o script che possano eseguire operazioni con credenziali diverse da Local System;
- malware.
Da ultimo, la registrazione verbosa di netlogon.log è un processo che utilizza risorse e potrebbe creare nel tempo un file risultante molto pesante, quindi si consiglia di disabilitarla e abilitarla solo in caso di necessità.
Per disabilitarla è sufficiente aprire di nuovo un prompt amministrativo ed eseguire:
nltest /dbflag:0x0
eventualmente riavviando il servizio netlogon.
