Como testar a autenticação RADIUS passo a passo
Published
Está num local com um portátil, um ponto de acesso e um servidor RADIUS que "já deveria estar a funcionar corretamente". Alguém fez um ping. A porta UDP 1812 está aberta. Até um teste no painel de controlo deu um resultado positivo. Nada disso lhe diz se o dispositivo de um funcionário vai parar à VLAN dos funcionários ou se um certificado revogado continua a obter uma sessão.
Saber como testar a autenticação RADIUS é uma cadeia de provas, não um único início de sessão. Trate cada Access-Accept como uma hipótese. É necessário verificar o método, os atributos, o endereço de origem e o comportamento da rede quando o servidor, o diretório ou o certificado falharem.
Comece com um pedido controlado. Em seguida, alargue os casos até que uma aprovação falsa não tenha onde se esconder.
Índice
- Envie o seu primeiro teste com o radtest
- Por que motivo o Access-Accept não prova o acesso à rede
- Casos de teste que todas as implementações de RADIUS necessitam
- Meça a carga e a latência com o radclient
- Caminhos de falha, failover e verificações de segurança
- Leia os registos para confirmar o resultado de cada teste
- Decida quando o RADIUS está pronto para a implementação
Envie o seu primeiro teste com o radtest
O comando que 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 utilizador, palavra-passe, endereço do servidor, NAS-Port e segredo partilhado. O PAP é a predefiniçã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 utilizador e uma palavra-passe conhecidos no local onde o servidor os possa localizar. É recomendável uma credencial que possa introduzir sem ter de procurar num diretório.
- Liste o cliente. O anfitrião ou NAS a partir do qual efetua o envio deve estar listado em
clients.confcom o segredo que irá introduzir. Uma origem desconhecida é uma falha diferente de uma palavra-passe incorreta. - Inicie o servidor no modo de depuração. Todos os pacotes e motivos de rejeição devem ser apresentados no terminal. Uma falha silenciosa invalida a execução.
- Envie as cinco entradas. Nome de utilizador, palavra-passe, servidor, NAS-Port e segredo. Um NAS-Port de
0é suficiente para esta primeira validação. - Leia o código e, em seguida, o motivo. Access-Accept significa que o servidor aprovou essas credenciais. Access-Reject significa que as recusou. A saída de depuração distingue entre um segredo partilhado incorreto, um cliente desconhecido, credenciais inválidas e uma falha de política.
- Repita a partir do NAS. Origine o mesmo pedido a partir do ponto de acesso ou do endereço do switch, e não apenas a partir do localhost. Os clientes são habitualmente autorizados pelo endereço de origem e pelo segredo partilhado em conjunto.
A alcançabilidade não é o resultado final. O pacote tem de chegar e a decisão de autorização tem de ser a esperada. Numa aceitação, inspecione os atributos retornados, tais como VLAN, tipo de serviço ou endereço atribuído. Uma aceitação que indique 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 testar os oito hoje.
Regra prática: Guarde um Access-Accept do endereço NAS real e um Access-Reject de uma palavra-passe incorreta. Essas duas notas são a linha de base em relação à qual todos os casos posteriores serão avaliados.
Por que razão o Access-Accept não prova o acesso à rede
Um teste de infraestrutura com resultado positivo falso é uma aprovação falsa que eu não aprovaria. Muitas vezes, apenas mostra que alguma resposta foi obtida para algum pedido.
O guia de resolução de problemas da Meraki RADIUS indica que o teste do seu painel de controlo utiliza PEAP com MS-CHAPv2. Esse teste falha, ou não fornece qualquer validação significativa, para EAP-TLS, porque o ponto de acesso não possui um certificado de cliente. A rede sem fios baseada em certificados tem de ser testada com um suplicante real que possua o certificado e a cadeia de confiança corretos.
Quatro camadas, quatro questões diferentes
Transporte questiona se algo respondeu. Um tempo limite esgotado não é uma rejeição.
A autenticação questiona se a palavra-passe ou o certificado eram válidos para essa identidade.
A autorização questiona se a resposta continha a VLAN, função ou ACL que pretendia enviar.
A acessibilidade verifica se o ponto final obteve o endereço esperado, a política de DNS e o acesso aos recursos que esse segmento deve permitir.
A aprovação numa camada não diz nada sobre as outras três. As mesmas orientações sobre Meraki, lidas em conjunto com o comportamento do FreeRADIUS EAP, descrevem um teste de EAP-TLS bem-sucedido como uma troca de múltiplos pacotes de Access-Request e Access-Challenge, seguida do acesso real do cliente à rede. Um único teste de conetividade não é esse teste.
Verifique o nome do servidor em que o suplicante confia, a cadeia da AC, a expiração do certificado e o relógio do dispositivo. O desvio do relógio invalida um bom certificado. Suponhamos que o portátil de um colaborador se autentica e depois fica no VLAN predefinido em vez do segmento de colaboradores. O Accept foi genuíno. O posicionamento na rede estava errado. Essa é a falha que a maioria das listas de verificação nunca regista.
Mantenha linhas separadas para utilizadores com palavra-passe, dispositivos EAP-TLS, identidades xPSK e políticas baseadas em diretórios. Uma aceitação PAP não deve substituir uma associação por certificado.
Teste o EAP-TLS num dispositivo suplente
- Emita um certificado de cliente de teste a partir da mesma AC em que o servidor confia.
- Instale o certificado e a cadeia da AC num portátil ou telemóvel suplente.
- Confirme que o suplicante valida o nome do servidor que configurou.
- Ligue-se e capture a troca de desafio, e não um teste de pacote único.
- Confirme que a sessão termina no VLAN previsto com acesso real à rede.
Uma vista curta dessa troca torna a captura mais fácil de reconhecer quando a sua própria rastreabilidade tem ruído.
Casos de teste de que todas as implementações de RADIUS precisam
Uma credencial válida pode produzir um Access-Accept enquanto o utilizador vai parar à rede errada. Teste cada camada separadamente: processamento de pedidos, 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 como a exatidão. Inclua também casos negativos: credenciais inválidas devem retornar Access-Reject, enquanto pedidos malformados, um NAS não reconhecido e um segredo partilhado incorreto não devem produzir um início de sessão bem-sucedido.
O fluxo de trabalho radtest está estabelecido há muito tempo e continua a utilizar os mesmos cinco dados de entrada. Para métodos com túnel, teste o servidor de autenticação interno separadamente na porta UDP 18120. Utilize um teste interno MS-CHAP quando o PEAP for o método externo. Isto ajuda a isolar se uma falha se situa na troca EAP externa, na configuração do certificado ou TLS, ou na verificação de credenciais interna.
Um Access-Accept é uma hipótese a verificar, 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 em falta para um VLAN predefinido. Verifique os atributos devolvidos e, em seguida, confirme o endereço do ponto de extremidade, VLAN, ACL, política de DNS e acessibilidade. O EAP-MD5 não fornece o material de chave necessário para redes sem fios, pelo que uma aceitação EAP-MD5 não é prova de prontidão para redes sem fios. Utilize-o apenas para testes limitados em redes com fios.
Decida os segmentos pretendidos antes de executar os testes de autorização; o WiFi controlo de acesso explica como estruturar essa política.
Nove linhas que contam como o mínimo
| Caso de teste | Como executar | Resultado previsto |
|---|---|---|
| Aceitação de referência | Execute o radtest com uma conta de teste válida a partir do IP do NAS |
Access-Accept com o atributo VLAN previsto; confirme que o ponto de extremidade fica nesse VLAN |
| Palavra-passe incorreta | Execute o radtest com uma palavra-passe incorreta |
Access-Reject com o motivo registado em log |
| Segredo partilhado incorreto | Envie a partir de um cliente configurado com um segredo divergente | Sem 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 | Ignorado ou rejeitado e registado em log |
| Dispositivo EAP-TLS válido | Ligue um suplicante real com um certificado válido e uma cadeia de confiança | Access-Accept e o VLAN correto para o seu grupo; confirme o acesso à rede a partir do dispositivo |
| Certificado expirado ou revogado | Ligue um dispositivo com um certificado expirado ou revogado | Access-Reject, sem alternância para uma rede predefinida |
| Alteração de grupo de diretório | Mova o utilizador de teste para outro grupo e volte a autenticar | O 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 | Recuperação de falhas (failover) para o secundário dentro do tempo limite, com a mesma política aplicada |
| Início e fim de contabilidade (accounting) | Inicie uma sessão e, em seguida, termine-a | Os registos de início e fim correspondem à sessão |
Para cada linha, registe a chegada do pedido, o código de resposta, a latência de ida e volta, a política selecionada, os atributos devolvidos e o início e fim de contabilização (accounting). Repita cada teste para detetar perdas intermitentes de UDP. Uma única execução limpa pode deixar passar um VLAN incorreto ou uma decisão de política inconsistente.
Uma aceitação que coloque o cliente na rede errada é um teste com falha.
Meça a carga e a latência com o radclient
Uma aceitação silenciosa oculta o enfileiramento. Os testes de volume precisam de uma ferramenta concebida para um lote e não para mais uma iniciação de sessão individual.
- Crie um ficheiro de autenticação com nomes de utilizador e palavras-passe 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 ficheiro e cronometre o lote com o comando Unix
timeenquanto oradclientopera o servidor. - Registe as contagens brutas. Total de pedidos, aceitações, rejeições, timeouts, respostas de erro e tempo decorrido.
- Calcule as taxas. A taxa de aceitação deve corresponder à quota válida do ficheiro. A taxa de rejeição deve corresponder à quota inválida. Obtenha também a latência média e o percentil.
- Repita na hora de ponta. Um registo matinal ou o início das aulas mostrarão um enfileiramento que uma execução de laboratório à hora de almoço nunca mostrará.
| Métrica | Como calcular | Meta |
|---|---|---|
| Total de pedidos | Contagem de linhas enviadas a partir do ficheiro de autenticação | Igual ao tamanho do ficheiro |
| Taxa de aceitação | Aceitações divididas pelo total de pedidos | Corresponde à quota válida do ficheiro |
| Taxa de rejeição | Rejeições divididas pelo total de pedidos | Corresponde à quota inválida do ficheiro |
| Timeouts e erros | Contagem de respostas sem resposta e de erro na execução | Zero num percurso limpo |
| Latência média | Tempo médio de resposta em todos os pedidos | Dentro da sua meta de latência no pico |
| Tempo decorrido | Resultado do tempo Unix para todo o lote | Estável em execuções repetidas |
Separe o túnel do repositório de contas
Se a taxa de aceitação for inferior à quota válida, não culpe a "carga" até saber qual metade falhou. Para o PEAP, teste o método interno de forma autónoma com um pedido MS-CHAP no servidor interno. Uma aceitação interna com uma associação externa com falhas aponta para certificados ou definições TLS. Um handshake externo que falha na verificação interna aponta para o repositório de contas, o hash da palavra-passe ou o grupo que a política prevê.
Mantenha estes tempos no mesmo registo que os resultados funcionais. Uma alteração posterior de firmware ou de diretório deve ser comparada com essa linha de base, e não com uma sensação de que "pareceu mais lento."
Se os tempos de espera limite (timeouts) aumentarem apenas nas horas de ponta, corrija a capacidade ou o caminho antes de adicionar locais. Um servidor correto, mas lento, continuará a falhar com clientes que desistem primeiro.
Caminhos de falha, comutação por falha e verificações de segurança
Uma troca funcional ainda pode ser insegura. A resolução de problemas que apenas pergunta se o UDP 1812 obteve resposta para demasiado cedo.
O boletim de segurança de 2025 da Juniper descreve a exposição a Blast-RADIUS no Autenticador de Resposta do RFC 2865. Um atacante local que consiga modificar o tráfego pode potencialmente transformar uma resposta válida noutra resposta através de uma colisão de prefixo escolhido de MD5. "Autenticação bem-sucedida" não é prova de que a implementação esteja protegida.
Verificações que devem pertencer à mesma execução que a de comutação por falha
Proteja o caminho onde a plataforma o permitir. Confirme que a manipulação no caminho está bloqueada e que a validação do Message-Authenticator é imposta nos pacotes que a exigem.
Desative métodos fracos. Os tipos de EAP obsoletos devem ser desativados e não mantidos "por precaução". Se ainda estiver a decidir entre métodos externos baseados em certificado ou em palavra-passe, compare-os em EAP-TLS vs PEAP antes de deixar ambos ativos.
Simule a falha do servidor intencionalmente. Cada cenário abaixo deve mostrar a falha em modo fechado (fail-closed) ou o recurso a uma alternativa controlada pretendida, além de uma linha de registo, um alerta e uma experiência de utilizador que possa explicar a um gestor de instalações.
| Cenário de falha | Como acionar | Condição de aprovação |
|---|---|---|
| Tempo limite excedido (Timeout) | Bloquear UDP 1812 para o servidor | Falha segura (fail closed) ou alternativa controlada, registada em log e com alerta enviado |
| Access-Reject | Utilizar uma palavra-passe incorreta | Acesso negado sem rede de alternativa (fallback) |
| Certificado expirado | Dispositivo com um certificado expirado | Access-Reject sem VLAN por omissão |
| Certificado revogado | Dispositivo com um certificado revogado | Access-Reject sem VLAN por omissão |
| IP de origem NAS desconhecido | Enviar a partir de um endereço não definido | Descartado ou rejeitado e registado em log |
| Segredo partilhado incorreto | Segredo incompatível no cliente | Sem Access-Accept e erro de segredo na saída de depuração |
| Diretório inacessível | Interromper a conetividade com o diretório | Recusado ou alternativa controlada por política |
| Resposta de autorização atrasada | Adicionar atraso à resposta de autorização | Tempo limite gerido sem acesso aberto |
O que a comutação por falha regional tem de preservar
A resposta de outro servidor não significa consistência de políticas. Quando parar o servidor principal, compare a VLAN, os limites de largura de banda, o estado de revogação e os atributos de auditoria do servidor de cópia de segurança com os do principal. Um convidado que mude para um segmento de funcionários durante a transição representa um teste falhado, mesmo que a ligação tenha sido rápida.
Marque qualquer cenário que recorra a acesso aberto como falhado, quer o utilizador fique online ou não. Escreva cada resultado no mesmo registo de testes da linha de base funcional, para que uma alteração posterior no failover seja evidente.
Leia os registos para confirmar cada resultado de teste
Cada teste deve deixar um rasto que possa associar a um ID de teste ou a uma conta conhecida. Numa infraestrutura movimentada, essa etiqueta é a forma de encontrar a sua execução sem ter de percorrer a manhã de todos os outros.
Para cada autenticação, alinhe estes campos:
- Identidade e dispositivo: quem ou o que se associou, não apenas um MAC que espera que seja seu.
- Método: EAP-TLS, PEAP ou uma PSK individual. Um método que não implementou é uma constatação.
- Local: ponto de acesso, SSID e localidade.
- Decisão: VLAN e função devolvidas, ou o motivo de rejeição.
- Hora: marca temporal que se situa dentro da janela que testou.
O nosso registo de autenticação foi concebido para essa correspondência. Uma única consulta em toda a infraestrutura mostra todas as aceitações e rejeições com identidade, dispositivo, estado de inscrição, método, ponto de acesso, SSID, local, VLAN, função, motivo e marcas de data/hora. Utilize-o quando um local tiver muitos pontos de acesso e precisar de ver se a mesma falha ocorre em todo o lado ou apenas num controlador.
Três padrões que indicam que as notas estão erradas
O motivo não corresponde ao teste. Enviou uma palavra-passe incorreta e o registo indica cliente desconhecido. Testou a coisa errada ou ocorreram duas falhas simultâneas.
A aceitação especifica a VLAN predefinida. As credenciais funcionaram. A colocação não. Não feche o caso.
A contabilização começou e nunca parou. O registo da sessão está incompleto, pelo que não pode provar que o cliente saiu quando julga que o fez. Compare o início e o fim com a sessão que executou, e não com a de um utilizador próximo.
Defina um alerta para picos de rejeição durante a janela de teste, para que um segredo partilhado incorreto não pareça que "os utilizadores introduziram mal os dados." Guarde o extrato do registo junto com as notas do teste. Esse extrato é a evidência de auditoria quando alguém perguntar, semanas mais tarde, o que provou.
Decida quando o RADIUS está pronto para implementação
Avance para a produção apenas quando as evidências cumprirem cinco etapas. Um engenheiro confiante não é uma delas.
- Cada linha da matriz passa em cada tipo de NAS que implementar, incluindo cada SSID ou política de acesso que pretenda manter.
- O failover mantém o mesmo VLAN, política e comportamento de revogação do servidor primário. Um segundo servidor que responda com uma função diferente falha nesta etapa.
- Nenhum cenário de falha resulta em acesso aberto. Palavra-passe errada, diretório inativo, certificado expirado e uma resposta atrasada não podem colocar o utilizador numa rede sem restrições.
- A carga mantém-se dentro da sua meta de latência no pico, com a taxa de aceitação a corresponder à quota válida do ficheiro de teste.
- Os registos mostram o motivo esperado e o VLAN para cada execução que considere aprovada.
Aguarde com o alargamento da implementação até que essas cinco condições se confirmem num local real, e não apenas num laboratório VLAN.
Permitimos-lhe provar isto primeiro numa localidade. Coloque as novas redes aberta, segura e xPSK nos pontos de acesso que essa localidade já executa, ao lado da rede que utiliza atualmente, e avalie o resultado com base em pedidos de suporte e evidências de auditoria antes de alterar qualquer outra localidade. Durante esse piloto, o registo deve responder a duas perguntas sem necessidade de uma reunião: que dispositivos se associaram em que VLAN e qual o motivo de aceitação ou rejeição apresentado com mais frequência.
Expanda apenas quando os pedidos de suporte e o extrato de auditoria não mostrarem rejeições inesperadas nem dispositivos no segmento errado. Mantenha a matriz como um conjunto de testes 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 utilizadores vejam a alteração. Quanto à forma como esse local piloto deve ser desenhado, comece a partir do WiFi design de rede e teste o design que pretende manter, e não um SSID temporário que irá eliminar na próxima semana.
Purple Access concede-lhe o RADIUS em nuvem que coloca cada dispositivo na rede aberta, segura ou xPSK por identidade, com o VLAN e o motivo de rejeição visíveis no registo de autenticação. Se pretende que esse plano de testes seja executado nos pontos de acesso que já possui, comece por uma localidade e leia o resultado antes de avançar. Visite Purple Access e coloque a primeira localidade numa linha de base sustentável.
