Rifiuto RADIUS contro nessuna risposta: quando parte l’accesso locale

Mantenere un account locale di emergenza non lo rende una seconda possibilità per ogni accesso rifiutato. Nel modello AAA di Cisco IOS e IOS XE, quel database viene consultato solo quando il metodo precedente fallisce in un modo preciso, e un server RADIUS che risponde con un rifiuto non è fallito in quel modo. L’account locale copre un metodo irraggiungibile, non uno rifiutato. Credere il contrario trasforma una decisione di policy in una caccia a un guasto del server che non esiste.

Perché l’elenco dei metodi sembra una scala

Una riga come aaa authentication login default group radius local si legge da sinistra a destra, e la maggior parte delle persone la legge come prova RADIUS, poi prova il database locale. La sintassi invita a quella lettura perché un elenco è una sequenza. La semantica è più stretta: l’elenco nomina metodi di autenticazione, e la regola per passare da uno al successivo dipende dal risultato del metodo precedente, non dal dare all’utente un altro tentativo.

Un metodo che restituisce un errore e un metodo che restituisce un fallimento portano qui a risultati diversi. Il rifiuto è una risposta, perché il server ha elaborato le credenziali e ha detto no, e l’elenco si ferma lì. Un server irraggiungibile, una richiesta scaduta o una risposta che non può essere validata è il caso che lascia girare il metodo successivo, e solo dove la gestione dei guasti della piattaforma è configurata così. Per questo il consiglio classico di aggiungere local funziona durante le interruzioni e non fa nulla con password sbagliate. Leggete invece l’elenco come due domande: quale metodo risponde, e che cosa la piattaforma considera una risposta.

Separate l’elenco dei metodi dal gruppo di server

L’elenco dei metodi è uno strato e il gruppo di server è un altro. La parola chiave group radius nomina un gruppo il cui ordine interno, i tentativi, i timeout e il rilevamento del server morto appartengono al gruppo, mentre un metodo locale è uno strato sopra. Regolare qualsiasi cosa dentro il gruppo non può quindi trasformare un rifiuto in un fallback. Confermate a quale elenco il servizio fa realmente riferimento prima di modificare uno dei due strati.

Stampate la configurazione AAA e leggete l’elenco verso cui punta il servizio, non il valore predefinito che ricordate di aver scritto. Fatelo dal dispositivo su cui il servizio termina davvero.

show running-config | section aaa
show radius server-group RAD-GRP
show aaa servers

La tabella dei server riporta lo stato e i contatori di ogni voce, il che vi dice se il gateway ha raggiunto il server durante il tentativo. Un server segnato come attivo con un contatore di richieste in crescita ha risposto, quindi l’accesso fallito è una decisione e non un problema di connettività.

Leggete la risposta prima del registro

Il codice di risposta nomina l’esito e implica il proprio passo successivo. Access-Reject significa che il backend ha preso una decisione, quindi la prova utile è la policy che ha corrisposto e lo stato dell’account dietro di essa. Access-Challenge significa che lo scambio vuole un altro passo supportato, come un secondo fattore, e un fallback locale salterebbe in silenzio qualcosa che la policy richiede.

Riproducete un tentativo con un account di test designato così che la risposta e il record del backend possano essere confrontati allo stesso timestamp. Usate una credenziale che vi è consentito far fallire.

test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authentication

Una voce di client RADIUS mancante o non riconosciuta è una causa comune di timeout silenzioso, perché il server riceve la richiesta, non trova alcuna definizione di client corrispondente e la scarta senza rispondere. Un disallineamento del segreto condiviso di solito sembra anch’esso un timeout, perché la risposta non supera la validazione e viene scartata. Niente di tutto ciò somiglia ad Access-Reject, e niente di tutto ciò si ripara aggiungendo un account locale. Controllate la definizione del client e il segreto su entrambi i lati prima di toccare l’elenco dei metodi.

Perché l’account locale non ha mai dimostrato nulla

Un account che sta dopo un gruppo nell’elenco dimostra solo che qualcuno ha pianificato un’interruzione. Non dice nulla sul fatto che il piano funzioni, perché il caso che lo mette alla prova è il caso che nessuno esercita: il server ha smesso di rispondere. Un accesso locale che non viene mai raggiunto in funzionamento normale può portare una password scaduta o uno stato bloccato per mesi senza che nessuno lo noti.

L’accesso di emergenza è una decisione di progettazione, non un effetto collaterale della configurazione. Dategli un proprio account limitato, un proprio responsabile e una procedura di ripristino scritta, e inserite la rotazione del segreto condiviso in quella procedura. Mantenere una password locale con lo stesso nome per ogni utente centrale è lo schema che reintroduce in silenzio l’accesso che pensavate di aver rimosso.

Il test che conta è deliberato, e interromperà gli accessi mentre è in esecuzione. È esattamente per questo che appartiene a una finestra pianificata con il passo di ripristino scritto per primo.

Verificate il percorso di fallback durante una finestra di manutenzione

Ordinate il test in modo da non rimuovere mai l’ultima via d’ingresso. Confermate prima un percorso di gestione indipendente, poi l’accesso normale consentito, poi un rifiuto deliberato, poi il comportamento di interruzione approvato. Questi quattro casi hanno esiti attesi diversi, e fonderli in un unico test è il modo in cui le persone si chiudono fuori da un dispositivo di cui hanno ancora bisogno.

Eseguite ogni verifica da una sessione console o da un percorso fuori banda, così un errore non possa chiudere la sessione in cui state lavorando. La console è l’unico percorso che non dipende dal componente in prova.

show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy

Poi ripristinate la configurazione precedente e confermate che i contatori si muovono di nuovo al prossimo accesso reale. Se il rifiuto deliberato produce un accesso locale invece di un rifiuto, allora l’elenco o la gestione dei guasti non è ciò che credevate, e quella scoperta vale più dell’interruzione con cui avete iniziato. Scrivete il risultato nel registro delle modifiche accanto ai nomi degli account e alla data del test.