Hasło AAA / TACACS + na przełączniku Cisco zawsze kończy się niepowodzeniem przy drugim pytaniu o hasło

Ilekroć loguję się do urządzenia sieciowego za pomocą AAA / TACACS +, jeśli grubo palcem po monicie o nazwę użytkownika, drugie hasło zawsze kończy się niepowodzeniem, nawet jeśli hasło jest prawidłowe. Muszę poczekać na monit o nazwę użytkownika i muszę uzyskać poprawne hasło w pierwszym monitie o hasło zaraz po tym. Innymi słowy, za każdym razem, gdy pojawia się monit o podanie drugiego hasła, nie zadziała.

Zobacz zdezynfekowaną interakcję i konfigurację poniżej.

Weryfikacja dostępu użytkownika
Nazwa użytkownika: nazwa użytkownika
Hasło:

Hasło: (zawsze tutaj się nie udaje)
% Brak dostępu

Weryfikacja dostępu użytkownika
Nazwa użytkownika: nazwa użytkownika
Hasło:

Połączony z s-site-rack-agg2.example.net w linii 1 (nazwa strony).
s-site-rack-agg2 #

Co może się różnić od drugiego pytania o hasło, aby uwzględnić to zachowanie?

Typowa konfiguracja AAA i powiązana z nią to:

aaa nowy model
aaa uwierzytelnianie login domyślna grupa tacacs + linia lokalna
aaa uwierzytelnienie login CONSOLE brak
aaa uwierzytelnianie włącz domyślną grupę tacacs + włącz
aaa autoryzacja exec domyślna grupa tacacs + lokalny jeśli-uwierzytelniony
aaa komendy autoryzacyjne 1 domyślne tacacs grupy + lokalny jeśli-uwierzytelniony
aaa komendy autoryzacyjne 7 domyślnych tacacs grupy + lokalny jeśli-uwierzytelniony
aaa komendy autoryzacyjne 15 domyślnych tacacs grupy + lokalny jeśli-uwierzytelniony
aaa rachunkowość exec domyślna grupa start-stop tacacs +
aaa polecenia księgowe 0 domyślna grupa start-stop tacacs +
aaa polecenia księgowe 1 domyślna grupa start-stop tacacs +
aaa polecenia księgowe 7 domyślnych grup start-stop tacacs +
aaa polecenia księgowe 15 domyślnych grup start-stop tacacs +
aaa system rachunkowości domyślna grupa start-stop tacacs +
!
Interfejs źródłowy ip tacacs Loopback0
tacacs-server host -prmiaryipremoved- pojedyncze połączenie
tacacs-server host -secondaryipremoved- pojedyncze połączenie
Limit czasu serwera tacacs 10
Tacacs-server direct-request
klucz serwera tacacs 7 -removed-
!
linia con 0
 uwierzytelnianie logowania CONSOLE
linia vty 0 4
 lokalizacja-usunięty-
 limit czasu wykonania 60 0
 hasło 7-usunięte
 wejście transportowe telnet ssh

Podczas próby tego zrobiłbym debugowanie na twoim serwerze TACACS +.

Zakładam, że chcesz korzystać tylko z uwierzytelniania TACACS i powracać do lokalnych loginów tylko wtedy, gdy nie ma on dostępu do serwera?

Spróbuj użyć tego:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Zobacz także tę stronę: zawiera kilka dobrych przykładów i wyjaśnień

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ heada _4_2 # X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjNfX2hlYWRhX180XzEmcXVlcnk9

Sądzę, że skoro masz słowo kluczowe „lokalne” w:
aaa authentication login default group tacacs+ local line

Uwierzytelnianie TACACS + zwraca błąd, więc router próbuje dokonać lokalnego uwierzytelnienia. Myślę, że powinieneś dostarczyć nam line vtyodkażoną konfigurację. Jeśli masz
line vty 0 15
login local

Następnie wykonałby uwierzytelnienie nazwy użytkownika / hasła, w przeciwnym razie robi hasło

