Problema

En entornos corporativos donde los equipos Windows 11 se conectan a puertos de switch configurados con 802.1X, es frecuente observar una breve interrupción de la conectividad justo después de que se aplican las GPO. Durante esa ventana el cliente intenta autenticarse contra recursos CIFS usando Kerberos, pero la solicitud se dirige al SPN cifs/ourdomain.org (nombre de dominio sin controlador específico). Al no existir ese SPN, Kerberos falla y el sistema recurre a NTLM. Si la política de dominio bloquea NTLM, la obtención de GPO y la redirección de carpetas se quedan en estado de error hasta que el cliente vuelve a intentar la operación unos minutos después.

Los síntomas típicos son:

  • Fallos intermitentes al cargar políticas de grupo al inicio.
  • Mensajes de “NTLM blocked” al iniciar sesión rápidamente después del arranque.
  • Retrasos en la aparición del escritorio cuando la redirección de carpetas depende de DFS‑N.
  • Eventos en Security‑Kerberos\Operational con “SPN not found” para el dominio desnudo.

El comportamiento se dispara únicamente cuando el cliente está bajo 802.1X; al desactivar la autenticación del puerto el problema desaparece. La causa está en la sincronía entre el proceso EAPOL (autenticación 802.1X) y la resolución de los controladores de dominio que el cliente necesita para Kerberos.

Causa

1. Estado de red transitorio tras EAPOL

Cuando el switch envía el primer EAP‑Request/Identity, Windows inicia la pila de autenticación 802.1X. Hasta que la asociación se marca como DomainAuthenticated, la pila de red aún usa la configuración de red “Public”. En ese lapso los servicios de descubrimiento de DC (LLMNR, NetBIOS, DNS) pueden devolver respuestas incompletas o dirigirse al dominio raíz, lo que genera un SPN sin controlador.

2. Resolución de DFS‑N antes de que el cliente tenga un DC válido

DFS‑N utiliza la ruta UNC \\ourdomain.org\RedirectedFolders. Si la resolución DNS devuelve el registro CNAME del dominio antes de que el cliente haya establecido una sesión Kerberos, la petición se envía al SPN desnudo y falla.

3. Caché de credenciales y políticas de “Network security: Restrict NTLM”

En dominios donde NTLM está bloqueado, cualquier intento de fallback se aborta y el cliente queda sin método de autenticación hasta que la pila de red se estabiliza. La política de restricción de NTLM, aunque necesaria, expone la dependencia de Kerberos en el momento de arranque.

4. Diferencias de temporización entre versiones de Windows

Las actualizaciones de Windows 11 25H2 introdujeron cambios en la prioridad de los adaptadores y en la forma en que la pila 802.1X notifica al subsistema de red. El tiempo entre la finalización del EAPOL y la disponibilidad de la lista de DC se amplía ligeramente, lo que hace que la ventana de falla sea más visible que en 23H2.

Solución

Una estrategia robusta combina ajustes en el cliente, en el controlador de dominio y en la infraestructura de red. Los pasos siguientes son aplicables a cualquier entorno que use 802.1X, DFS‑N y GPO.

1. Asegurar que la resolución de DC ocurre después de la autenticación 802.1X

  • Configura el switch para que envíe el EAP‑Success antes de habilitar el tráfico de datos. En la mayoría de los controladores Cisco/Juniper esto se logra con la opción post‑auth VLAN o inline‑policy que mantiene al cliente en una VLAN de aislamiento hasta que la autenticación finalice.
  • En el cliente, habilita la política de grupo Network security: Force logoff when logon hours expire (no directamente relacionada, pero fuerza la re‑evaluación de la red al cambiar de VLAN).

2. Forzar la resolución de controlador antes de acceder a DFS‑N

  • Añade una regla de inicio de sesión que ejecute nltest /sc_verify:DOMAIN o dsquery computer -name %computername% antes de que se inicie el proceso de redirección. Esto obliga a Windows a obtener un ticket Kerberos válido antes de tocar DFS.
  • Alternativamente, crea un script de inicio de sesión que realice klist purge y luego klist get cifs/yourdc.yourdomain.org para “calentar” la caché.
# Script de arranque (PowerShell)
nltest /sc_verify:YOURDOMAIN
klist purge
klist get cifs/yourdc.yourdomain.org

