Como testar a autenticação RADIUS passo a passo
Published
Você está em um local com um laptop, um ponto de acesso e um servidor RADIUS que "já deveria estar funcionando". Alguém enviou um ping. A porta UDP 1812 está aberta. Uma verificação no painel de controle até retornou verde. Nada disso diz se o dispositivo de um funcionário vai parar na VLAN de funcionários ou se um certificado revogado ainda obtém uma sessão.
Como testar a autenticação do RADIUS é uma cadeia de provas, não apenas um login. Trate cada Access-Accept como uma hipótese. Você ainda precisa verificar o método, os atributos, o endereço de origem e o que a rede faz quando o servidor, o diretório ou o certificado está errado.
Comece com uma solicitação controlada. Em seguida, amplie os casos até que uma aprovação falsa não tenha onde se esconder.
Índice
- Envie seu primeiro teste com radtest
- Por que o Access-Accept não comprova o acesso à rede
- Casos de teste que toda implantação do RADIUS precisa
- Meça a carga e a latência com o radclient
- Caminhos de falha, failover e verificações de segurança
- Leia os logs para confirmar cada resultado de teste
- Decida quando o RADIUS está pronto para a implementação
Envie seu primeiro teste com o radtest
O comando que você pode executar nos próximos cinco minutos é radtest testing password 127.0.0.1 0 testing123. O manual do radtest do FreeRADIUS define isso como um Access-Request controlado com cinco entradas: nome de usuário, senha, endereço do servidor, NAS-Port e segredo compartilhado. O PAP é o padrão. A mesma utilidade também pode enviar CHAP, MS-CHAP ou EAP-MD5.
Execute a linha de base antes de alterar qualquer outra coisa
- Defina uma conta de teste. Coloque um nome de usuário e uma senha conhecidos onde o servidor possa encontrá-los. Você precisa de uma credencial que possa digitar sem procurar em um diretório.
- Liste o cliente. O host ou NAS de onde você envia deve estar em
clients.confcom o segredo que você digitará. Uma origem desconhecida é uma falha diferente de uma senha incorreta. - Inicie o servidor no modo de depuração. Cada pacote e motivo de rejeição deve ser exibido no terminal. Uma falha silenciosa desperdiça a execução.
- Envie as cinco entradas. Nome de usuário, senha, servidor, NAS-Port, segredo. Uma NAS-Port de
0é suficiente para esta primeira comprovação. - Leia o código e, em seguida, o motivo. Access-Accept significa que o servidor aprovou essas credenciais. Access-Reject significa que ele as recusou. A saída de depuração separa um segredo compartilhado incorreto, um cliente desconhecido, credenciais inválidas e uma falha de política.
- Repita a partir do NAS. Origine a mesma solicitação a partir do endereço do ponto de acesso ou switch, não apenas do localhost. Os clientes costumam ser autorizados pelo endereço de origem e pelo segredo compartilhado juntos.
A acessibilidade não é o resultado final. O pacote precisa chegar e a decisão de autorização deve ser a esperada. Em caso de aceite, inspecione os atributos retornados, como VLAN, tipo de serviço ou endereço enquadrado. Um aceite que nomeia a VLAN errada não é uma aprovação, mesmo quando o código parece correto.
Após essa aceitação básica, o mesmo manual lista oito métodos que podem funcionar para a conta de exemplo: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC e EAP-MD5. Não tente cobrir todos os oito hoje.
Regra prática: Salve um Access-Accept do endereço NAS real e um Access-Reject de uma senha incorreta. Essas duas observações são a linha de base em relação à qual todos os casos posteriores serão avaliados.
Por que o Access-Accept não comprova o acesso à rede
Um teste de infraestrutura verde é a aprovação falsa que eu não assinaria. Ele frequentemente apenas mostra que alguma solicitação obteve alguma resposta.
O guia de solução de problemas Meraki RADIUS afirma que seu teste de painel usa PEAP com MS-CHAPv2. Esse teste falha ou não oferece nenhuma validação significativa para EAP-TLS, porque o ponto de acesso não possui um certificado de cliente. A rede sem fio baseada em certificado precisa ser testada com um suplicante real que possua o certificado correto e a cadeia de confiança.
Quatro camadas, quatro perguntas diferentes
Transporte pergunta se algo respondeu. Um limite de tempo esgotado não é uma rejeição.
A autenticação pergunta se a senha ou o certificado era válido para essa identidade.
A autorização pergunta se a resposta trouxe a VLAN, a função ou a ACL que você pretendia enviar.
A acessibilidade questiona se o ponto de extremidade obteve o endereço esperado, a política de DNS e o acesso aos recursos que esse segmento deve permitir.
Uma aprovação em uma camada não diz nada sobre as outras três. A mesma orientação do Meraki, lida junto com o comportamento do FreeRADIUS EAP, descreve um teste do EAP-TLS bem-sucedido como uma troca de pacotes múltiplos de Access-Request e Access-Challenge e, em seguida, o acesso real do cliente à rede. Uma única verificação de conectividade não é esse teste.
Verifique o nome do servidor em que o suplicante confia, a cadeia da CA, a expiração do certificado e o relógio do dispositivo. O desvio do relógio invalida um bom certificado. Suponha que o notebook de um funcionário se autentique e, em seguida, permaneça na VLAN padrão em vez do segmento de funcionários. O Aceite foi legítimo. O posicionamento na rede estava incorreto. Essa é a falha que a maioria das listas de verificação nunca registra.
Mantenha linhas separadas para usuários de senha, dispositivos EAP-TLS, identidades xPSK e políticas baseadas em diretório. Um aceite PAP não deve substituir um ingresso por certificado.
Teste o EAP-TLS em um dispositivo sobressalente
- Emita um certificado de cliente de teste da mesma CA em que o servidor confia.
- Instale o certificado e a cadeia da CA em um notebook ou telefone sobressalente.
- Confirme se o suplicante valida o nome do servidor configurado.
- Conecte-se e capture a troca de desafios, e não uma sondagem de pacote único.
- Confirme se a sessão é encerrada na VLAN esperada com acesso real à rede.
Uma visualização curta dessa troca torna a captura mais fácil de reconhecer quando seu próprio rastreamento estiver ruidoso.
Casos de teste que toda implantação de RADIUS precisa
Uma credencial válida pode produzir um Access-Accept enquanto o usuário cai na rede errada. Teste cada camada separadamente: manipulação de solicitações, autenticação, atributos de autorização e o acesso real do ponto de extremidade. O guia de testes de desempenho do FreeRADIUS cobre tanto a carga quanto a exatidão. Inclua também casos negativos: credenciais inválidas devem retornar Access-Reject, enquanto solicitações malformadas, um NAS não reconhecido e um segredo compartilhado incorreto não devem produzir um login bem-sucedido.
O fluxo de trabalho radtest é estabelecido há muito tempo e ainda usa as mesmas cinco entradas. Para métodos com túnel, teste o servidor de autenticação interno separadamente na porta UDP 18120. Use um teste interno MS-CHAP quando PEAP for o método externo. Isso ajuda a isolar se uma falha está na troca externa do EAP, na configuração do certificado ou TLS, ou na verificação de credenciais interna.
Um Access-Accept é uma hipótese a ser verificada, não uma prova de acesso correto à rede. O Guia de implementação do FreeRADIUS descreve como um NAS pode descartar um atributo VLAN não suportado ou mapear um atributo ausente para um VLAN padrão. Verifique os atributos retornados e, em seguida, confirme o endereço do ponto de extremidade, VLAN, ACL, política de DNS e conectividade. O EAP-MD5 não fornece o material de chave que a rede sem fio precisa, portanto, uma aceitação do EAP-MD5 não é evidência de prontidão para a rede sem fio. Use-o apenas para testes limitados em redes cabeadas.
Defina os segmentos pretendidos antes de executar os testes de autorização; o controle de acesso à WiFi explica como estruturar essa política.
Nove linhas que contam como o mínimo
| Caso de teste | Como executar | Resultado esperado |
|---|---|---|
| Aceite básico | Execute o radtest com uma conta de teste válida a partir do IP do NAS |
Access-Accept com o atributo de VLAN esperado; confirme se o endpoint vai para esse VLAN |
| Senha incorreta | Execute o radtest com uma senha incorreta |
Access-Reject com um motivo registrado em log |
| Segredo compartilhado incorreto | Envie a partir de um cliente configurado com um segredo divergente | Nenhum Access-Accept; erro de segredo visível na saída de depuração |
| NAS desconhecido | Envie a partir de um endereço IP não definido como cliente | Descartado ou rejeitado e registrado em log |
| Dispositivo EAP-TLS válido | Conecte um suplicante real com um certificado válido e uma cadeia de confiança | Access-Accept e a VLAN correta para o seu grupo; confirme o acesso à rede a partir do dispositivo |
| Certificado expirado ou revogado | Conecte um dispositivo com um certificado expirado ou revogado | Access-Reject, sem alternância de contingência para uma rede padrão |
| Alteração de grupo no diretório | Mova o usuário de teste para outro grupo e faça a reautenticação | A VLAN ou a função muda para corresponder ao novo grupo, ou o acesso é recusado |
| Servidor primário indisponível | Bloqueie a porta UDP 1812 para o servidor primário ou interrompa-o | Failover para o secundário dentro do tempo limite, com a mesma política aplicada |
| Início e término de contabilidade (Accounting) | Inicie uma sessão e, em seguida, encerre-a | Os registros de início e término correspondem à sessão |
Para cada linha, registre a chegada da solicitação, o código de resposta, a latência de ida e volta, a política selecionada, os atributos retornados e o início e o fim da contabilização. Repita cada teste para capturar perdas de UDP intermitentes. Uma única execução limpa pode deixar passar um VLAN incorreto ou uma decisão de política inconsistente.
Um aceite que coloca o cliente na rede errada é um teste com falha.
Meça a carga e a latência com o radclient
Uma aceitação silenciosa esconde a fila. O teste de volume precisa de uma ferramenta construída para um lote, e não de outro login único.
- Crie um arquivo de autenticação com nomes de usuário e senhas aleatórios. Misture entradas válidas e inválidas para que as rejeições sejam contadas e não tratadas como ruído.
- Envie o arquivo e cronometre o lote com o comando Unix
timeenquanto oradclientexecuta o servidor. - Registre as contagens brutas. Total de solicitações, aceitações, rejeições, timeouts, respostas de erro e tempo decorrido.
- Calcule as taxas. A taxa de aceitação deve corresponder à parcela válida do arquivo. A taxa de rejeição deve corresponder à parcela inválida. Considere também a latência média e de percentil.
- Repita no horário de pico. Um check-in pela manhã ou o início das aulas mostrarão um enfileiramento que uma execução em laboratório na hora do almoço jamais mostrará.
| Métrica | Como calcular | Meta |
|---|---|---|
| Total de solicitações | Contagem de linhas enviadas do arquivo de autenticação | Igual ao tamanho do arquivo |
| Taxa de aceitação | Aceitações divididas pelo total de solicitações | Corresponde à parcela válida do arquivo |
| Taxa de rejeição | Rejeições divididas pelo total de solicitações | Corresponde à parcela inválida do arquivo |
| Timeouts e erros | Contagem de respostas sem resposta e de erro na execução | Zero em um caminho limpo |
| Latência média | Tempo de resposta médio em todas as solicitações | Dentro da sua meta de latência no pico |
| Tempo decorrido | Saída de tempo Unix para o lote completo | Estável em execuções repetidas |
Separe o túnel do repositório de contas
Se a taxa de aceitação for menor do que a parcela válida, não culpe a "carga" até saber qual metade falhou. Para PEAP, teste o método interno de forma independente com uma solicitação MS-CHAP no servidor interno. Um aceite interno com uma conexão externa com falha aponta para certificados ou configurações de TLS. Um handshake externo que falha na verificação interna aponta para o repositório de contas, o hash da senha ou o grupo esperado pela política.
Mantenha esses tempos no mesmo log dos resultados funcionais. Uma alteração posterior de firmware ou de diretório deve ser comparada com essa linha de base, e não com a sensação de que "parecia mais lento".
Se os tempos limite aumentarem apenas nos horários de pico, corrija a capacidade ou o caminho antes de adicionar locais. Um servidor correto e lento ainda falhará para clientes que desistirem primeiro.
Caminhos de falha, failover e verificações de segurança
Uma troca funcional ainda pode ser não segura. A solução de problemas que apenas pergunta se o UDP 1812 obteve uma resposta para cedo demais.
O boletim de segurança de 2025 da Juniper descreve a exposição ao Blast-RADIUS no Response Authenticator da RFC 2865. Um atacante local que consiga modificar o tráfego pode potencialmente transformar uma resposta válida em outra resposta por meio de uma colisão de prefixo escolhido em MD5. "Autenticação bem-sucedida" não é evidência de que a implantação está protegida.
Verificações que pertencem à mesma execução que o failover
Proteja o caminho onde a plataforma permitir. Confirme se a manipulação no caminho está bloqueada e se a validação de Message-Authenticator é imposta em pacotes que a exigem.
Desative métodos fracos. Tipos de EAP obsoletos devem ser desativados, e não mantidos "por via das dúvidas". Se você ainda estiver escolhendo entre métodos externos de certificado e senha, compare-os em EAP-TLS vs PEAP antes de deixar ambos ativados.
Force a falha do servidor de propósito. Cada cenário abaixo deve mostrar a falha protegida (fail-closed) pretendida ou o fallback controlado, além de uma linha de log, um alerta e uma experiência do usuário que você possa explicar a um gerente de local.
| Cenário de falha | Como acionar | Condição de aprovação |
|---|---|---|
| Tempo limite (Timeout) | Bloquear UDP 1812 para o servidor | Falha fechada ou fallback controlado, registrado em log e alertado |
| Access-Reject | Usar uma senha incorreta | Acesso negado sem rede de fallback |
| Certificado expirado | Dispositivo com um certificado expirado | Access-Reject sem VLAN padrão |
| Certificado revogado | Dispositivo com um certificado revogado | Access-Reject sem VLAN padrão |
| IP de origem do NAS desconhecido | Enviar de um endereço não definido | Descartado ou rejeitado e registrado em log |
| Segredo compartilhado incorreto | Segredo divergente no cliente | Sem Access-Accept e erro de segredo na saída de depuração |
| Diretório inacessível | Interromper a conectividade do diretório | Recusado ou fallback controlado conforme a política |
| Resposta de autorização atrasada | Adicionar atraso à resposta de autorização | Tempo limite tratado sem acesso aberto |
O que o failover regional precisa preservar
A resposta de outro servidor não significa consistência de política. Ao interromper o primário, compare VLAN, limites de largura de banda, status de revogação e atributos de auditoria do servidor de backup com o primário. Um convidado que faz failover para um segmento de funcionários é um teste com falha, mesmo que a conexão tenha sido rápida.
Marque qualquer cenário que faça fallback para acesso aberto como reprovado, independentemente de o usuário ficar online ou não. Escreva cada resultado no mesmo log de teste da linha de base funcional para que uma alteração posterior de failover fique evidente.
Leia os logs para confirmar cada resultado de teste
Cada teste deve deixar um rastro que você possa corresponder a um ID de teste ou a uma conta conhecida. Em um ambiente com muito tráfego, essa identificação é a forma de encontrar sua execução sem precisar rolar pela rotina matinal de todos os outros.
Para cada autenticação, alinhe estes campos:
- Identidade e dispositivo: quem ou o que se conectou, e não apenas um MAC que você espera que seja seu.
- Método: EAP-TLS, PEAP ou uma PSK individual. Um método que você não implantou é um achado de auditoria.
- Local: ponto de acesso, SSID e site.
- Decisão: VLAN e função retornada, ou o motivo da rejeição.
- Hora: carimbo de data/hora contido no intervalo de tempo que você testou.
Nosso log de autenticação foi construído para essa correspondência. Uma única consulta em toda a propriedade mostra cada aceite e rejeição com identidade, dispositivo, estado de inscrição, método, ponto de acesso, SSID, local, VLAN, função, motivo e carimbos de data/hora. Use-o quando um local tiver muitos pontos de acesso e você precisar ver se a mesma falha está em todos os lugares ou apenas em um controlador.
Três padrões que significam que as notas estão incorretas
O motivo não corresponde ao teste. Você enviou uma senha incorreta e o log indica cliente desconhecido. Você testou a coisa errada ou duas falhas se acumularam.
A aceitação nomeia a VLAN padrão. As credenciais funcionaram. O posicionamento não. Não encerre o caso.
O accounting foi iniciado e nunca parou. O registro da sessão está incompleto, portanto você não pode provar que o cliente desconectou quando você pensa que desconectou. Compare o início e o fim com a sessão que você executou, e não com a de um usuário próximo.
Defina um alerta para picos de rejeição durante a janela de testes para que um segredo compartilhado incorreto não pareça que "os usuários digitaram errado". Mantenha o extrato do log junto com as notas de teste. Esse extrato é a evidência de auditoria quando alguém perguntar, semanas depois, o que você provou.
Decida quando o RADIUS está pronto para a implantação
Entre em operação somente quando as evidências atenderem a cinco etapas. Um engenheiro confiante não é uma delas.
- Cada linha da matriz é aprovada em cada tipo de NAS implantado por você, incluindo cada SSID ou política de acesso que pretende manter.
- O failover mantém a mesma VLAN, política e comportamento de revogação do servidor primário. Um segundo servidor que responde com uma função diferente falha nesta etapa.
- Nenhum cenário de falha resulta em acesso aberto. Senha incorreta, diretório inativo, certificado expirado e uma resposta atrasada não devem colocar o usuário em uma rede sem restrições.
- A carga permanece dentro da sua meta de latência no pico, com a taxa de aceitação correspondendo à parcela válida do arquivo de teste.
- Os logs mostram o motivo esperado e VLAN para cada execução que você considerar aprovada.
Segure a implantação mais ampla até que esses cinco pontos sejam verdadeiros em um local real, e não apenas em um laboratório VLAN.
Permitimos que você comprove isso em um primeiro site. Coloque as novas redes aberta, segura e xPSK nos pontos de acesso que esse site já executa, ao lado da rede utilizada hoje, e avalie o resultado nos chamados e nas evidências de auditoria antes de alterar qualquer outro site. Durante esse piloto, o log deve responder a duas perguntas sem a necessidade de uma reunião: quais dispositivos se conectaram em qual VLAN e qual motivo de aceite ou rejeição apareceu com mais frequência.
Expanda apenas quando os chamados e o extrato de auditoria não mostrarem rejeições inesperadas e nenhum dispositivo no segmento errado. Mantenha a matriz como uma suíte de regressão permanente. Execute-a novamente após cada renovação de certificado, atualização de firmware ou alteração de diretório, em relação à mesma linha de base, antes que os usuários vejam a alteração. Para saber como esse site piloto deve ser elaborado, comece pelo design de rede WiFi e teste o design que você pretende manter, não uma SSID temporária que você excluirá na próxima semana.
Purple Access fornece RADIUS em nuvem que coloca cada dispositivo na rede aberta, segura ou xPSK por identidade, com a VLAN e o motivo de rejeição visíveis no log de autenticação. Se você deseja que esse plano de teste seja executado nos pontos de acesso que já possui, comece com um site e analise o resultado antes de avançar com a implantação. Visite Purple Access e defina o primeiro site em um padrão de referência que você possa defender.
