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.

http://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

image

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.

image

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

http://technet.microsoft.com/en-us/library/cc738772(WS.10).aspx

Maintaining and Monitoring Account Lockout

http://technet.microsoft.com/en-us/library/cc776964(WS.10).aspx