Si tras actualizar a Windows 11 24H2 tus equipos dejan de autenticarse mediante 802.1X, este artículo explica por qué sucede, cómo confirmarlo, las pruebas que descartan otras causas y los pasos que debes seguir para lograr una solución definitiva o mitigar el impacto en tu red corporativa.
Resumen del problema
En entornos cableados con autenticación 802.1X basada en PEAP‑MSCHAPv2 o en módulos de terceros (por ejemplo EAP‑GTC) se observa que la misma configuración que funcionaba sin incidencias en Windows 10 o en Windows 11 previos, deja de hacerlo en la compilación 26100 (o superior) de Windows 11 24H2. Windows sólo muestra la notificación “Se requiere inicio de sesión”, pero nunca presenta la interfaz de credenciales del módulo EAP.
- El ciclo de paquetes se repite Request → Identity → Failure → Request, agotando el temporizador sin establecer la sesión.
- EapHost llega a cargar la DLL del proveedor externo, pero nunca invoca
EapPeerBeginSession(), por lo que la autenticación no se inicia. - Pruebas habituales —reinstalar EAP‑GTC, añadir
ThirdPartyEapDispatcherPeerConfig = 1en registro, desactivar Credential Guard o renovar certificados— no resuelven la incidencia.
Impacto para las organizaciones
El bloqueo puede:
- Impidir que estaciones de trabajo reciban dirección IP (si 802.1X controla el puerto físico) y por tanto evitar el acceso a recursos críticos.
- Romper la segmentación dinámica de VLAN, obligando a equipos 24H2 a ubicarse en la red de invitados.
- Generar un incremento notorio de tickets y costes operativos en el Service Desk.
En despliegues masivos de actualizaciones —sobre todo con políticas de ring deployment o pilotajes automáticos— es clave detener la propagación hasta verificar compatibilidad.
Cambios introducidos en Windows 11 24H2
Microsoft ha reforzado la cadena de confianza de EAPHost con estos ajustes internos:
- Validación de firma digital ampliada: la DLL de un método EAP externo debe incluir contrafirma SHA‑256 y estar time‑stamped por una CA de confianza.
- Separación de contexto UI: ahora las ventanas de credenciales se lanzan en un proceso aislado de tipo
dllhost.execon AppContainer. Si el proveedor no declara correctamente el CLSID de la interfaz gráfica o no soporta windowless initiation, la llamada se descarta. - Refactorización de marcos de trabajo: se han movido rutinas de inicialización desde
eaphost.exea librerías compartidas, alterando el orden de carga y las llamadas aEapPeerGetIdentity.
Estas modificaciones, destinadas a mejorar la seguridad frente a inyección de DLL o token theft, impiden que código heredado continúe funcionando sin recompilar con el nuevo SDK 24H2.
Diagnóstico rápido paso a paso
Antes de profundizar, confirma si realmente te encuentras ante el fallo descrito:
- Desde un equipo afectado abre PowerShell como administrador y ejecuta
netsh lan show eap. Verifica que tu método aparece como Enabled. - Comprueba en servicios que
EapHostyWired AutoConfigestán establecidos en Automatic y en estado Running. - Despliega un puerto de switch en VLAN de producción y captura tráfico con Wireshark; si observas repetición de EAP Request / Identity seguida de Failure sin que jamás aparezca EAP-Success, confirma el síntoma.
- Abre el Visor de eventos y filtra el registro Microsoft-Windows-EapHost/Operational. Encontrarás errores 12013 o 20028 que indican UI invocation failed o EAP peer method DLL returned failure.
Pruebas de aislamiento para acotar la causa
Una vez verificado el fallo, realiza estas pruebas para descartar otros factores:
| Prueba | Objetivo | Resultado esperado |
|---|---|---|
| Crear un perfil que use sólo PEAP‑MSCHAPv2 nativo | Evaluar si el problema es global o específico del módulo de terceros | Si PEAP nativo funciona, la incompatibilidad es del proveedor externo |
| Desactivar temporalmente Credential Guard | Eliminar interferencias de virtualización de credenciales | En la mayoría de casos no cambia el resultado |
Ejecutar sfc /scannow y Dism /Online /Cleanup-Image /RestoreHealth | Descartar corrupción de sistema | El fallo persiste: no es corrupción de archivos |
Captura de registros avanzados
Al abrir un caso en Microsoft Q&A o con tu partner de soporte, aportar evidencias sólidas acelera la resolución:
- Visor de eventos: exporta Microsoft-Windows-EapHost/Operational y Wired-AutoConfig/Operational.
- Process Monitor: filtra por
eaphost.exeydllhost.exe; revisa si aparece STATUSDLLNOTFOUND o STATUSINVALIDIMAGEHASH al cargar tu DLL. - Netsh trace:
netsh trace start scenario=NetConnection capture=yes; reproduce el problema y detén el rastreo para obtener un ETL completo.
Mitigación rápida mientras llega el parche
Si necesitas recuperar la operativa antes de una corrección oficial, plantéate:
- Mantener Windows 10 o builds anteriores de Windows 11 en estaciones críticas. Utiliza etiquetado dinámico en Intune o WSUS para bloquear las actualizaciones Feature Update a 24H2.
- Habilitar VLAN de fallback: muchos switches permiten asignar la VLAN nativa cuando 802.1X falla tras X segundos, evitando una caída total de conectividad.
- Proporcionar credenciales cacheadas: si tu infraestructura admite re‑autenticación basada en sesión anterior (fast reclaim), los equipos que ya estaban conectados antes de subir a 24H2 pueden sobrevivir a un reinicio de puerto.
Plan de acción recomendado
La experiencia con cambios parecidos (p. ej., la introducción de LSASS en modo protegido o de la firma obligatoria SHA‑1 → SHA‑2) demuestra que el camino más corto es trabajar de la mano con Microsoft. Sigue esta estrategia:
- Reúne artefactos (logs, capturas, número de compilación, GUID del método EAP, firmas de la DLL).
- Publica el caso en Microsoft Q&A, foro Windows Client → Networking. Indica claramente “802.1X – Third‑party EAP fails on Windows 11 24H2 build 26100”. Adjunta los logs.
- Insiste en el canal de Feedback Hub con el mismo título y adjunta el paquete de diagnósticos. Cuantas más señales reciba el equipo de redes de Microsoft, antes llegará el hotfix.
- Programa comprobaciones semanales de los acumulativos de Windows Update; usa PowerShell (
Get-WindowsUpdateLog) para validar si la KB recién publicada menciona “EAPHost compatibility”. - Cuando haya parche, despliega primero en un anillo piloto limitado, repite las pruebas de autenticación y valida que el bucle Request → Identity desaparece.
Mejores prácticas para desarrolladores de módulos EAP
Si eres proveedor de una solución de identidad basada en EAP:
- Compila con el Windows SDK 24H2 y firma la DLL con un certificado de EV Code‑Signing sustentado en SHA‑256 y sello de tiempo RFC 3161.
- Declara correctamente el CLSID de la UI bajo
HKLM\SYSTEM\CurrentControlSet\Services\EapHost\Methods\{GUID}\ConfigUIClsid. - Implementa la interfaz IPropertyStore para exponer metadatos de UI requeridos por el nuevo lanzador.
- Prueba en entornos con Core Isolation y con Credential Guard activos para prevenir futuros bloqueos.
Preguntas frecuentes
¿Funciona la misma solución en 802.1X inalámbrico?
Sí; aunque la pila Wi‑Fi usa wlanext.exe en lugar de dot3svc, ambos llaman a EAPHost. Algunos usuarios reportan que el síntoma se reproduce también en Wi‑Fi corporativo WPA‑Enterprise.
¿Es posible deshabilitar la nueva validación de firmas por GPO?
No. Microsoft no expone directivas para revertir la verificación de firma y aislamiento de UI en 24H2, al considerarlo un componente crítico de seguridad.
¿Puedo usar NPS en modo non‑EAP (MAC authentication bypass) como alternativa?
Sólo como medida temporal. MACAuth es menos seguro y requiere mantener una base de datos de direcciones MAC que crece y se vuelve difícil de administrar.
Conclusión
El fallo de autenticación 802.1X en Windows 11 24H2 es consecuencia directa de las mejoras de seguridad aplicadas a EAPHost. Hasta que Microsoft publique el parche correspondiente, la única vía consiste en escalar el incidente con información exhaustiva y mantener la versión anterior en equipos de misión crítica. Documentar detalladamente la incidencia —y seguir las actualizaciones de Windows— garantizará una liberación más rápida del hotfix y una transición fluida cuando esté disponible.