Respingere RADIUS versus niciun răspuns: când funcționează autentificarea locală
AAA tratează o respingere și un server inaccesibil ca rezultate diferite. Calea de rezervă acoperă doar al doilea caz, așa că citiți mai întâi lista de metode și codul de răspuns.
Păstrarea unui cont local de urgență nu îl face o a doua șansă pentru fiecare autentificare respinsă. În modelul AAA din Cisco IOS și IOS XE, acea bază de date este consultată doar când metoda anterioară eșuează într-un anumit mod, iar un server RADIUS care răspunde cu o respingere nu a eșuat în acel mod. Contul local acoperă o metodă inaccesibilă, nu una respinsă. A crede altfel transformă o decizie de politică într-o vânătoare a unei defecțiuni de server care nu există.
De ce lista de metode arată ca o scară
O linie precum aaa authentication login default group radius local se citește de la stânga la dreapta, iar majoritatea oamenilor o citesc ca încearcă RADIUS, apoi încearcă baza de date locală. Sintaxa invită la această citire pentru că o listă este o secvență. Semantica este mai îngustă: lista numește metode de autentificare, iar regula de trecere de la una la următoarea depinde de rezultatul metodei anterioare, nu de a-i da utilizatorului o altă încercare.
O metodă care returnează o eroare și o metodă care returnează un eșec duc aici la rezultate diferite. Respingerea este un răspuns, pentru că serverul a procesat datele de autentificare și a spus nu, iar lista se oprește acolo. Un server inaccesibil, o cerere expirată sau un răspuns care nu poate fi validat este cazul care lasă următoarea metodă să ruleze, și doar acolo unde tratarea eșecurilor a platformei este configurată astfel. De aceea sfatul clasic de a adăuga local funcționează la căderi și nu face nimic la parole greșite. Citiți lista în schimb ca două întrebări: care metodă răspunde și ce consideră platforma un răspuns.
Separați lista de metode de grupul de servere
Lista de metode este un strat, iar grupul de servere este altul. Cuvântul cheie group radius numește un grup a cărui ordine internă, reîncercări, limite de timp și detectare a serverului mort aparțin grupului, în timp ce o metodă locală este un strat deasupra. Prin urmare, reglarea oricărui lucru din interiorul grupului nu poate transforma o respingere într-o cale de rezervă. Confirmați la ce listă se referă de fapt serviciul înainte de a schimba oricare dintre cele două straturi.
Tipăriți configurația AAA și citiți lista către care indică serviciul, nu valoarea implicită pe care vă amintiți că ați scris-o. Faceți asta de pe dispozitivul pe care serviciul se termină de fapt.
show running-config | section aaa
show radius server-group RAD-GRP
show aaa serversTabelul serverelor raportează starea și contoarele fiecărei intrări, ceea ce vă spune dacă gateway-ul a ajuns la server în timpul încercării. Un server marcat ca activ cu un contor de cereri crescător a răspuns, așa că autentificarea eșuată este o decizie, nu o problemă de conectivitate.
Citiți răspunsul înainte de jurnal
Codul de răspuns numește rezultatul și implică propriul pas următor. Access-Reject înseamnă că backend-ul a luat o decizie, așa că dovada utilă este politica ce s-a potrivit și starea contului din spatele ei. Access-Challenge înseamnă că schimbul dorește un alt pas acceptat, cum ar fi un al doilea factor, iar calea de rezervă locală ar sări în liniște peste ceva ce politica cere.
Reproduceți o încercare cu un cont de test desemnat, astfel încât răspunsul și înregistrarea backend-ului să poată fi comparate la aceeași marcă de timp. Folosiți o acreditare pe care vă este permis să o faceți să eșueze.
test aaa group RAD-GRP svc-ops 'LabPass!24' legacy
debug radius authenticationO intrare de client RADIUS lipsă sau nerecunoscută este o cauză obișnuită a unui timp de așteptare silențios, pentru că serverul primește cererea, nu găsește nicio definiție de client care să corespundă și o aruncă fără să răspundă. O nepotrivire a secretului partajat arată de obicei tot ca un timp de așteptare, pentru că răspunsul nu trece validarea și este aruncat. Niciuna dintre acestea nu arată ca Access-Reject și niciuna nu se repară adăugând un cont local. Verificați definiția clientului și secretul pe ambele părți înainte de a atinge lista de metode.
De ce contul local nu a dovedit niciodată nimic
Un cont care stă după un grup în listă dovedește doar că cineva a planificat o cădere. Nu spune nimic despre dacă planul funcționează, pentru că cazul care îl pune la încercare este cazul pe care nimeni nu îl exersează: serverul a încetat să răspundă. O autentificare locală la care nu se ajunge niciodată în funcționare normală poate purta o parolă expirată sau o stare blocată luni întregi fără ca nimeni să observe.
Accesul de urgență este o decizie de proiectare, nu un efect secundar al configurației. Dați-i propriul cont restricționat, propriul responsabil și o procedură de recuperare scrisă, și includeți rotația secretului partajat în acea procedură. Păstrarea unei parole locale cu același nume pentru fiecare utilizator central este modelul care reintroduce în liniște accesul pe care credeați că l-ați eliminat.
Testul care contează este deliberat și va întrerupe autentificările în timp ce rulează. Exact de aceea aparține unei ferestre programate cu pasul de revenire scris primul.
Verificați calea de rezervă într-o fereastră de mentenanță
Ordonați testul astfel încât să nu eliminați niciodată ultima cale de intrare. Confirmați mai întâi o cale de administrare independentă, apoi accesul normal permis, apoi o respingere deliberată, apoi comportamentul de cădere aprobat. Aceste patru cazuri au rezultate așteptate diferite, iar unirea lor într-un singur test este modul în care oamenii se blochează în afara unui dispozitiv de care încă au nevoie.
Rulați fiecare verificare dintr-o sesiune de consolă sau dintr-o cale din afara benzii, astfel încât o greșeală să nu poată închide sesiunea în care lucrați. Consola este singura cale care nu depinde de componenta testată.
show aaa servers
show running-config | include aaa authentication
test aaa group RAD-GRP svc-ops 'LabPass!24' legacyApoi restaurați configurația anterioară și confirmați că contoarele se mișcă din nou la următoarea autentificare reală. Dacă respingerea deliberată produce o autentificare locală în loc de o respingere, atunci lista sau tratarea eșecurilor nu este ceea ce credeați, iar acea descoperire valorează mai mult decât căderea cu care ați început. Scrieți rezultatul în registrul de modificări lângă numele conturilor și data testului.