Tenemos una cuenta de dominio que se está bloqueando a través de 1 de 2 servidores. La auditoría integrada solo nos dice eso (bloqueado de SERVER1, SERVER2).
La cuenta se bloquea dentro de los 5 minutos, al parecer, aproximadamente 1 solicitud por minuto.
Inicialmente intenté ejecutar procmon (desde sysinternals) para ver si se generaba un nuevo PROCESO DE INICIO después de desbloquear la cuenta. No surge nada sospechoso. Después de ejecutar procmon en mi estación de trabajo y elevarlo a un shell UAC (conscent.exe), parece que desde la pila aparece ntdll.dlly rpct4.dllrecibe una llamada cuando intenta autenticar contra AD (no estoy seguro).
¿Hay alguna forma de restringir qué proceso está causando una solicitud de autenticación a nuestro DC? Siempre es el mismo DC, por lo que sabemos que debe ser un servidor en ese sitio. Podría intentar buscar las llamadas en wireshark, pero no estoy seguro de que eso reduciría qué proceso realmente lo está desencadenando.
Tampoco los servicios, las asignaciones de unidades o las tareas programadas utilizan esa cuenta de dominio, por lo que debe ser algo que tenga almacenados los créditos de dominio. No hay sesiones RDP abiertas con esa cuenta de dominio en ningún servidor (verificamos).
Notas adicionales
Sí, las auditorías de inicio de sesión de "éxito / falla" están habilitadas en el DC en cuestión: no se registran eventos de falla hasta que la cuenta esté bloqueada.
Más excavaciones muestran que LSASS.exerealiza una KERBEROSllamada al DC en cuestión una vez que se desbloquea la cuenta. Está precedido (generalmente) por Java, que parece ser llamado por vpxd.exeun proceso de vCenter. PERO, cuando miro al otro "servidor2" desde el que puede ocurrir el bloqueo de la cuenta (también), nunca veo una llamada lsass.exey solo se generan procesos de apache. La única relación que ambos tienen es que SERVER2 es parte del clúster vSphere de SERVER1 (el servidor1 es un sistema operativo vSphere).
Error en DC
Entonces, parece que todo lo que AD me va a decir es que es un error Kerberos previo a la autenticación. Verifiqué y no había boletos con kliste hice un rubor de todos modos por si acaso. Todavía no tengo idea de qué está causando este error kerberos.
Index : 202500597
EntryType : FailureAudit
InstanceId : 4771
Message : Kerberos pre-authentication failed.
Account Information:
Security ID: S-1-5-21-3381590919-2827822839-3002869273-5848
Account Name: USER
Service Information:
Service Name: krbtgt/DOMAIN
Network Information:
Client Address: ::ffff:x.x.x.x
Client Port: 61450
Additional Information:
Ticket Options: 0x40810010
Failure Code: 0x18
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Certificate information is only provided if a certificate was used for pre-authentication.
Pre-authentication types, ticket options and failure codes are defined in RFC 4120.
If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
in this event might not be present.
fuente
Encontré esta vieja pregunta mientras investigaba un problema diferente, pero para cualquier persona con un problema similar:
El código de falla 0x18 significa que la cuenta ya estaba deshabilitada o bloqueada cuando el cliente intentó autenticarse.
Debe encontrar la misma ID de evento con el código de falla 0x24 , que identificará los intentos fallidos de inicio de sesión que causaron el bloqueo de la cuenta. (Esto supone que está ocurriendo debido a una contraseña en caché incorrecta en alguna parte).
Luego puede ver la Dirección del cliente en esos eventos para ver qué sistema está pasando las credenciales incorrectas. A partir de ahí, tendría que averiguar si se trata de un servicio con una contraseña anterior, una unidad de red asignada, etc.
Hay una variedad de códigos de falla, por lo que debe buscar cualquier cosa además de 0x18 para determinar qué causó el bloqueo de la cuenta si no hay eventos con códigos 0x24. Creo que el único tipo de falla que conducirá a un bloqueo es 0x24 (contraseña incorrecta), pero podría estar equivocado.
fuente
Kerberos 0x18 es de hecho un intento de contraseña incorrecta.
Kerberos 0x12 es una cuenta deshabilitada, caducada, bloqueada o restricción de horas de inicio de sesión.
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771
fuente
Hoy pasé mucho tiempo y descubrí la causa raíz. Me equivoqué: desde la información capturada con el sniffer de red (la identificación del proceso de error de Kerberos fue 566 = lsass.exe). Déjame resumir la información.
Inicie sesión en la PC problemática, ejecute powershell con derechos elevados
Habilitar inicio de sesión de auditoría
auditpol /set /subcategory:"logon" /failure:enableComprueba la fuente
Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | flSi tú ves:
Significa que tiene algún servicio que se ejecuta desde una cuenta problemática con una contraseña anterior
fuente
Esto es de las notas anteriores. Parece que el iniciador de esta publicación declaró en su último comentario. Java llamando al proceso vpxd.exe.
Notas adicionales Sí, las auditorías de inicio de sesión de "éxito / falla" están habilitadas en el DC en cuestión: no se registran eventos de falla hasta que la cuenta esté bloqueada.
Una excavación adicional muestra que LSASS.exe realiza una llamada KERBEROS al DC en cuestión una vez que se desbloquea la cuenta. Está precedido (generalmente) por java, que parece ser llamado por vpxd.exe, que es un proceso de vCenter. PERO, cuando miro el otro "servidor2" desde el que puede ocurrir el bloqueo de la cuenta (también), nunca veo una llamada a lsass.exe y solo se generan procesos de apache. La única relación que ambos tienen es que SERVER2 es parte del clúster vSphere de SERVER1 (el servidor1 es un sistema operativo vSphere).
fuente