Problema

En entornos con Active Directory, los equipos con Windows 11 25H2 pueden presentar un bloqueo total del subsistema de seguridad (LSASS/LSAIso) cuando se realiza cualquier operación que dependa de SSPI o Kerberos. El síntoma típico es que aplicaciones como curl --negotiate, RDP, Chrome (proxy auth) o PuTTY (GSSAPI) quedan colgadas indefinidamente. Un diagnóstico rápido muestra que klist get tgt se detiene en Current LogonId is 0:0x… y, curiosamente, Wireshark no captura tráfico en los puertos 88/TCP, 88/UDP, 53 o 389. Herramientas de red básicas (ping, telnet) siguen funcionando, lo que indica que el problema no está en la conectividad física sino en la capa de autenticación local.

Este patrón – “aplicaciones que usan Kerberos dejan de responder mientras la red sigue operativa” – se repite en varios clientes y suele aparecer de forma intermitente, dificultando su detección y resolución.

Causa

Los deadlocks de SSPI/Kerberos pueden originarse por varios factores que, combinados, provocan que el hilo del hipervisor que ejecuta lsass.exe o LSAIso.exe quede bloqueado:

  1. Credential Guard / Hypervisor‑based LSA
    Cuando Credential Guard está activo, LSA se ejecuta dentro de un contenedor aislado (Hyper‑V). Si el controlador de red o la pila TCP/IP no entrega paquetes Kerberos (por ejemplo, por una regla de firewall que fuerza solo TCP y el cliente intenta UDP), el hilo de LSA espera indefinidamente, generando un lock.

  2. Kerberos forzado sobre TCP con MaxPacketSize = 1
    Configurar Kerberos para usar exclusivamente TCP y limitar el tamaño máximo del paquete a 1 byte obliga a que cada intercambio se fragmenta en cientos de paquetes. En entornos con proxies o firewalls que inspeccionan el tráfico, la fragmentación puede desencadenar una pérdida de paquetes y, al no recibir respuesta, LSA queda en espera.

  3. Proxy o firewall que manipula Kerberos
    En el caso descrito, Sophos Firewall actúa como proxy con Kerberos y NTLM habilitados. Si la regla de inspección de Kerberos está desincronizada con la versión del cliente (por ejemplo, firma de tickets incompatibles), el proceso de autenticación nunca finaliza y el hilo de LSA se bloquea.

  4. Actualizaciones de Windows 11 25H2 que introducen cambios en la gestión de credenciales
    Algunas actualizaciones de 25H2 modificaron la forma en que LSA interactúa con el controlador de red. En configuraciones donde el controlador de red está en modo “Power‑saving” o “Selective Suspend”, la capa de transporte puede suspender la conexión justo cuando LSA está esperando la respuesta del KDC, provocando el deadlock.

  5. Problemas de sincronización de tiempo
    Un desfase de tiempo entre el cliente y el Domain Controller hace que el ticket Kerberos sea rechazado por expiración. En entornos con Credential Guard, el rechazo no se comunica de forma inmediata y el hilo queda esperando la respuesta del KDC.

Solución

Una estrategia eficaz combina ajustes de configuración, validación de la cadena de confianza y, cuando sea necesario, desactivar temporalmente componentes de aislamiento. Los pasos a seguir son:

1. Verificar y, si conviene, desactivar Credential Guard

reg query "HKLM\System\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled

Si el valor es 1, desactívalo mediante GPO o editando la clave:

reg add "HKLM\System\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled /t REG_DWORD /d 0 /f

Reinicia el equipo para que el cambio tome efecto. En la mayoría de los entornos corporativos, desactivar Credential Guard elimina el contenedor hipervisor y permite que LSA recupere su flujo normal.

2. Cambiar la política de transporte Kerberos a UDP (fallback)

En el controlador de dominio, abre Group Policy Management, edita la política Computer Configuration → Policies → Administrative Templates → System → KDC y habilita “Allow Kerberos authentication over UDP”. En los clientes, fuerza UDP con:

reg add "HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v EnableUDP /t REG_DWORD /d 1 /f

Reinicia el servicio kdc o el propio cliente.

3. Ajustar MaxPacketSize

Un valor de 1 es extremo y rara vez necesario. Configura un tamaño razonable (por ejemplo, 1400) en la política de dominio:

