Odrzucenie RADIUS kontra brak odpowiedzi: kiedy działa logowanie lokalne

Utrzymywanie lokalnego konta awaryjnego nie czyni go drugą szansą dla każdego odrzuconego logowania. W modelu AAA Cisco IOS i IOS XE do tej bazy sięga się tylko wtedy, gdy poprzednia metoda zawiedzie w określony sposób, a serwer RADIUS odpowiadający odrzuceniem nie zawiódł w ten sposób. Konto lokalne obejmuje metodę nieosiągalną, a nie odrzuconą. Sądzenie przeciwnie zamienia decyzję polityki w polowanie na nieistniejącą awarię serwera.

Dlaczego lista metod wygląda jak drabina

Wiersz taki jak aaa authentication login default group radius local czyta się od lewej do prawej, a większość ludzi czyta go jako spróbuj RADIUS, potem spróbuj lokalnej bazy. Składnia zachęca do takiego czytania, bo lista jest sekwencją. Znaczenie jest węższe: lista nazywa metody uwierzytelniania, a reguła przejścia z jednej do następnej zależy od wyniku poprzedniej metody, a nie od dania użytkownikowi kolejnej próby.

Metoda zwracająca błąd i metoda zwracająca niepowodzenie prowadzą tu do różnych wyników. Odrzucenie jest odpowiedzią, bo serwer przetworzył dane logowania i powiedział nie, i lista się tam zatrzymuje. Nieosiągalny serwer, wygasłe żądanie lub odpowiedź, której nie można zweryfikować, to przypadek, który pozwala działać następnej metodzie, i tylko tam, gdzie obsługa awarii platformy jest tak skonfigurowana. Dlatego klasyczna rada, by dodać local, działa przy awariach i nic nie robi przy błędnych hasłach. Czytaj listę zamiast tego jako dwa pytania: która metoda odpowiada i co platforma uznaje za odpowiedź.

Oddziel listę metod od grupy serwerów

Lista metod to jedna warstwa, a grupa serwerów to druga. Słowo kluczowe group radius nazywa grupę, której wewnętrzna kolejność, ponowienia, limity czasu i wykrywanie martwego serwera należą do grupy, podczas gdy metoda lokalna jest warstwą nad nią. Dlatego dostrajanie czegokolwiek wewnątrz grupy nie może zmienić odrzucenia w ścieżkę awaryjną. Przed zmianą którejkolwiek warstwy potwierdź, do której listy usługa faktycznie się odwołuje.

Wydrukuj konfigurację AAA i przeczytaj listę, na którą wskazuje usługa, a nie wartość domyślną, którą pamiętasz, że napisałeś. Zrób to z urządzenia, na którym usługa faktycznie się kończy.

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

Tabela serwerów podaje stan i liczniki każdego wpisu, co mówi, czy brama dotarła do serwera podczas próby. Serwer oznaczony jako działający z rosnącym licznikiem żądań odpowiadał, więc nieudane logowanie jest decyzją, a nie problemem z łącznością.

Przeczytaj odpowiedź, zanim przeczytasz log

Kod odpowiedzi nazywa wynik i sugeruje własny następny krok. Access-Reject oznacza, że backend podjął decyzję, więc przydatnym dowodem jest pasująca polityka i stan konta za nią. Access-Challenge oznacza, że wymiana chce jeszcze jednego obsługiwanego kroku, na przykład drugiego czynnika, a lokalna ścieżka awaryjna po cichu pominęłaby coś, czego wymaga polityka.

Odtwórz jedną próbę z wyznaczonym kontem testowym, aby odpowiedź i zapis backendu można było porównać w tym samym znaczniku czasu. Użyj danych logowania, których niepowodzenie jest dozwolone.

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

Brakujący lub nierozpoznany wpis klienta RADIUS to częsta przyczyna cichego limitu czasu, bo serwer otrzymuje żądanie, nie znajduje pasującej definicji klienta i wyrzuca je bez odpowiedzi. Niezgodność wspólnego sekretu również zwykle wygląda jak limit czasu, bo odpowiedź nie przechodzi walidacji i jest odrzucana. Nic z tego nie wygląda jak Access-Reject i nic z tego nie naprawia się przez dodanie lokalnego konta. Sprawdź definicję klienta i sekret po obu stronach, zanim dotkniesz listy metod.

Dlaczego lokalne konto nigdy niczego nie dowiodło

Konto stojące na liście po grupie dowodzi tylko, że ktoś zaplanował awarię. Nie mówi nic o tym, czy plan działa, bo przypadek, który go sprawdza, to przypadek, którego nikt nie ćwiczy: serwer przestał odpowiadać. Lokalne logowanie, do którego w normalnej pracy nigdy się nie dochodzi, może miesiącami nosić wygasłe hasło lub zablokowany stan, a nikt tego nie zauważy.

Dostęp awaryjny to decyzja projektowa, a nie skutek uboczny konfiguracji. Daj mu własne ograniczone konto, własnego właściciela i pisemną procedurę odzyskiwania, i włącz rotację wspólnego sekretu do tej procedury. Trzymanie lokalnego hasła o tej samej nazwie dla każdego użytkownika centralnego to wzorzec, który po cichu przywraca dostęp, który uważałeś za usunięty.

Test, który ma znaczenie, jest zamierzony i przerwie logowania w czasie działania. Właśnie dlatego należy do zaplanowanego okna z krokiem wycofania napisanym jako pierwszy.

Sprawdź ścieżkę awaryjną w oknie konserwacji

Ułóż test tak, aby nigdy nie usuwać ostatniej drogi wejścia. Najpierw potwierdź niezależną ścieżkę zarządzania, potem normalny dozwolony dostęp, potem zamierzone odrzucenie, potem zatwierdzone zachowanie przy awarii. Te cztery przypadki mają różne oczekiwane wyniki, a łączenie ich w jeden test to sposób, w jaki ludzie zamykają się na zewnątrz urządzenia, którego wciąż potrzebują.

Wykonuj każdą kontrolę z sesji konsoli lub ze ścieżki poza pasmem, aby błąd nie mógł zamknąć sesji, w której pracujesz. Konsola to jedyna ścieżka, która nie zależy od testowanego komponentu.

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

Potem przywróć poprzednią konfigurację i potwierdź, że liczniki znów się ruszają przy następnym prawdziwym logowaniu. Jeśli zamierzone odrzucenie daje lokalne logowanie zamiast odrzucenia, to lista lub obsługa awarii nie jest tym, w co wierzyłeś, a to odkrycie jest ważniejsze niż awaria, od której zacząłeś. Zapisz wynik w rejestrze zmian obok nazw kont i daty testu.