Conta LDAP bloqueada esporadicamente após a alteração da senha - Localizando a origem das tentativas inválidas

Question

Em uma pequena rede de máquinas (< 1000), temos um usuário cuja conta está sendo bloqueada após um intervalo indeterminado após uma alteração de senha.

Estamos com sérias dificuldades em encontrar a origem das tentativas de logon inválidas e eu agradeceria muito se alguns de vocês pudessem passar pelo processo de raciocínio e pelas verificações que você faria para corrigir o problema.

Tudo o que sei com certeza é que a conta é bloqueada várias vezes (5+) por dia, não posso nem ter certeza de que é devido a tentativas de login malsucedidas, pois não há registro de falha até que a conta seja bloqueada.

Até agora eu tentei;

• Registrando a conta de tudo o que podemos pensar e voltar com a nova senha
• Analisando a caixa do usuário para qualquer software não padrão que possa realizar uma pesquisa LDAP
• A verificação de todos os serviços instalados em nossas caixas de produção para verificar nenhum deles está tentando ser executada na conta
• Alterando o usuário de volta para a senha antiga (o problema persiste, portanto, talvez a alteração de senha seja um arenque vermelho)
• Wireshark em uma caixa onde é executada muita autenticação LDAP - somente rejeita ocorrem depois que a conta já está bloqueada
• Limpando o cache de credenciais em - Painel de controle - > Contas de usuários - > Avançado
• Olhando para o local

Não sei o que tentar. Fico feliz em tentar qualquer sugestão que você tenha para diagnosticar o problema. Acho que minha pergunta se resume a um simples pedido;

Eu preciso de uma técnica para obter a origem (Application / Host) das tentativas de login inválidas que estão causando o bloqueio da conta.

Não tenho certeza se isso é possível, mas suspeito que deve haver mais coisas que eu possa tentar.

Muito obrigado,

CityView

EDITAR - RESOLVIDO

TLDR - O RSS Feed Reader configurado no Client Box com credenciais antigas causou o Continuous Build Software (que o leitor tentou logar) para bloquear a conta, pois fez uma tentativa de login com falha a cada 5 minutos .

Estratégia

Eu olhei os logs para as principais peças de infraestrutura que temos, procurando o nome de usuário em questão. Ficou claro que houve muitas tentativas fracassadas para o Continuous Build Software. Foi então um caso de realizar uma captura wireshark entre as duas caixas para tentar descobrir de onde vêm as solicitações. Nós matamos processos até encontrarmos o caminho certo.

Obrigado a todos por sua ajuda, parece tão fácil agora que está ordenado!

    

Answer 1

Infelizmente, há várias circunstâncias em que o log de eventos de segurança terá o ID de evento 680 e o nome da estação de trabalho estará em branco.

680,AUDIT FAILURE,Security,Fri Feb 25 14:29:37 2011,NT AUTHORITY\SYSTEM,Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0    Logon account:  jdoe    Source Workstation:     Error Code: 0xC0000064    

Uma maneira de expor mais informações é habilitar o log detalhado do netlogon. Em um controlador de domínio (s) onde os eventos são registrados, crie o seguinte valor do Registro:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"DBFlag"=dword:24401F04

Reinicie o serviço netlogon para que isso entre em vigor. As informações detalhadas serão registradas em:% systemroot% \ debug \ netlogon.log e netlogon.bak. O arquivo de log passa e é renomeado para .bak com cerca de 19 MB. Após um dos eventos, faça uma cópia dos dois arquivos do dc em que o evento ocorreu e abra-os em um editor de texto e procure o nome do usuário.

Se você tiver sorte, terá algo assim:

02/12 10:54:39 [LOGON] ACMI: SamLogon: Transitive Network logon of (null)\jdoe from  (via EXCHANGE2) Entered
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: jdoe: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: Username jdoe is hq.acme.com\jdoe (found On GC)

Observe que, se você tiver vários controladores de domínio, quando reiniciar o serviço netlogon em um, a máquina que está fazendo as tentativas de logon poderá alternar para outro dc, portanto, esteja preparado para habilitar isso em mais de um DC. Se você tiver um ambiente de vários domínios com domínios filho, talvez seja necessário rastrear isso de um domínio filho para o domínio raiz e outro domínio filho antes que a máquina incorreta seja localizada. A máquina ofensora pode ser qualquer coisa, não precisa necessariamente ser uma estação de trabalho Windows. Pode ser uma impressora / copiadora de rede multifuncional ou um cliente de email que esteja tentando uma conexão SMTP autenticada com seu servidor Exchange.

    

Answer 2

FWIW (talvez não muito - apenas lançando coisas para você), quando tivemos um problema parecido com um Domínio do AD, finalmente usamos este conjunto de ferramentas é rastrear o perpetrador.

Em um caso, acabou sendo uma estação de trabalho de sala de treinamento em outro prédio que eles tinham acessado, mas não semanas atrás - e que não era usado desde então.

    

Answer 3

Parece que você já tentou quase tudo. Eu teria pensado que o log de segurança teria indicado a estação de trabalho que tentou se conectar.

Vi isso com alguns usuários com máquinas virtuais que mapearam uma unidade no servidor físico e, em seguida, a VM usaria credenciais antigas e bloquearia a conta de forma divertida. Como a VM havia sido desativada por duas alterações de senha, os usuários não pensaram em verificar. No entanto, o log de segurança nos deu o nome do computador.

Interessado em ouvir uma solução aqui