Esaminare gli account bloccati
Talvolta può capitare che gli account di Active Directory vengano bloccati a causa di tentativi di accesso con password errata. Spesso questo problema può accadere se l’utente dopo aver cambiato la password non ha aggiornato le credenziali sui vari dispositivi o applicativi che utilizza. Molto spesso il problema può essere legato alle seguenti cause che generano tentativi di accesso ripetuti con credenziali errate:
- Password di rete salvate relative all’account
- Operazioni pianificate eseguite con le credenziali dell’account
- Servizi in esecuzione con le credenziali dell’account
- Applicazioni che utilizzano al loro interno con le credenziali dell’account
- Utilizzo delle credenziali dell’account per connettersi a reti wifi
- Utilizzo delle credenziali dell’account per connettersi via Remote Desktop
- Accessi eseguiti da smartphone, tablet che fanno uso delle credenziali dell’account per leggere la posta, connettersi a reti wifi o aprire VPN
- Il virus Conficker può causare tentativi di attacchi a forza bruta sui membri del gruppo built-in Administrators nel dominio.
- Accessi eseguiti da più client con versioni di OS differenti in cui può accadere che le versioni legacy dei client non riescano a rilevare correttamente il cambio di password.
In infrastrutture con Active Directory è possibile analizzare gli eventi di sicurezza del Domain Controller e in particolare del PDC emulator per rilevare i tentativi di accesso falliti da parte di un utente e risalire al computer che genere il problema.
Per eseguire questo tipo di analisi è possibile verificare gli eventi di sicurezza con ID 4740 sul domain controller col ruolo di PDC, infatti a partire da Windows Server 2008 sul PDC viene registrato un evento con ID 4740 ogni qualvolta un account viene bloccato. In una foresta AD con livello funzionale 2008 r2 per far sì che gli eventi di sicurezza con ID 4740 vengano registrati occorre abilitare sul DC la Group Policy locale Computer Configuration\Windows Settings\Security Settings\Advanced Audit Configuration\Logon/Logoff\Audit Account Lockout attivando l’audit per Success e il Failure:
Per informazioni riguardo al supporto di questa GPO nelle varie versioni del sistema operativo si veda Which Versions of Windows Support Advanced Audit Policy Configuration?.
Per esportare gli eventi 4740 è possibile utilizzare i seguenti comandi (a riguardo si vedano i suggerimenti nel post Getting event log contents by email on an event log trigger):
del C:\SecEvt4740.txt
wevtutil qe Security “/q:*[System [(EventID=4740)]]” /f:text /rd:true /c:1 > C:\SecEvt4740.txt
Per identificare il DC col ruolo fsmo di PDC è possibile utilizzare il seguente comando (a riguardo si veda Identify the PDC emulator):
dsquery server -hasfsmo pdc
Ovviamente è anche possibile utilizzare PowerShell tramite i cmdlet Get-EventLog e Get-WinEvent introdotto in PowerShell 2.0 (a riguardo si veda il post Hey, Scripting Guy! How Can I Read from Windows Event Logs with Windows PowerShell 2.0?) come descritto nel post Tracing the Source of Account Lockouts in cui viene descritto uno script in cui viene richiesto un account da controllare e viene eseguita sul PDC la ricerca degli eventi di sicurezza con ID 4740:
# Richiesta Utente
$User = Read-Host -Prompt “Please enter a user name”
# Ricerca PDC
$PDC = Get-ADDomainController -Discover -Service PrimaryDC
# Ricerca eventi di lockout relativi all’utente verificatisi nell’ultima ora
Get-WinEvent -ComputerName $PDC -Logname Security -FilterXPath “*[System[EventID=4740 and TimeCreated[timediff(@SystemTime) <= 3600000]] and EventData[Data[@Name=’TargetUserName’]=’$User’]]” | Select-Object TimeCreated,@{Name=’User Name’;Expression={$_.Properties[0].Value}},@{Name=’Source Host’;Expression={$_.Properties[1].Value}}
Per un altro esempio si veda il post Use PowerShell to Find the Location of a Locked-Out User e il relativo script Get-LockedOutLocation.
In alternativa è possibile abilitare il log del servizio Net Logon (a riguardo si veda la KB 109626 Enabling debug logging for the Net Logon service) e consultare poi il file %windir%\debug\netlogon.log ad esempio tramite i comandi (per accedere al file col servizio NetLogon attivo occorre prima farne una copia):
type netlogon.log |find /i “0xC000006A” >badpassword.txt
type netlogon.log |find /i “0xC0000234“ >lockedout.txt
In Windows 8 e Windows Server 2012 nel file netlogon.log viene registrato anche l’ID del processo dell’applicazione che ha causato il lockout rendendo più semplice l’analisi.
Per ulteriori informazioni e suggerimenti su come eseguire il troubleshooting del lockup dgli account si veda anche il post Troubleshooting account lockout the PSS way.
Microsoft ha reso disponibili per Windows Server 2003 e Windows XP gli Account Lockout and Management Tools e l’Account Lockout Status (LockoutStatus.exe) per semplificare il processo di troubleshotting.
Un altro tool interessante è il Netwrix Account Lockout Examiner che permette un’analisi granulare con una GUI semplice del blocco degli account, del tool esiste una versione freeware ed una versione a pagamento che permette l’implementazione di una struttura di helpdesk per supportare gli utenti in situazioni di lockout per la comparazione delle funzionalità si veda Netwrix Account Lockout Examiner – Freeware and Enterprise Editions.
Ciao Ermanno, articolo interessante.Avevo proprio questo tipo di problema sul mio account di dominio che, nel corso dell’anno, risultava bloccato al mattino…pensavo appunto a qualche script con password vecchie ma non ero riuscito a identificare da dove partisse il problema…devo dire che e’ un po di tempo che non ricapita..in ogni caso dal DC 2008R2 (livello funzionalita’ foresta 2008 R2 e ruolo fsmo) nei criteri di gruppo LOCALI ho impostato il “controllo blocco account” come da articolo.Ho volutamente bloccato l’account facendo diversi tentativi di login falliti…ma negli eventi del DC non registra nessun evento 4740 (trovo solo eventi 4624,4625 per password scadute o errate,4648)…
Interessante: c’e’ anche l’evento 4719 ,di stamattina, che riporto:
“Il criterio di controllo del sistema è cambiato.
Soggetto:
ID sicurezza: SYSTEM
Nome account: SRV2008$
Dominio account: CSS
ID accesso: 0x3e7
Modifica criterio controllo:
Categoria: Accesso/fine sess.
Sottocategoria: Blocco account
GUID sottocategoria: {0cce9217-69ae-11d9-bed3-505054503030}
Modifiche: Aggiunta completata, Errore aggiunto ”
Hai suggerimenti in merito? o sto sbagliando qualcosa? Grazie
Ciao Salvatore,
dopo aver impostato la policy hai eseguito sul DC un gpupdate /force ed eventualmente hai provato a riavviare il sistema per assicurarti che la GPO sia stata presa in carico?
Provo a investigare sull’evento che hai riportato
Si,il force l’ho fatto…da un gpresult vedo la policy…un riavvio del server non posso, essendo anche il file server aziendale…Ho riprovato,ma nulla.Ciao
L’evento 4719 viene registrato quando quando una policy di auditing viene modificata vedi questo post e i relativi commenti:
http://blogs.msdn.com/b/ericfitz/archive/2010/07/16/auditing-changes-to-audit-policy.aspx
vedi anche
https://technet.microsoft.com/it-it/library/Dd772736(v=WS.10).aspx
Questo evento potrebbe essere però il sintomo del fatto che c’è qualche problema con la configurazione delle policy di auditing, vedi questa discussione
https://social.technet.microsoft.com/Forums/windowsserver/en-US/ebcd93c6-4803-4770-a680-d58cbaa13b33/how-to-stop-event-4719
Per quanto riguarda la mancata registrazione dell’evento 4740 vedi questa discussione:
https://social.technet.microsoft.com/Forums/en-US/fabef911-0baf-4407-8ab9-2afc7b0e9eb8/dcs-not-auditing-locked-account-event-id-4740?forum=winserversecurity
I have resolved this myself after digging a little further:
My environment is 2008r2 and above so the old legacy audit policies were doing peculiar things like not auditing. so in the Domain Controller GP I set these back to ‘not defined’:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy
then started configuring Advanced Audit Policies instead:
Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration
also ensure:
Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. is set to enabled
these then apply correctly as displayed by the command auditpol /get /category:*
After testing and locking and account I’m not getting correct auditing, and seeing 4740 events.
Resources used to assist in my resolution:
http://technet.microsoft.com/en-us/library/ff182311(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/dd408940(v=ws.10).aspx