Infraestrutura de TI / Estudo de caso

Diagnóstico de falha de autenticação 802.1X após atualização do Windows

Investigação de um notebook que deixou de entrar no Wi-Fi corporativo. A suspeita inicial era sinal ou antena; a causa estava em uma atualização de segurança do Windows.

Ambiente
Wi-Fi corporativo com 802.1X (mesma filial do caso anterior)
Período
Outubro de 2026
Papel
Analista de infraestrutura, responsável pelo diagnóstico
Tempo até a causa
Um dia de análise

Cruzando quatro fontes de log, isolei a causa em um dia: o fluxo de autenticação automática da estação dependia de credenciais derivadas de NTLM, e a política aplicada pela atualização de outubro do Windows bloqueou esse mecanismo no cenário analisado. Apliquei um contorno e recomendei a migração para EAP-TLS antes que os demais notebooks fossem afetados.

Última atualização: 22 de outubro de 2026

Resumo executivo

Contexto

A rede Wi-Fi corporativa da filial autentica estações com a conta de máquina do Active Directory, via 802.1X e PEAP-MSCHAPv2, sem pedir senha ao usuário. A implantação está descrita no estudo de caso do 802.1X.

Problema

Um notebook deixou de se conectar à rede corporativa. Nenhuma mudança havia sido feita na controladora Wi-Fi nem no servidor de autenticação. Se a causa estivesse no cliente e fosse sistêmica, outros notebooks poderiam cair da mesma forma.

Meu papel

  • levantamento da linha do tempo da falha;
  • formulação e teste das hipóteses;
  • coleta e correlação dos logs do cliente, do NTLM, do RADIUS e do Active Directory;
  • definição do contorno imediato (rede temporária);
  • recomendação da correção definitiva e da análise de impacto para os demais notebooks.

Resultado

  • Causa raiz identificada e comprovada por evidência de log em todas as falhas do dia.
  • Usuário reconectado por uma rede temporária, mantendo a política 802.1X intacta para os demais equipamentos.
  • Risco antecipado: os demais notebooks com autenticação por credencial de máquina cairiam ao receber a mesma atualização.
  • Migração para EAP-TLS recomendada como correção definitiva.

O que este caso demonstra

  • Troubleshooting orientado por hipóteses
  • Correlação de logs de várias fontes
  • 802.1X, PEAP e NTLM
  • Análise de impacto de atualizações
  • Comunicação de risco e recomendação

Detalhes técnicos

Roteiro da investigação

  1. Sintoma
  2. Hipóteses
  3. Fontes de evidência
  4. Hipóteses descartadas
  5. Causa raiz
  6. Contorno
  7. Correção definitiva

Sintoma

  • Última conexão bem-sucedida às 13:48.
  • Às 14:01 o notebook reinicia sozinho para instalar a atualização.
  • Às 14:03 ocorre a primeira recusa. Nenhuma tentativa foi aceita depois disso.

Hipóteses

  1. Sinal fraco ou falha de antena (a suspeita inicial).
  2. Mudança na controladora Wi-Fi ou no servidor RADIUS.
  3. Problema na conta de computador ou no canal seguro com o domínio.
  4. Problema na conta do usuário.
  5. Mudança no próprio cliente Windows.

Fontes de evidência

  • Log de conexões sem fio do cliente (WLAN AutoConfig).
  • Log operacional de NTLM no cliente.
  • Log de autenticação do servidor RADIUS (NPS).
  • Active Directory: OU, grupos e estado da conta de computador.

Hipóteses descartadas e confirmada

HipóteseEvidência consultadaConclusão
Sinal ou antenaA falha começou logo após o reinício para atualização, e o túnel TLS com o servidor chegava a abrir, o que exige rádio funcionando.Descartada
Controladora Wi-Fi ou RADIUSNenhuma mudança de configuração na janela da falha.Descartada
Conta de computador / ADMesma OU e mesmos grupos dos notebooks que conectavam; canal seguro íntegro.Descartada
Conta do usuárioAtiva, sem bloqueio, senha válida.Descartada
Mudança no cliente WindowsBloqueio de NTLMv1 registrado no mesmo segundo de cada uma das 13 falhas do dia.Confirmada

