• Soluzioni
    • MSP
    • Rivendita
  • Servizi
    • Tutti i servizi
    • Assistenza gratuita
    • Coaching
    • Knowledge Base
    • Servizi Tecnici
    • Supporto premium
    • Supporto standard
  • Risorse
    • Tutte le risorse
    • Blog
    • Podcast
  • Eventi
  • MSP Hub
  • Partner
  • Vendors
    • Why Achab
    • Portfolio
    • Testimonial
    • Contact us
  • Company
    • Chi siamo
    • Team
    • Vendor
    • Contatti
    • Lavora con noi
    • Sala Stampa
  • Area Partner
  • Soluzioni
    • MSP
    • Rivendita
  • Servizi
    • Tutti i servizi
    • Assistenza gratuita
    • Coaching
    • Knowledge Base
    • Servizi Tecnici
    • Supporto premium
    • Supporto standard
  • Risorse
    • Tutte le risorse
    • Blog
    • Podcast
  • Eventi
  • MSP Hub
  • Partner
  • Vendors
    • Why Achab
    • Portfolio
    • Testimonial
    • Contact us
  • Company
    • Chi siamo
    • Team
    • Vendor
    • Contatti
    • Lavora con noi
    • Sala Stampa
  • Area partner
HomeRisorseArticoliSoluzioni tecnicheUtenti bloccati in Active Directory? Ecco come indagare
Categorie degli articoli
  • Backup, DR e business continuity
  • Business
  • Casi di successo
  • Cybersecurity
  • Email
  • Gestione IT
  • Networking
  • Senza categoria
  • Soluzioni tecniche

Tieniti aggiornato

Inserisci il tuo indirizzo e-mail per restare aggiornato su tutte le nostre iniziative

Nella stessa categoria

26 Gennaio 2023
Ripristinare gli elementi rimossi da OneDrive, Sharepoint e Teams
13 Ottobre 2022
Impossibile aprire file da OneDrive: ecco cosa fare
28 Gennaio 2020
Riabilitare il backup del registro di sistema in Windows 10
New call-to-action
Soluzioni tecniche

Utenti bloccati in Active Directory? Ecco come indagare

05 Novembre 2019

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.

Autore
Furio Borsi
Si appassiona al mondo digitale fin da bambino, con il glorioso Commodore 64, sul quale si diverte a scrivere semplici programmi in Basic e modificare giochi. Nel 1990 riceve in regalo il suo primo PC (i386), seguito un paio d'anni dopo da un i486dx. In questi anni affina le sue attitudini al problem solving, scassando hardware e software e divertendosi a rimetterlo a posto. ;) Diventa così "quello che se ne capisce" per i suoi familiari e amici, arrivando a collaborare con alcuni studi professionali per la gestione del parco macchine e dei server Windows. Finito il liceo, studia DAMS con indirizzo multimediale a Bologna e Imperia. Nel 2002, dopo un anno sabbatico a Londra, lavora come sviluppatore junior in un'azienda che produce software per database territoriali in ambito Pubblica Amministrazione. In questo periodo si avvicina con passione a problematiche sistemistiche e di network management su reti estese. Nel 2007 entra a far parte dello staff di Achab, per cui si occupa di formazione e supporto, in particolare riguardo a Kaseya, e gestione del parco macchine e della rete.
Condividi l’articolo

Tag

Achab, Active Directory, lockout account, troubleshooting active directory, utenti bloccati, utenti bloccati ad

Commenti (0)
Login
guest
guest
0 Commenti
Inline Feedbacks
Guarda tutti i commenti

Nella stessa categoria

26 Gennaio 2023
Ripristinare gli elementi rimossi da OneDrive, Sharepoint e Teams
13 Ottobre 2022
Impossibile aprire file da OneDrive: ecco cosa fare
28 Gennaio 2020
Riabilitare il backup del registro di sistema in Windows 10

Tieniti aggiornato

Inserisci il tuo indirizzo e-mail per restare aggiornato su tutte le nostre iniziative

  • Privacy Policy
  • Contatti
  • Area Partner
  • Reclami
  • Foreign Partners
  • Impostazioni cookie
Tieniti aggiornato

Inserisci il tuo indirizzo email per ricevere aggiornamenti sul mondo delle soluzioni Achab.

Copyright © Achab S.p.A. unipersonale Società soggetta a direzione e coordinamento da parte di Vortex Beteiligungs GmbH
Viale Monte Nero 4, 20135 Milano - Tel. +39 02 54108204
P.IVA e C.F. 11270660159 - Cap. Soc. € 60.000,00 - Registro Imprese Milano - REA 1453036 - PEC: achab@legalmail.it

wpDiscuz