Come testare l'autenticazione RADIUS passo dopo passo
Published
Si trova in una sede con un laptop, un punto di accesso e un server RADIUS che "dovrebbe già essere a posto". Qualcuno ha inviato un ping. La porta UDP 1812 è aperta. Perfino la verifica sulla dashboard ha dato esito positivo. Niente di tutto ciò le dice se il dispositivo di un dipendente finisce sulla VLAN riservata al personale o se un certificato revocato ottiene comunque una sessione.
Capire come testare l'autenticazione RADIUS è una catena di verifiche, non un singolo accesso. Tratti ogni Access-Accept come un'ipotesi. È comunque necessario verificare il metodo, gli attributi, l'indirizzo sorgente e il comportamento della rete quando il server, la directory o il certificato sono errati.
Inizi con una richiesta controllata. Ampli quindi i casi d'uso finché non ci sia più spazio per un falso positivo.
Sommario
- Inviare il primo test con radtest
- Perché Access-Accept non dimostra l'accesso alla rete
- Casi di test necessari per ogni distribuzione RADIUS
- Misurare carico e latenza con radclient
- Percorsi di errore, failover e controlli di sicurezza
- Leggere i log per confermare il risultato di ciascun test
- Stabilire quando RADIUS è pronto per il rilascio
Inviare il primo test con radtest
Il comando che è possibile eseguire nei prossimi cinque minuti è radtest testing password 127.0.0.1 0 testing123. Il manuale radtest di FreeRADIUS lo definisce come un Access-Request controllato con cinque input: nome utente, password, indirizzo del server, NAS-Port e segreto condiviso. Il valore predefinito è PAP. La stessa utilità può anche inviare messaggi CHAP, MS-CHAP o EAP-MD5.
Esegua la baseline prima di modificare qualsiasi altra cosa
- Definire un account di test. Inserire un nome utente e una password noti dove il server possa trovarli. È opportuno disporre di una credenziale che sia possibile digitare senza dover effettuare ricerche in una directory.
- Elencare il client. L'host o il NAS da cui si effettua l'invio deve essere presente in
clients.confcon il segreto che si digiterà. Una sorgente sconosciuta costituisce un errore diverso da una password errata. - Avviare il server in modalità di debug. Ogni pacchetto e motivo di rifiuto dovrebbero essere stampati sul terminale. Un errore silenzioso vanifica l'esecuzione.
- Inviare i cinque input. Nome utente, password, server, NAS-Port, segreto. Un valore NAS-Port pari a
0è sufficiente per questa prima verifica. - Leggere il codice, quindi il motivo. Access-Accept indica che il server ha approvato tali credenziali. Access-Reject indica che le ha rifiutate. L'output di debug distingue tra un segreto condiviso non corretto, un client sconosciuto, credenziali non valide e un errore di politica.
- Ripetere dal NAS. Inviare la medesima richiesta dall'indirizzo dell'access point o dello switch, non solo da localhost. I client vengono comunemente autorizzati combinando l'indirizzo sorgente e il segreto condiviso.
La raggiungibilità non è il risultato finale. Il pacchetto deve arrivare e la decisione di autorizzazione deve essere quella prevista. In caso di accettazione, ispezioni gli attributi restituiti come VLAN, tipo di servizio o indirizzo framed. Un'accettazione che indica la VLAN errata non è un esito positivo, anche quando il codice appare corretto.
Dopo l'accettazione di base, lo stesso manuale elenca otto metodi che possono funzionare per l'account di esempio: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC ed EAP-MD5. Non provarli tutti e otto oggi stesso.
Regola pratica: salvare un messaggio di Access-Accept dall'indirizzo NAS reale e un messaggio di Access-Reject da una password errata. Queste due note rappresentano la linea di base rispetto alla quale verrà valutato ogni caso successivo.
Perché Access-Accept non dimostra l'accesso alla rete
Un test dell'infrastruttura contrassegnato in verde è il falso positivo che non approverei. Spesso dimostra solo che una determinata richiesta ha ottenuto una qualche risposta.
La guida alla risoluzione dei problemi di Meraki RADIUS indica che il test del dashboard utilizza PEAP con MS-CHAPv2. Tale test non riesce, o non fornisce alcuna convalida significativa, per EAP-TLS, poiché l'access point non dispone di un certificato client. La rete wireless basata su certificati deve essere testata con un supplicant reale che contenga il certificato e la catena di attendibilità corretti.
Quattro livelli, quattro domande diverse
Trasporto: verifica se è stata ricevuta risposta. Un timeout non equivale a un rifiuto.
L'autenticazione verifica se la password o il certificato erano validi per tale identità.
L'autorizzazione verifica se la risposta conteneva il valore VLAN, il ruolo o l'ACL che intendeva inviare.
La raggiungibilità verifica se l'endpoint ha ottenuto l'indirizzo previsto, la policy DNS e l'accesso alle risorse che quel segmento dovrebbe consentire.
L'esito positivo su un livello non dice nulla sugli altri tre. La stessa guida Meraki, letta insieme al comportamento di FreeRADIUS EAP, descrive un test EAP-TLS riuscito come uno scambio di più pacchetti Access-Request e Access-Challenge, seguito dall'effettivo accesso alla rete da parte del client. Una singola verifica di connettività non equivale a tale test.
Verifichi il nome server di cui il supplicant si fida, la catena della CA, la scadenza del certificato e l'ora del dispositivo. Il disallineamento dell'ora compromette un certificato valido. Si consideri il caso in cui il laptop aziendale di un dipendente si autentichi e venga posizionato sulla VLAN predefinita anziché nel segmento del personale. L'accettazione era autentica; tuttavia, la collocazione in rete era errata. Questo è l'errore che la maggior parte delle checklist non registra mai.
Mantenere righe separate per gli utenti con password, i dispositivi EAP-TLS, le identità xPSK e le policy basate su directory. Un'accettazione PAP non deve sostituire un'associazione con certificato.
Provi EAP-TLS su un dispositivo di riserva
- Emettere un certificato client di test dalla stessa CA di cui il server si fida.
- Installare il certificato e la catena della CA su un laptop o smartphone di riserva.
- Confermare che il supplicant convalidi il nome server configurato.
- Connettersi e acquisire lo scambio di challenge, non un probe a pacchetto singolo.
- Confermare che la sessione termini sulla VLAN prevista con un accesso effettivo alla rete.
Una visione sintetica di tale scambio rende la traccia (capture) più facile da riconoscere quando la propria traccia è rumorosa.
Casi di test necessari per ogni distribuzione di RADIUS
Credenziali valide possono generare un messaggio di Access-Accept anche se l'utente atterra sulla rete errata. Testare ciascun livello separatamente: gestione delle richieste, autenticazione, attributi di autorizzazione e l'accesso effettivo dell'endpoint. La guida ai test di prestazioni di FreeRADIUS copre sia il carico sia la correttezza. Includere anche i casi negativi: credenziali non valide dovrebbero restituire un Access-Reject, mentre richieste non valide, un NAS non riconosciuto e un segreto condiviso errato non devono consentire un accesso riuscito.
Il flusso di lavoro di radtest è consolidato e utilizza tuttora i medesimi cinque input. Per i metodi incapsulati, testi separatamente il server di autenticazione interno sulla porta UDP 18120. Utilizzi un test interno MS-CHAP quando PEAP è il metodo esterno. Ciò aiuta a isolare se l'errore risiede nello scambio EAP esterno, nella configurazione del certificato o TLS, oppure nella verifica delle credenziali interne.
Un messaggio Access-Accept è un'ipotesi da verificare, non la prova di un corretto accesso alla rete. La guida all'implementazione di FreeRADIUS descrive come un NAS possa ignorare un attributo VLAN non supportato o associarne uno mancante a un attributo VLAN predefinito. Verificare gli attributi restituiti, quindi controllare l'indirizzo dell'endpoint, la VLAN, la lista di controllo degli accessi (ACL), le regole DNS e la raggiungibilità. Il protocollo EAP-MD5 non fornisce il materiale della chiave necessario alla connessione wireless, pertanto un'accettazione EAP-MD5 non costituisce prova della conformità per l'uso senza fili. Utilizzarlo esclusivamente per test limitati su reti cablate.
Stabilire i segmenti previsti prima di eseguire i test di autorizzazione; il controllo dell'accesso WiFi spiega come strutturare tale policy.
Nove righe considerate come requisito minimo
| Caso di test | Come eseguirlo | Risultato previsto |
|---|---|---|
| Accettazione di base | Eseguire radtest con un account di test valido dall'IP del NAS |
Access-Accept con l'attributo VLAN previsto; confermare che l'endpoint arrivi su tale VLAN |
| Password errata | Eseguire radtest con una password non corretta |
Access-Reject con il motivo registrato nei log |
| Segreto condiviso errato | Inviare da un client configurato con un segreto non corrispondente | Nessun Access-Accept; errore del segreto visibile nell'output di debug |
| NAS sconosciuto | Inviare da un indirizzo IP non definito come client | Scartato o rifiutato e registrato nei log |
| Dispositivo EAP-TLS valido | Connettere un supplicant reale con un certificato valido e una catena attendibile | Access-Accept e la VLAN corretta per il relativo gruppo; confermare l'accesso alla rete dal dispositivo |
| Certificato scaduto o revocato | Connettere un dispositivo con un certificato scaduto o revocato | Access-Reject, senza fallback su una rete predefinita |
| Modifica del gruppo di directory | Spostare l'utente di test in un altro gruppo, quindi eseguire nuovamente l'autenticazione | La VLAN o il ruolo cambiano per corrispondere al nuovo gruppo, oppure l'accesso viene rifiutato |
| Server primario non disponibile | Bloccare la porta UDP 1812 verso il primario o interromperlo | Failover sul secondario entro il tempo di timeout, con applicazione della stessa politica |
| Avvio e arresto dell'accounting | Avviare una sessione, quindi terminarla | I record di avvio e arresto corrispondono alla sessione |
Per ogni riga, registrare l'arrivo della richiesta, il codice di risposta, la latenza di andata e ritorno, la policy selezionata, gli attributi restituiti e l'avvio e l'arresto dell'accounting. Ripetere ciascun test per individuare eventuali perdite UDP intermittenti. Una singola esecuzione corretta può far sfuggire un VLAN errato o una decisione di policy incoerente.
Un'accettazione che colloca il client sulla rete errata è da considerarsi un test fallito.
Misurare carico e latenza con radclient
Un'accettazione silenziosa nasconde le code. I test di volume richiedono uno strumento integrato per i processi batch, non un altro accesso singolo.
- Creare un file di autenticazione composto da nomi utente e password casuali. Combinare voci valide e non valide affinché i rifiuti vengano conteggiati anziché essere considerati rumore.
- Inviare il file e cronometrare il batch tramite il comando Unix
timementreradclientaziona il server. - Registrare i conteggi grezzi. Richieste totali, accettazioni, rifiuti, timeout, risposte di errore e tempo trascorso.
- Calcolare i tassi. Il tasso di accettazione deve corrispondere alla quota valida del file. Il tasso di rifiuto deve corrispondere alla quota non valida. Rilevare inoltre la latenza media e i percentili.
- Ripetere il test nelle ore di punta. Un'ondata di accessi mattutini o l'inizio dell'orario scolastico evidenzieranno accodamenti che una prova di laboratorio in pausa pranzo non mostrerà mai.
| Metrica | Come calcolarla | Obiettivo |
|---|---|---|
| Richieste totali | Conteggio delle righe inviate dal file di autenticazione | Pari alla lunghezza del file |
| Tasso di accettazione | Accettazioni divise per le richieste totali | Corrisponde alla quota valida del file |
| Tasso di rifiuto | Rifiuti divisi per le richieste totali | Corrisponde alla quota non valida del file |
| Timeout ed errori | Conteggio delle mancate risposte e delle risposte di errore nell'esecuzione | Zero in condizioni di funzionamento corretto |
| Latenza media | Tempo di risposta medio per tutte le richieste | Entro l'obiettivo di latenza nei momenti di picco |
| Tempo trascorso | Output in tempo Unix per l'intero batch | Stabile tra le varie esecuzioni |
Separi il tunnel dallo store degli account
Se il tasso di accettazione è inferiore alla quota valida, non attribuisca la colpa al "carico" finché non sa quale metà ha riscontrato l'errore. Per PEAP, testi il metodo interno in modo autonomo inviando una richiesta MS-CHAP al server interno. Un'accettazione interna con un'associazione esterna non riuscita indica problemi con i certificati o con le impostazioni TLS. Un handshake esterno che si interrompe durante la verifica interna indica problemi con l'archivio account, l'hash della password o il gruppo previsto dalla politica.
Mantenere queste tempistiche nello stesso registro dei risultati funzionali. Una successiva modifica del firmware o della directory dovrà essere confrontata con quella linea di base e non con la sensazione che "sembrasse più lento".
Se i timeout aumentano solo nei momenti di picco, correggere la capacità o il percorso prima di aggiungere altre sedi. Un server corretto ma lento continuerà a causare errori sui client che interrompono la connessione per primi.
Percorsi di errore, failover e verifiche di sicurezza
Uno scambio funzionante può comunque non essere sicuro. La risoluzione dei problemi che si limita a verificare se UDP 1812 ha ottenuto una risposta si interrompe troppo presto.
Il bollettino di sicurezza 2025 di Juniper descrive l'esposizione a Blast-RADIUS nel Response Authenticator dell'RFC 2865. Un malintenzionato locale in grado di modificare il traffico può potenzialmente trasformare una risposta valida in un'altra risposta tramite una collisione di prefissi scelti MD5. L'esito "Autenticazione riuscita" non è una prova del fatto che la distribuzione sia protetta.
Verifiche da includere nella stessa sessione del failover
Proteggere il percorso laddove la piattaforma lo consenta. Confermare che la manipolazione sul percorso sia bloccata e che la convalida di Message-Authenticator sia applicata sui pacchetti che la richiedono.
Disattivi i metodi deboli. I tipi EAP obsoleti devono essere disabilitati, non lasciati attivi "per sicurezza". Se sta ancora scegliendo tra metodi esterni basati su certificato o su password, li confronti in EAP-TLS vs PEAP prima di lasciarli entrambi abilitati.
Simulare intenzionalmente un guasto del server. Ciascuno scenario sottostante deve mostrare il fail-closed previsto o un fallback controllato, oltre a una riga di registro, un avviso e un'esperienza utente che sia possibile spiegare al responsabile della sede.
| Scenario di errore | Come attivarlo | Condizione di superamento |
|---|---|---|
| Timeout | Bloccare UDP 1812 verso il server | Fail-closed o fallback controllato, registrato nei log e segnalato tramite avviso |
| Access-Reject | Utilizzare una password errata | Accesso negato senza rete di fallback |
| Certificato scaduto | Dispositivo con un certificato scaduto | Access-Reject senza VLAN predefinita |
| Certificato revocato | Dispositivo con un certificato revocato | Access-Reject senza VLAN predefinita |
| IP sorgente NAS sconosciuto | Inviare da un indirizzo non definito | Scartato o rifiutato e registrato nei log |
| Secret condiviso non corretto | Mancata corrispondenza del secret sul client | Nessun Access-Accept ed errore del secret nell'output di debug |
| Directory non raggiungibile | Interrompere la connettività della directory | Rifiutato o fallback controllato in base alla policy |
| Risposta di autorizzazione ritardata | Aggiungere ritardo alla risposta di autorizzazione | Timeout gestito senza accesso aperto |
Cosa deve preservare il failover regionale
La risposta di un altro server non equivale alla coerenza delle politiche. Quando arresta il primario, confronti VLAN, limiti di larghezza di banda, stato di revoca e attributi di audit del backup rispetto al primario. Un ospite che effettua il failover in un segmento riservato al personale rappresenta un test fallito, anche se la connessione è stata rapida.
Contrassegnare qualsiasi scenario che ripieghi sull'accesso aperto come non riuscito, indipendentemente dal fatto che l'utente vada online o meno. Scrivere ciascun risultato nello stesso registro di test della linea di base funzionale, in modo che una successiva modifica al failover risulti evidente.
Leggere i log per confermare ogni risultato del test
Ogni test deve lasciare una traccia che possa essere associata a un ID test o a un account noto. Su un'infrastruttura complessa, tale etichetta consente di trovare la propria esecuzione senza dover scorrere le attività mattutine di tutti gli altri.
Per ciascuna autenticazione, allinei questi campi:
- Identità e dispositivo: chi o cosa si è connesso, non solo un indirizzo MAC che si spera sia il Suo.
- Metodo: EAP-TLS, PEAP o una PSK individuale. Un metodo non distribuito costituisce un rilievo di audit.
- Luogo: punto di accesso, SSID e sede.
- Decisione: VLAN e ruolo restituiti, oppure il motivo del rifiuto.
- Ora: timestamp compreso nella finestra temporale testata.
Il nostro registro di autenticazione è progettato per questo tipo di corrispondenza. Una singola query su tutta la struttura mostra ogni accettazione e rifiuto con identità, dispositivo, stato di registrazione, metodo, punto di accesso, SSID, sede, VLAN, ruolo, motivo e marcatori temporali. Può utilizzarlo quando una sede ha molti punti di accesso e occorre verificare se lo stesso errore si verifica ovunque o solo su un controller.
Tre modelli che indicano che le note sono errate
Il motivo non corrisponde al test. È stata inviata una password errata e il registro indica un client sconosciuto. È stato testato l'elemento sbagliato oppure si sono sovrapposti due errori.
L'accettazione indica il valore predefinito VLAN. Le credenziali hanno funzionato. Il posizionamento no. Non chiuda il caso.
L'accounting è iniziato e non si è mai arrestato. Il registro di sessione è incompleto, pertanto non è possibile dimostrare che il client si sia disconnesso quando previsto. Confrontare l'avvio e l'arresto con la sessione eseguita, non con quella di un utente vicino.
Impostare un avviso per i picchi di rifiuto durante la finestra di test, in modo che un secret condiviso errato non sembri che "gli utenti abbiano digitato male". Conservare l'estratto del registro insieme alle note del test. Tale estratto costituisce la prova di audit quando qualcuno chiederà, a distanza di settimane, cosa si è dimostrato.
Stabilire quando RADIUS è pronto per il rollout
Proceda con la messa in funzione solo quando le prove soddisfano cinque criteri di verifica. La certezza di un tecnico non è tra questi.
- Ogni riga della matrice ha esito positivo su ciascun tipo di NAS distribuito, inclusa qualsiasi SSID o regola di accesso che si intende mantenere.
- Il failover mantiene gli stessi comportamenti di VLAN, regola e revoca del primario. Un secondo server che risponde con un ruolo diverso non supera questo controllo.
- Nessuno scenario di errore comporta un'apertura non protetta. Password errata, directory inaccessibile, certificato scaduto e risposta ritardata non devono consentire l'accesso dell'utente a una rete senza restrizioni.
- Il carico rimane entro l'obiettivo di latenza nei momenti di picco, con un tasso di accettazione corrispondente alla quota valida del file di test.
- I log mostrano il motivo previsto e l'attributo VLAN per ogni esecuzione considerata superata.
Sospenda il rollout su più ampia scala finché queste cinque condizioni non saranno verificate su un sito reale, e non solo in un laboratorio VLAN.
Le consentiamo di verificare prima questa procedura in una singola sede. Configuri le nuove reti aperte, sicure e xPSK sui punti di accesso già attivi in quella sede, accanto alla rete attualmente in uso, e valuti il risultato in base ai ticket e alle evidenze di audit prima di modificare qualsiasi altra sede. Durante il pilot, il registro deve rispondere a due domande senza dover organizzare una riunione: quali dispositivi si sono connessi tramite quale VLAN e quale motivo di accettazione o rifiuto si è verificato più frequentemente.
Procedere con l'estensione solo quando i ticket e l'estratto dell'audit non mostrano rifiuto inattesi e nessun dispositivo sul segmento errato. Mantenere la matrice come suite di regressione permanente. Eseguirla nuovamente dopo ogni rinnovo del certificato, aggiornamento del firmware o modifica della directory, rispetto alla stessa baseline, prima che gli utenti vedano la modifica. Per informazioni su come tracciare il sito pilota, iniziare dalla progettazione della rete WiFi e testare la struttura che si intende mantenere, non una soluzione temporanea SSID che verrà eliminata la settimana successiva.
Purple Access offre RADIUS in cloud per collocare ogni dispositivo sulla rete aperta, sicura o xPSK in base all'identità, rendendo visibili la VLAN e il motivo del rifiuto nel registro di autenticazione. Se desidera eseguire questo piano di test sui punti di accesso già in uso, inizi da una sola sede ed esamini il risultato prima di procedere con l'implementazione generale. Visiti la pagina di Purple Access e imposti la prima sede su una baseline difendibile.