reg add "HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v MaxPacketSize /t REG_DWORD /d 1400 /f

Esto reduce la fragmentación y evita que el firewall descarte paquetes incompletos.

4. Revisar reglas del firewall/proxy

  • Asegúrate de que los puertos 88/TCP, 88/UDP, 53/TCP/UDP y 389/TCP estén permitidos sin inspección profunda.
  • Desactiva temporalmente la inspección de Kerberos en Sophos para confirmar si el problema desaparece.
  • Si el proxy necesita inspeccionar, habilita la opción “Kerberos passthrough” o “allow pre‑authentication”.

5. Sincronizar tiempo

Ejecuta en todos los clientes y DCs:

w32tm /resync /nowait

Configura NTP de forma centralizada para evitar desfases futuros.

6. Reiniciar LSA sin reiniciar la máquina (opcional)

En casos donde el deadlock ya está activo y no se desea un reboot completo:

net stop lsass
net start lsass

Nota: En Windows 10/11 el servicio lsass no se puede detener directamente; la alternativa es reiniciar el proceso mediante taskkill /PID <pid> /F y luego ejecutar sc start lsass. Este método es riesgoso y solo debe usarse en entornos de prueba.

7. Aplicar los últimos parches de Windows 11 25H2

Microsoft ha lanzado correcciones que abordan el deadlock de LSA bajo ciertas combinaciones de Credential Guard y Kerberos TCP. Mantén los clientes al día con Windows Update o WSUS.

Cuándo aplicar esta solución

  • Síntomas: aplicaciones basadas en SSPI/Kerberos se quedan colgadas, klist get tgt se bloquea en LogonId 0:0x…, no hay tráfico en el puerto 88 aunque la red funciona.
  • Entorno: Windows 11 25H2 o versiones posteriores, dominio AD (Server 2016/2019), uso de Credential Guard o LSAIso, y Kerberos forzado sobre TCP.
  • Exclusiones: si la red muestra pérdida de paquetes en Wireshark o si el problema ocurre solo en una única máquina sin Credential Guard, la causa probablemente sea distinta (hardware NIC, driver desactualizado, etc.).

Código

# 1. Desactivar Credential Guard (requiere reinicio)
reg add "HKLM\System\CurrentControlSet\Control\DeviceGuard\Scenarios\CredentialGuard" /v Enabled /t REG_DWORD /d 0 /f

# 2. Forzar Kerberos sobre UDP
reg add "HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v EnableUDP /t REG_DWORD /d 1 /f

# 3. Ajustar tamaño máximo de paquete Kerberos
reg add "HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters" /v MaxPacketSize /t REG_DWORD /d 1400 /f

# 4. Sincronizar tiempo con el DC
w32tm /resync /nowait

Verificación

  1. Comprobar que klist avanza

    klist get tgt

    El comando debe devolver el ticket sin detenerse en LogonId.

  2. Captura de tráfico
    Inicia Wireshark filtrando kerberos y verifica que aparecen paquetes en el puerto 88 (UDP o TCP según la configuración). No debería haber ausencia de tráfico.

  3. Prueba de aplicación
    Ejecuta curl --negotiate -u : https://intranet.example.com o abre una sesión RDP. La respuesta debe ser inmediata.

  4. Revisar logs de LSASS
    En el Visor de eventos, bajo Windows Logs → Security, busca eventos 4768/4769 sin errores de “KDC_ERR_PREAUTH_FAILED”.

Notas adicionales

  • En entornos con Sophos Firewall HA, la regla de inspección se debe replicar en ambas IP virtuales; de lo contrario, el tráfico puede saltar a una instancia sin la excepción Kerberos y volver a bloquearse.
  • Si la desactivación de Credential Guard no es viable por políticas de seguridad, considera habilitar “Remote Credential Guard” y delegar la autenticación a un servidor de salto que no tenga CG activado.
  • La combinación de TCP + MaxPacketSize = 1 es una configuración que rara vez se justifica. Revisa los GPO que la establecen; a menudo proviene de pruebas antiguas de redes con MTU reducida.
  • Cuando se reinicia LSA mediante net stop/start, los usuarios pueden perder sesiones activas. Planea la acción fuera de horario de producción o notifica a los usuarios.