¿Qué está causando que mi controlador de dominio registre docenas de intentos de autenticación exitosos por segundo?

Tenemos un dominio con aproximadamente 15 servidores y aproximadamente 30 estaciones de trabajo. Los servidores son principalmente 2008r2 y las estaciones de trabajo son principalmente Windows 7. Los dos DC son 2012r2. Cada pocas semanas, una de nuestras cuentas de administrador se bloquea. Estoy tratando de reducir la causa y he llegado a un callejón sin salida.

Esto es lo que tengo.

El registro de eventos en el PDC muestra el evento 4776 - éxito de la auditoría:

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

Todo por el mismo nombre de usuario y recurrente varias veces por segundo.

Según los identificadores de eventos, estos son inicios de sesión NTLM en lugar de Kerberos. Aunque el tipo de autenticación utilizado es menos preocupante para mí que la cantidad de corte. Esto sucede varias veces por segundo y se repite cada par de segundos hasta el infinito, todas las horas, día, noche o fin de semana.

El registro de eventos también muestra el evento de éxito de auditoría ID 4624 (inicio de sesión) y 4634 (cierre de sesión) para este nombre de usuario, pero como en el evento anterior, el campo "estación de trabajo" está vacío.

Permití el registro detallado de netlogon y el netlogon.log muestra

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

Y así sucesivamente y así sucesivamente. La fuente aparente de estos inicios de sesión (a través de XYZ) puede incluir estaciones de trabajo y servidores de toda la red.

Claramente esto parece una automatización o script. Como los inicios de sesión son generalmente exitosos, no creo que sea un intento de intrusión. Sin embargo, algunos de los inicios de sesión fallan de vez en cuando, pero no he identificado ningún patrón para la falla y ocurren con tan poca frecuencia que (la mayoría de los días) no bloquean la cuenta. El código de falla cuando hay uno suele ser 0xc0000022 (acceso denegado)

Deshabilité y desinstalé nuestro agente de monitoreo remoto (actualmente Kaseya, pero finalmente nos mudamos a LabTech) desde uno de los servidores, pero aún vi nuevos eventos que se originan en ese servidor, por lo que esto descarta las tareas de automatización. También revisé el programador de tareas en un par de servidores y no encontré nada fuera de lo común. He verificado los servicios para verificar las cuentas de inicio de sesión y esta cuenta no se utiliza en ningún servicio.

Ejecuté Netstat durante un buen tiempo y vi principalmente conexiones al PDC desde "Sistema" y "Proceso inactivo del sistema". Vi conexiones ocasionales desde spoolsrv y lsass e ismserv (el servidor en el que estoy probando es un servidor Citrix XenApp, pero otros servidores "fuente" no están en la granja XenApp, y por supuesto las estaciones de trabajo "fuente" tampoco lo están). Detuve el servicio de cola de impresión solo para probar y no tuvo ningún impacto en los eventos de inicio de sesión.

Trabajo en un MSP y esta es nuestra cuenta de administrador dom técnico principal, por lo que es de alta prioridad que funcione y sea seguro. La última idea que me queda es cambiar la contraseña y ver qué se rompe, pero sin saber para qué se usa la cuenta, esto podría tener consecuencias potencialmente catastróficas. Sin embargo, mi sospecha es que esto podría ser un AD mal configurado.

¿Alguien ha experimentado algo como esto antes y ha podido identificar la fuente?

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

— Thomas
fuente

Para cualquiera que tenga curiosidad por la gran cantidad de servidores, tienen los servidores XenApp con SharePoint de cara pública para una fuerza de trabajo altamente móvil con BYOD. También tenían un personal de TI anterior que se excedió un poco en su infraestructura para el tamaño de su negocio. Desde que nos contrataron, hemos estado tratando de reducirlos un poco a algo más apropiado para sus necesidades.

— Thomas

Algo que podría intentar es instalar Microsoft Network Monitor en uno de los servidores, iniciar una captura, esperar una entrada del servidor para iniciar sesión en el registro de netlogon y luego mirar la captura y ver si puede encontrar la conversación en Network Monitor . Network Monitor debería mostrarle el proceso responsable de la conversación. Si eso no lo reduce lo suficiente, puede usar Network Monitor junto con Process Monitor para identificar el proceso responsable.

— joeqwerty

Microsoft Network Monitor está en desuso y es reemplazado por Microsoft Message Analyzer. El mismo trato que Wireshark. Ejecuté una captura de paquetes y no encontré absolutamente nada útil. Los únicos eventos que se correlacionan estrechamente con los eventos de NetLogon son las conexiones WMI y RPC.

— Thomas

Correcto, NetMon está en desuso pero sigue siendo una buena herramienta. Si no ha usado Message Analyzer antes, puede ser un poco abrumador. NetMon es bastante simple e intuitivo. Usualmente lo uso antes que cualquier otra cosa. - En cuanto a su captura, el tráfico RPC podría contener algunas pistas.

— joeqwerty

Si nada. Hay un MSRPC Bind enviado y Ack recibido para construir una sesión encriptada seguido de un paquete NRPC enviado y recibido que contiene una Solicitud y Respuesta NetrLogonSamLogonEx, los últimos dos encriptados. El proceso de llamada en la computadora fuente es LSASS, que ejecuta el servicio Netlogon. No hay detalles útiles en absoluto en los datos del paquete del tráfico Bind y, por supuesto, los paquetes cifrados no me sirven de nada.

— Thomas

Recomiendo habilitar aún más la auditoría NTLM en sus DC. Con la Política de controlador de dominio predeterminada, habilite la siguiente configuración de política:

Seguridad de red: restringir NTLM: auditar tráfico entrante = habilitar la auditoría para todas las cuentas Seguridad de red: restringir NTLM: auditar autenticación NTLM en este dominio = habilitar todo Seguridad de red: restringir NTLM: tráfico NTLM saliente a servidores remotos = auditar todo

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

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

Una vez habilitado, navegue en su visor de eventos a: Registros de aplicaciones y servicios> Microsoft> Windows> NTLM> Operativo

Habrá eventos con marcas de tiempo que coincidan con sus marcas de tiempo de eventos de netlogon. Este registro revelará el nombre real de la estación de trabajo.

Y específicamente para ayudarlo a identificar aún más la fuente, el nombre de canal seguro en este registro ayudaría a reducir el origen del proceso.

— Lúpulo casero
fuente

Gracias por la respuesta. Lamentablemente, este cliente en particular ya no es un cliente nuestro, por lo que no puedo probar sus instrucciones. Seguí adelante y acepté tu respuesta, porque mi propia comprensión de AD me dice que debería darme los detalles que necesito. (No estoy seguro de por qué no pensé en ajustar la política de auditoría, pero no te atreves a sugerirlo).

— Thomas