Minha conta bloqueou mais uma vez!
Por Eduardo Tavares de Almeida
Um tipo de chamado muito frequente no suporte são os chamados de bloqueio de contas. Muitas vezes o administrador de domínio habilita um número muito baixo de tentativas e podem ocorrer falsos bloqueios.
Outras vezes tem alguma aplicação que pode ter a senha em cache como o Internet Explorer, updates de alguns softwares que salvam a senha do proxy, serviços, mapeamentos, tarefas agendadas entre outros.
O blog abaixo explica como habilitar GPO de auditoria e descobrir qual a origem das autenticações com senha errada e é a partir dele que irei continuar.
https://blogs.technet.com/b/latam/archive/2006/03/17/423428.aspx
No meu exemplo vou compartilhar um caso em que descobrimos que as autenticações iniciavam do próprio DC, mas como vemos logo mais, era registrado no arquivo de netlogon.log como Network logon.
-------------------
03/22 12:22:33 [LOGON] CONTOSO: SamLogon: Network logon of CONTOSO\johnb from DC01 (via DC01) Returns 0xC000006A
03/22 12:22:33 [LOGON] CONTOSO: SamLogon: Network logon of CONTOSO\johnb from DC01 (via DC01) Entered
03/22 12:22:33 [LOGON] CONTOSO: SamLogon: Network logon of CONTOSO\johnb from DC01 (via DC01) Returns 0xC0000234
-------------------
Verificamos o servidor e a única aplicação suspeita era uma aplicação que permite execução de tarefas remotamente, mas o cliente não podia desabilitar e queria provas de que era ela.
Como o processo poderia ser iniciado e parado com diferentes PIDs, para poder cruzar essa informação, deixamos um Process Monitor executando com o comando abaixo. Esse comando mantem o process monitor usando um circular logging e apagando os mais antigos automaticamente.
start C:\procmon.exe /quiet /minimized /backingfile C:\temp\ProcessMon.pml /nofilter
Assim que o evento de bloqueio de conta ocorresse, o comando abaixo iria parar a coleta.
C:\procmon.exe /terminate
Conseguimos coletar o evento com as tentativas e assim verificar Logon Process, era chamado por uma dll da Microsoft que e pode ser utilizado por terceiro. Essa informação não ajudou muito. A informação mais importante era o “Caller Process ID”.
Logon Failure:
Reason: Unknown user name or bad password
User Name: johnb
Domain: CORPORATIVO
Logon Type: 3
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: DC01
Caller User Name: DC01$
Caller Domain: CONTOSO
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 5540
Transited Services: -
Source Network Address: -
Source Port: -
O comando tasklist /svc poderia mostrar a aplicação, mas e se esse processo só tentou se autenticar e fechou, bem ai nesse caso o Process Monitor foi a salvação.
No menu Tools, temos o Process Tree
O Process Tree foi fundamental, já que mostra todos os processos, PIDs e quando ele foi iniciado. Com isso vendo evento 529 que mostrava o Process Id 5540 e vendo a Process Tree foi possível confirmar que a aplicação que suspeitamos no inicio, era realmente a culpada.
Outras vezes temos que pegar mais logs com Network Monitor, por exemplo, e sempre que possível simultaneamente. Cruzando as informações e seguindo o rastro é possível dizer o causador.
Esses eventos são o que procuramos nos logs de segurança. A primeira coluna é para Windows 2003, XP e a segunda para Windows 2008, 7.
Event 644 / 4740 (Account Lockout),
Event 529 / 4625 (Unknown Username or Bad Password),
Event 675 / 4771 (Kerberos Pre-Authentication Failure),
Event 680 / 4776 (NTLM Authentication Failure)
Nos links abaixo você pode encontrar mais informações sobre troubleshooting e ferramentas.
Account Lockout Tools
https://technet.microsoft.com/en-us/library/cc738772(WS.10).aspx
Maintaining and Monitoring Account Lockout
https://technet.microsoft.com/en-us/library/cc776964(WS.10).aspx