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
- Sintoma
- Hipóteses
- Fontes de evidência
- Hipóteses descartadas
- Causa raiz
- Contorno
- 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
- Sinal fraco ou falha de antena (a suspeita inicial).
- Mudança na controladora Wi-Fi ou no servidor RADIUS.
- Problema na conta de computador ou no canal seguro com o domínio.
- Problema na conta do usuário.
- 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ótese | Evidência consultada | Conclusão |
|---|---|---|
| Sinal ou antena | A 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 RADIUS | Nenhuma mudança de configuração na janela da falha. | Descartada |
| Conta de computador / AD | Mesma OU e mesmos grupos dos notebooks que conectavam; canal seguro íntegro. | Descartada |
| Conta do usuário | Ativa, sem bloqueio, senha válida. | Descartada |
| Mudança no cliente Windows | Bloqueio 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?