3. Añadir SPN de dominio desnudo como alias (opcional y con precaución)

  • En el controlador de dominio, registra un SPN genérico cifs/yourdomain.org apuntando a un DC de preferencia. Esto permite que, si la resolución falla, Kerberos todavía encuentre un objetivo válido.
setspn -a CIFS/yourdomain.org yourdc01.yourdomain.org
  • Advertencia: Exponer un SPN genérico incrementa la superficie de ataque; solo habilitarlo si la política de seguridad lo permite y se controla el acceso a la OU correspondiente.

4. Ajustar la política de restricción de NTLM

  • Crea una excepción temporal para cifs/yourdomain.org en la GPO Network security: Restrict NTLM: Outgoing NTLM traffic. La excepción debe ser lo más específica posible (solo el SPN necesario) y se puede revocar una vez que la infraestructura esté estable.
  • Si la organización prefiere bloquear NTLM totalmente, habilita la política Network security: Allow NTLM authentication on the network solo para el grupo de máquinas que presentan el problema, y monitoriza los eventos de auditoría.

5. Actualizar controladores de red y firmware

  • Algunas NIC presentan un bug que retrasa la notificación de “DomainAuthenticated”. Verifica que los drivers estén al día y, de ser posible, habilita la opción Enable IEEE 802.1X authentication on startup en la configuración del adaptador.

6. Revisar los tiempos de expiración de la caché DNS

  • Reduce el TTL de los registros SRV _ldap._tcp.dc._msdcs.yourdomain.org a 300 s en el DNS interno. Un TTL bajo garantiza que el cliente recupere rápidamente la lista de DC después de la autenticación.

Cuándo aplicar esta solución

Aplica cuando se cumplan al menos dos de los siguientes criterios:

  • Fallos de GPO o de redirección de carpetas aparecen solo en los primeros 60 s después del arranque.
  • Los eventos de Kerberos indican “SPN not found” para el dominio desnudo.
  • El problema desaparece al desactivar 802.1X en el puerto del switch.
  • La política de dominio bloquea NTLM y los logs muestran “NTLM blocked” en la sesión de inicio.

No aplica si:

  • La red no usa 802.1X (el problema está en otro punto).
  • Los equipos afectados son versiones de Windows anteriores a 10 1903 (no hay cambio de temporización).
  • La infraestructura DNS no tiene registros SRV o CNAME que apunten al dominio raíz.

Código

# 1. Verificar que el cliente tiene un ticket Kerberos válido para CIFS
klist get cifs/yourdc.yourdomain.org

# 2. Registrar SPN genérico (solo si se decide usar esta medida)
setspn -a CIFS/yourdomain.org yourdc01.yourdomain.org

# 3. Añadir excepción NTLM en la política local (ejemplo con PowerShell)
Import-Module SecurityPolicyDsc
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "RestrictNTLMOut" -Value 2

Verificación

  1. Reinicia una máquina cliente con 802.1X habilitado.
  2. Observa los eventos Security‑Kerberos\Operational durante los primeros 30 s; no deben aparecer errores de SPN.
  3. Ejecuta gpresult /r y verifica que todas las GPO se hayan aplicado sin “access denied”.
  4. Inicia sesión y comprueba que la carpeta redirigida está disponible inmediatamente.
  5. Si se usó la excepción NTLM, revisa el registro de auditoría para confirmar que no se generó ningún intento de fallback.

Notas adicionales

  • En entornos con múltiples VLAN de post‑auth, asegúrate de que la VLAN de datos tenga acceso a los puertos DNS y a los DC. Un firewall que bloquee DNS en la VLAN de datos reproduce el mismo síntoma.
  • La combinación de nltest /sc_verify y klist purge es útil en scripts de arranque porque no depende de la UI y funciona en sesiones sin interacción.
  • Cuando se registra un SPN genérico, monitoriza los logs de seguridad para detectar intentos de Pass‑the‑Ticket; el SPN amplio puede ser un vector de ataque si no se controla el acceso a la OU del DC.
  • Si la solución de excepción NTLM no es aceptable, considera habilitar Kerberos armoring (en Windows Server 2022 y versiones posteriores) para reducir la probabilidad de que una petición fallida caiga en NTLM.