Rastree qué proceso / programa está causando el error de autenticación previa de Kerberos (Código 0x18)

12

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.
Jaigene Kang
fuente

Respuestas:

5

Los eventos de inicio de sesión registran el proceso que intenta iniciar sesión. Habilite la auditoría de inicio de sesión fallido (Configuración de seguridad> Políticas locales> Política de auditoría> Auditar eventos de inicio de sesión) en la Política de seguridad local (secpol.msc) y luego busque un evento en el registro de eventos de seguridad. También puede habilitarlo a través de la Política de grupo, si eso fuera preferible.

Habrá una sección de Información del proceso que registra tanto la ruta ejecutable como la ID del proceso.

Ejemplo:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe
Mitch
fuente
Parece que esto ya estaba en nuestros GPO. Puedo ver cuando el objeto se modifica / desbloquea en el registro de seguridad, pero no veo malos intentos después de eso.
Jaigene Kang
@JaiKang, a menos que los servidores en cuestión sean DC, no se verán afectados por la configuración de "Auditoría de inicios de sesión fallidos" en la Política de controladores de dominio predeterminados. El evento de inicio de sesión fallido será registrado por el servidor que intenta la autenticación y se establecerá mediante la "Política de dominio predeterminada" u otra política de computadora que se aplique a ese servidor.
Mitch
De hecho, lo descubrí. Tuve que establecer algunas configuraciones en la sección "Avanzado" de la configuración de Auditoría. Actualicé mi publicación original con los eventos.
Jaigene Kang
@JaiKang, la autenticación previa es solo el proceso utilizado para verificar las credenciales antes de devolver un token. Todavía debe haber una auditoría de falla en el servidor que intenta la autenticación que incluye la identificación del proceso.
Mitch
¿Puede explicar qué ajustes "avanzados" tenía que establecer?
skinneejoe
2

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.

DoubleD
fuente
Perdón por la publicación de Necro y disculpas por no insertar como comentario ... Todavía no me he ganado mi 50p. :-) El código de falla 0x18 es una falla previa a la autenticación y no indica una cuenta bloqueada. Una cuenta bloqueada también podría activar un código 0x18, pero esperaría un 0x12 en lugar de credenciales revocadas.
Sjm
1

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.

  1. Inicie sesión en la PC problemática, ejecute powershell con derechos elevados

  2. Habilitar inicio de sesión de auditoría

    auditpol /set /subcategory:"logon" /failure:enable

  3. Comprueba la fuente

    Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Si tú ves:

Procesar informacion:

Identificador de proceso de llamada: 0x140

Nombre del proceso de la persona que llama: C: \ Windows \ System32 \ services.exe

Significa que tiene algún servicio que se ejecuta desde una cuenta problemática con una contraseña anterior

Alex
fuente
0

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).

usuario354506
fuente