Myślę, że twoja konfiguracja jest dość niebezpieczna i wydajesz się niezdecydowany, jeśli używasz „enable / line” lub „local” jako rezerwowej, poprawna odpowiedź jest lokalna, nigdy nie używaj „enable”, a zwłaszcza nigdy „line” do niczego (linia ma dwa- sposób „zaszyfrowany”, a nie jednokierunkowy skrót).

Zamiast tego poleciłbym tę konfigurację:

aaa new-model
! uses tacacs, fallsback to local user if tacacs not working
aaa authentication login default group tacacs+ local
! user gets enabled by tacacs or by enable password
aaa authentication enable default group tacacs+ enable
! console user is authorized as well (gets enabled, if such permission)
aaa authorization console
! configuration commands are authorized as well as exec commands (Good to prevent dangerous commands)
aaa authorization config-commands
! user privilege level is recovered from tacacs or from local account
aaa authorization exec default group tacacs+ local
! level 15 commands are authorized (you really only need this) 
aaa authorization commands 15 default group tacacs+ if-authenticated 
! level 1, 15 commands are logged (you really only need these two)
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
!
! fallback user consulted only when tacacs is broken
username sikrit privilege 15 secret <password>

użytkownika „sikrit” należy używać, gdy tacacs nie działa (nie można go użyć, jeśli TACACS odpowiada), nie ma potrzeby hasła „linii” pod VTY, ponieważ nigdy nie jest konsultowany. Hasło „włącz” nie jest potrzebne, ponieważ nigdy nie jest sprawdzane. Jeśli chcesz, aby użytkownik nie miał włączonej kopii zapasowej, po prostu utwórz inną z „uprawnieniem 1”.
Dodałem jednak wsparcie dla „enable”, jeśli mimo wszystko chcesz go używać.

Jeśli używasz OOB, a dostęp OOB jest już zabezpieczony / uwierzytelniony, możesz pozwolić użytkownikowi OOB zawsze korzystać z lokalnego uwierzytelnienia, na wypadek, gdyby TACACS został uszkodzony, ale IOS błędnie uważa, że ​​tak nie jest, wtedy możesz dodać coś takiego :

aaa authentication login CONSOLE local
!
line con 0
 login authentication CONSOLE

Nie jestem pewien, czy winę za to ponosi twoja konfiguracja urządzenia lokalnego, ale raczej sam serwer TACACS. TACACS pośredniczy w zapytaniu o nazwę użytkownika / hasło z serwera TACACS (i ewentualnie zewnętrznego magazynu tożsamości) do urządzenia, więc jeśli używasz ACS (na przykład) i masz skonfigurowane do komunikowania się z AD w celu uwierzytelnienia użytkownika, potrzebujesz myśleć o pytaniu o nazwę użytkownika / hasło jako pochodzącym z kontrolera domeny, a nie z samego urządzenia.

Niedawno natknąłem się na taki właśnie problem, który został naprawiony przez łatkę do ACS - ponownie, zakładam, że używasz ACS i każe ci pobierać z AD do weryfikacji autoryzacji / grupy użytkowników itp. Identyfikator błędu Cisco to CSCtz03211 i w zasadzie ACS 5.3 wysyłał wiele prób uwierzytelnienia do AD na jedną próbę uwierzytelnienia „nazwa użytkownika / hasło” do urządzenia. Spowodowałoby to zachowanie, w którym jeśli użytkownik za pierwszym razem podchwyciłby hasło hasłem, wiele wystąpień błędnej kombinacji nazwy użytkownika / hasła zostało wysłanych do AD, a konto użytkownika zostało faktycznie zablokowane, co skutkowało kolejnymi nieudanymi próbami logowania urządzenie, nawet jeśli użytkownik wpisał swoją nazwę użytkownika / hasło poprawnie przy drugiej próbie (takie zachowanie oczywiście różni się w zależności od progów blokady ustawionych dla kont użytkowników w AD).

Tylko coś do rozważenia (bez wiedzy o implementacji serwera TACACS).