Empresas que atualizaram estações de trabalho para o Windows 11 24H2 (build 26100 ou superior) estão enfrentando uma falha crítica: a autenticação 802.1X em redes cabeadas para de funcionar quando é usado um módulo EAP de terceiros, como o EAP‑GTC, que operava normalmente no Windows 10. O problema, já reconhecido nos canais de Feedback da Microsoft, segue sem correção oficial. Abaixo detalhamos causas prováveis, evidências coletadas, impacto operacional e caminhos práticos para mitigação enquanto não há patch definitivo.
Visão geral do problema
Após a instalação da versão 24H2, o Windows passa a exibir um alerta “Sign‑in required” nas conexões Ethernet protegidas por 802.1X. Contudo, ao clicar no botão disponibilizado pelo sistema, nenhuma interface de credenciais é aberta. Capturas de pacotes mostram o seguinte ciclo EAP:
- EAP‑Request (Identity)
- EAP‑Response (Identity)
- EAP‑Failure
Na prática, o switch volta a uma VLAN de quarentena ou simplesmente recusa o acesso, interrompendo a conectividade do usuário.
Sintomas observados
- Alerta persistente de autenticação na área de notificação do Windows (“Sign‑in required”).
- Ausência de pop‑up para digitação de senha, token ou OTP.
- Ciclo repetitivo de inicialização e término do processo
dllhost.exe. - Falha na troca EAP antes de qualquer desafio do provedor (GTC, OTP, etc.).
Investigação detalhada
Análise de pacotes (Wireshark)
O tráfego revela apenas um par Request/Identity e Response/Identity, seguido de Failure. Não há Challenge nem Vendor‑Specific Attributes que normalmente transportariam campos próprios do EAP‑GTC.
Logs do EapHost
O log do serviço mostra chamadas a GtcEapPeerGetIdentity(); entretanto, não surge nenhuma entrada de EapPeerBeginSession(), ponto em que a UI do provedor costuma ser lançada.
Monitoramento de processos
Ferramentas como Process Explorer e DebugView++ revelam que o dllhost.exe responsável pela hospedagem do módulo é iniciado, invoca a classe COM ThirdPartyEapDispatcherPeerConfig e é encerrado imediatamente, reiniciando em um loop.
Tabela de constatações técnicas
| Componente | Comportamento observado | Diferença vs. Windows 10 |
|---|---|---|
| EAP‑GTC (3rd‑party) | DLL (eapp3hst.dll) carregada em dllhost.exe, mas EapPeerBeginSession() nunca é chamado. | No Windows 10 a função é chamada e a UI é aberta. |
| EapHost logs | Somente entradas de GtcEapPeerGetIdentity(); ausência de BeginSession. | BeginSession ocorre normalmente no Windows 10. |
| Process Explorer / DebugView++ | dllhost.exe inicia e encerra repetidamente; COM ThirdPartyEapDispatcherPeerConfig é invocada. | Processo permanece ativo no Windows 10. |
Possível raiz do problema
Embora a Microsoft ainda não tenha divulgado um boletim, a evidência aponta para mudanças internas no EAPHost – camada que abstrai os métodos de autenticação. O Windows 11 24H2 reforçou políticas de segurança associadas ao Credential Guard e à assinatura de binários, o que pode ter impactado módulos externos que não se adaptaram a novas interfaces ou a verificações de integridade ampliadas.
Por que funcionava no Windows 10?
O Windows 10 segue usando um pipeline EAPHost estável desde a versão 1511. O upgrade para 24H2 introduziu ajustes para compatibilidade com Virtualization‑Based Security, isolamento de processos sensíveis e renovação do fluxo COM de provedores. Consequentemente, um provedor que não foi recompilado com as novas dependências ou que não carrega metadados de assinatura corretos pode ser bloqueado silenciosamente.
Soluções já tentadas (sem sucesso)
- Habilitar Third‑Party EAP via
HKLM\SYSTEM\CurrentControlSet\Services\EapHost\ThirdPartyEapDispatcherPeerConfig = 1. - Desativar Credential Guard para restaurar DLL hosts antigos.
- Revalidar certificados de servidor e políticas de grupo.
- Carregar manualmente o módulo EAP‑GTC via utilitário
netsh lan add profile.
Impacto para ambientes corporativos
Organizações que dependem de tokens de dois fatores, cartões de acesso ou processos legados de autenticação (OTP por RADIUS usando EAP‑GTC) ficam sem conectividade cabeada. Em cenários de acesso condicionado (NAC) ou de microsegmentação por VLAN, a falha derruba serviços críticos, exige rollback de imagem do SO ou força a migração para métodos nativos como EAP‑TLS.
Estratégias de mitigação a curto prazo
- Métodos nativos temporários: migrar estações sensíveis para PEAP‑MSCHAPv2 ou EAP‑TLS até que o fornecedor atualize o módulo GTC.
- Rollback do build: se a janela de suporte permitir, retornar para 23H2 ou Windows 10 enquanto o patch não é liberado.
- Aplicar políticas de fallback: ajustar o switch para mover endpoints não autenticados para uma VLAN de guest controlada, minimizando downtime.
- Whitelist de assinatura: revisar configurações de Windows Defender Application Control para permitir DLLs legadas assinadas antes de bloqueá‑las completamente.
Próximos passos recomendados
| Ação | Objetivo |
|---|---|
| Abrir chamado no Microsoft Q&A ou Developer Communities (Windows – Networking) | Obter esclarecimentos de engenheiros responsáveis e acompanhar eventuais patches. |
| Monitorar atualizações cumulativas do Windows 11 24H2 | Correções de EAP costumam ser incluídas nos Patch Tuesdays. |
| Confirmar assinatura do módulo EAP para Windows 11 | Novas políticas de assinatura e Driver Security podem bloquear binários legados. |
| Testar método EAP nativo em estação piloto | Mitigação provisória até correção para EAP‑GTC. |
| Coletar logs de EapHost, NetSetup e pacotes de rede | Facilitar a triagem para Microsoft ou fornecedor do módulo. |
Boas práticas de monitoramento e documentação
Crie um playbook interno com:
- Modelos de registro exportando eventos de EapHost e de operação de 802.1X.
- Guidelines de rollback com checkpoints de imagens aprovadas (desktops, VDI e laptops).
- Matriz de compatibilidade entre builds de Windows, firmware de switches e versões de servidores RADIUS.
- Política de atualização que só libera builds do canal General Availability após validação de 802.1X em laboratório.
Considerações finais
A interrupção da autenticação 802.1X no Windows 11 24H2 é um exemplo claro de como ajustes de segurança em camadas internas podem colidir com módulos de terceiros. Enquanto a Microsoft não disponibiliza hotfix ou esclarecimento oficial, os administradores devem optar por mitigação (EAP nativo ou rollback) e escalar o caso nos canais indicados, munidos de logs detalhados. Isso garante evidências suficientes para que o fabricante do módulo EAP ou o próprio time de rede da Microsoft reproduza o cenário e disponibilize correção na cadeia de atualização mensal.
Manter o histórico de testes, os binários atualizados e as políticas de assinatura em ordem reduzirá o risco de imprevistos semelhantes em futuras versões do sistema.