O que está fazendo com que meu controlador de domínio registre dezenas de tentativas de autenticação bem-sucedidas por segundo?

Temos um domínio com cerca de 15 servidores e cerca de 30 estações de trabalho. Servidores são principalmente 2008r2 e estações de trabalho são principalmente Windows 7. Os dois DCs são 2012r2. A cada poucas semanas, uma de nossas contas de administrador é bloqueada. Estou tentando diminuir a causa e cheguei a um beco sem saída.

Aqui está o que eu tenho.

O log de eventos no PDC mostra o evento 4776 - êxito da auditoria:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Tudo com o mesmo nome de usuário e recorrente várias vezes por segundo.

Com base nas identificações de evento, esses são logons NTLM em vez de Kerberos. Embora o tipo de autenticação usada seja menos preocupante para mim do que a quantidade de cisalhamento. Isso acontece várias vezes por segundo e repete a cada par de segundos ad infinitum, todas as horas dia ou noite ou fim de semana.

O log de eventos também mostra os eventos de sucesso de auditoria ID 4624 (logon) e 4634 (logoff) para esse nome de usuário, mas, como no evento acima, o campo "estação de trabalho" está vazio.

Ativei o log detalhado do log de rede e o netlogon.log mostra

02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from  (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from  (via server4) Returns 0x0

E assim por diante. A fonte aparente desses logons (via XYZ) pode incluir estações de trabalho e servidores de toda a rede.

Claramente, isso se parece com uma automação ou script. Como os logins geralmente têm êxito, não acredito que seja uma tentativa de invasão. Alguns logins, no entanto, falham de tempos em tempos, mas eu não identifiquei nenhum padrão para a falha e eles ocorrem com tão pouca frequência que (na maioria dos dias) eles não bloqueiam a conta. O código de falha quando existe um geralmente é 0xc0000022 (acesso negado)

Desabilitei e desinstalei nosso agente de monitoramento remoto (atualmente Kaseya, mas finalmente estamos mudando para o LabTech) de um dos servidores, mas ainda vi novos eventos originados nesse servidor, portanto, isso exclui as tarefas de automação. Também verifiquei o agendador de tarefas em alguns servidores e não encontrei nada fora do comum. Eu verifiquei os serviços para verificar as contas de logon e esta conta não é usada em nenhum serviço.

Corri o Netstat por um bom tempo e vi principalmente conexões com o PDC a partir de "Sistema" e "Sistema ocioso do sistema". Vi conexões ocasionais de spoolsrv, lsass e ismserv (o servidor em que estou testando é um servidor Citrix XenApp, mas outros servidores "de origem" não estão no farm do XenApp e, é claro, as estações de trabalho "de origem" também não. Parei o serviço de spooler de impressão apenas para testar e não teve nenhum impacto nos eventos de login.

Eu trabalho em um MSP e esta é a nossa conta principal de administrador de domínio técnico, por isso é de alta prioridade que esteja funcionando e seja seguro. A última idéia que me resta é alterar a senha e ver o que quebra, mas sem saber para que a conta está sendo usada, isso pode ter consequências potencialmente catastróficas. No entanto, minha suspeita é que isso possa ser apenas um AD mal configurado.

Alguém já experimentou algo assim antes e foi capaz de identificar a fonte?

active-directory windows-server-2008-r2 windows-server-2012-r2

— Thomas
fonte

Para qualquer pessoa curiosa sobre o alto número de servidores, eles têm os servidores XenApp voltados para o SharePoint publicamente para uma força de trabalho altamente móvel com BYOD. Eles também tinham uma equipe de TI anterior que exagerou um pouco em sua infraestrutura para o tamanho de seus negócios. Desde que eles nos contrataram, tentamos reduzi-los um pouco a algo mais apropriado às suas necessidades.

— Thomas

Algo que você pode tentar é instalar o Microsoft Network Monitor em um dos servidores, iniciar uma captura, aguardar que uma entrada do servidor seja registrada no log de logon de rede e, em seguida, observe a captura e veja se consegue encontrar a conversa no Monitor de Rede . O Monitor de rede deve mostrar o processo responsável pela conversa. Se isso não o restringir o suficiente, você pode usar o Network Monitor em conjunto com o Process Monitor para identificar o processo responsável.

— Joeqwerty

O Microsoft Network Monitor foi descontinuado e substituído pelo Microsoft Message Analyzer. O mesmo negócio que o Wireshark. Fiz uma captura de pacotes e não achei absolutamente nada útil. Os únicos eventos que se correlacionam estreitamente com os eventos do NetLogon são as conexões WMI e RPC.

— Thomas

Certo, o NetMon está obsoleto, mas ainda é uma boa ferramenta. Se você não usou o Message Analyzer antes, pode ser um pouco complicado. O NetMon é bastante simples e intuitivo. Eu costumo usá-lo antes de mais nada. - Quanto à sua captura, o tráfego RPC pode conter algumas pistas.

— precisa saber é o seguinte

Sim, nada. Há uma ligação MSRPC enviada e a Ack recebida para criar uma sessão criptografada seguida por um pacote NRPC enviado e recebido contendo uma solicitação e resposta NetrLogonSamLogonEx, sendo as duas últimas criptografadas. O processo de chamada no computador de origem é LSASS, que executa o serviço Netlogon. Não há detalhes úteis nos dados dos pacotes do tráfego Bind e, é claro, os pacotes criptografados são inúteis para mim.

— Thomas

Eu recomendo ativar ainda mais a auditoria NTLM nos seus DCs. Usando a Diretiva de Controlador de Domínio Padrão, ative as seguintes configurações de diretiva:

Segurança de rede: Restringir NTLM: Auditar tráfego de entrada = Ativar auditoria para todas as contas Segurança de rede: Restringir NTLM: Auditar autenticação NTLM neste domínio = Ativar tudo Segurança de rede: Restringir NTLM: tráfego NTLM de saída para servidores remotos = Auditar tudo

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/pt-br/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Depois de ativado, navegue no visualizador de eventos para: Logs de aplicativos e serviços> Microsoft> Windows> NTLM> Operacional

Haverá eventos com registros de data e hora correspondentes aos registros de data e hora do evento netlogon. Este log revelará o nome real da estação de trabalho.

E, especificamente, para ajudá-lo a identificar ainda mais a fonte, o Nome do canal seguro neste log ajudaria a diminuir a origem do processo.

— Lúpulo Homebrew
fonte

Obrigado pela resposta. Infelizmente, esse cliente em particular não é mais um cliente nosso, portanto, não posso tentar suas instruções. Fui em frente e aceitei sua resposta, pois minha própria compreensão do AD me diz que isso deve me dar os detalhes que preciso. (Não sei por que eu não pense em ajustar a política de auditoria, mas você rocha para sugerir isso.)

— Thomas