Causa raiz

A rede usa PEAP-MSCHAPv2 com a credencial da máquina, sem pedir senha. No cenário analisado, esse fluxo de autenticação automática dependia de credenciais derivadas de NTLM, e a política aplicada pela atualização de segurança de outubro bloqueou esse mecanismo: o log operacional de NTLM do cliente registrou o bloqueio de credenciais derivadas de NTLMv1 no mesmo segundo de cada falha. O túnel TLS com o servidor de autenticação era estabelecido, mas o Windows deixava de enviar a credencial dentro dele. Não se trata de uma afirmação geral sobre todo PEAP-MSCHAPv2, e sim do comportamento observado nesta estação e nesta configuração.

Contorno imediato

Criação de uma rede temporária para o equipamento afetado, enquanto os ajustes para voltar a autenticar via RADIUS eram alinhados. A política 802.1X da rede corporativa não foi afrouxada.

Correção definitiva

Migrar a rede para EAP-TLS com certificado de máquina, eliminando a dependência de MSCHAPv2 e NTLMv1. A migração já constava como próximo passo no projeto original.

Limitações

  • A rede temporária é um contorno operacional: não tem o mesmo controle de acesso do 802.1X e precisa ser desativada assim que a autenticação via RADIUS voltar.
  • A correção definitiva depende de uma PKI com emissão, renovação e revogação de certificados de máquina, que exige planejamento próprio.
  • Os logs reais não são publicados; a evidência abaixo é uma reconstrução sintética do padrão observado.

Evidências

Nomes de máquina, usuário, SSID, domínio e servidores foram substituídos por marcadores. Os horários e a mensagem do NTLM são os observados; o formato das linhas foi simplificado para leitura.

Linha do tempo correlacionada (reconstrução sintética)

# fonte      hora    evento
WLAN        13:48   última conexão 802.1X bem-sucedida   SSID=<SSID-CORPORATIVO>
Sistema     14:01   reinício para instalar a atualização de segurança
WLAN        14:03   falha de autenticação 802.1X         SSID=<SSID-CORPORATIVO>
NTLM        14:03   "An attempt to use NTLMv1-derived credentials for
                     Single Sign-On was blocked due to policy"
# ... o mesmo par WLAN + NTLM se repete nas 13 falhas do dia, no mesmo segundo

Por que esta evidência é suficiente

A correlação não é apenas de horário aproximado: o evento de bloqueio do NTLM aparece no mesmo segundo de cada uma das 13 falhas, e a primeira delas ocorre logo após a instalação da atualização. As demais camadas (rádio, RADIUS, AD) foram verificadas e não apresentaram mudança.

Versão didática

Como eu ensinaria este conceito

O caso mostra que diagnóstico é um método, não um palpite: levantar hipóteses, testar cada uma contra uma evidência e descartar antes de trocar qualquer peça.

Público

Cursos técnicos de redes e suporte, e formação de professores de Computação.

Pré-requisitos

Saber o que é um log e ler horários.

Analogia

Um médico que pergunta “o que mudou desde ontem?” antes de pedir exames. A pergunta mais útil de um incidente é a mesma.

Experimento mínimo

Entregar à turma três “logs” sintéticos impressos (rede, sistema e servidor) com um evento intruso. Em grupos, os alunos montam a linha do tempo e precisam justificar cada hipótese descartada.

Erro comum

Confundir correlação com causa, ou trocar hardware (antena, placa) antes de ler os registros.

Pergunta de reflexão

Por que uma correção de segurança pode quebrar algo que funcionava? Quem deveria ser avisado antes?