La password AAA / TACACS + sullo switch Cisco non riesce sempre al secondo prompt della password

Ogni volta che si accede a un dispositivo di rete utilizzando AAA / TACACS +, se si preme il dito sulla richiesta della password dopo la richiesta del nome utente, la seconda richiesta della password fallisce sempre anche quando la password è corretta. Devo attendere di nuovo il prompt del nome utente e devo ottenere la password corretta al primo prompt della password immediatamente successivo. In altre parole, ogni volta che vedo la seconda richiesta di password, non funzionerà.

Vedi l'interazione disinfettata e la configurazione di seguito.

Verifica dell'accesso dell'utente
Nome utente: nome utente
Parola d'ordine:

Password: (fallisce sempre qui)
% Accesso negato

Verifica dell'accesso dell'utente
Nome utente: nome utente
Parola d'ordine:

Collegato a s-site-rack-agg2.example.net sulla linea 1 (nome-sito).
s-site-rack-agg2 #

Cosa potrebbe esserci di diverso con la seconda richiesta di password per tenere conto di questo comportamento?

La tipica AAA e la relativa configurazione che ho sono:

aaa nuovo modello
autenticazione aaa login gruppo predefinito tacacs + linea locale
autenticazione aaa CONSOLE nessuna
autenticazione aaa abilita il gruppo predefinito tacacs + abilita
autorizzazione aaa exec gruppo predefinito tacacs + locale se autenticato
comandi di autorizzazione aaa 1 gruppo predefinito tacacs + locale se autenticato
aaa comandi di autorizzazione 7 tacac di gruppo predefiniti + locale se autenticato
comandi di autorizzazione aaa 15 tacac di gruppo predefiniti + locale se autenticato
aaa accounting exec gruppo start-stop predefinito tacacs +
aaa comandi contabili 0 tacacs gruppo start-stop predefinito +
aaa comandi contabili 1 gruppo start-stop predefinito tacacs +
comandi di contabilità aaa 7 tacacs gruppo start-stop predefiniti +
comandi di contabilità aaa 15 tacacs gruppo start-stop predefiniti +
tacacs gruppo start-stop default sistema contabile aaa +
!
ip tacacs sorgente-interfaccia Loopback0
tacacs-server host -prmiaryipremoved- connessione singola
tacacs-server host -secondaryipremoved- single-connection
timeout tacacs-server 10
richiesta diretta di tacacs-server
tacacs-server key 7 -removed-
!
linea con 0
 CONSOLE di autenticazione login
linea vty 0 4
 posizione -removed-
 exec-timeout 60 0
 password 7 -removed-
 trasporto input telnet ssh

cisco cisco-ios aaa

— generalnetworkerror
fonte

Non ho mai toccato il fondo poiché le password non riuscite hanno impiegato> il timeout per TACACS a restituire una risposta, quindi il secondo prompt era dalla linepassword. Le password corrette hanno ricevuto immediatamente una risposta da TACACS. Spostato su server ACS più recenti ha risolto il problema, stessa configurazione, quindi sembra che fosse un problema ACS.

— generalnetworkerror

Risposte:

Farei un debug sul tuo server TACACS + mentre lo stai provando.

Presumo che desideri utilizzare solo l'autenticazione TACACS e ricorrere agli accessi locali solo se non può accedere al server?

Prova a usare questo:
aaa authentication login default group tacacs+ line aaa authentication enable default group tacacs+ enable

Vedi anche questo sito: ha alcuni buoni esempi e spiegazioni

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

La mia ipotesi è che dal momento che hai la parola chiave "locale" in:
aaa authentication login default group tacacs+ local line

L'autenticazione TACACS + restituisce un errore, quindi il router tenta di eseguire l'autenticazione locale. Immagino che dovresti fornirci la line vtyconfigurazione disinfettata. Se hai
line vty 0 15 login local

Quindi farebbe un'autenticazione nome utente / password altrimenti farebbe la password

— knotseh
fonte

Aggiunte lineconfigurazioni sanitizzate a Q.

— generalnetworkerror

Da una breve occhiata al debug, sembra che ACS non torni abbastanza veloce con una password errata in quanto questa condizione è l'unica volta che vedo i timeout con il server TACACS segnalato. Tutte le altre volte ci sono zero timeout.

— generalnetworkerror,

Penso che la tua configurazione sia abbastanza pericolosa e sembri indeciso se stai usando 'enable / line' o 'local' come fallback, la risposta corretta è locale, non usare mai 'enable' e soprattutto mai 'line' per nulla (la linea è due- modo "crittografato" non con hash unidirezionale).

Raccomanderei invece questa configurazione:

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>

L'utente 'sikrit' deve essere usato quando tacacs non funziona (non può essere usato se TACACS risponde) non è necessario inserire la password 'line' in VTY, poiché non è mai stata consultata. Non è necessaria la password "abilita", poiché non viene mai consultata. Se desideri un utente di backup non abilitato, creane un altro con "privilegio 1".
Tuttavia, ho aggiunto il supporto per "abilitare" se si desidera utilizzarlo per qualche motivo dopo tutto.

Se si utilizza OOB e l'accesso OOB è già protetto / autenticato, è possibile consentire all'utente OOB di utilizzare sempre l'autenticazione locale, nel caso in cui TACACS venga interrotto ma IOS pensi erroneamente di no, quindi aggiungerebbe qualcosa del genere :

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

— ytti
fonte

L'idea di dover aaa authentication login default group tacacs+ local lineusare era la password di linea come catchall se il modello AAA era distribuito su un dispositivo in cui il TACACS era rotto e nessun utente locale era definito. E in realtà avevo aaa authentication login CONSOLE nonenella mia configurazione che inizialmente non avevo mostrato. (Sì, tendo a fidarmi dell'accesso fisico della console ai dispositivi più di quanto probabilmente dovrei.)

— generalnetworkerror

In realtà non sono riuscito a replicare in laboratorio il problema che stai riscontrando. Se non hai configurato la password "locale" e IOS ritiene che TACACS non sia raggiungibile, avrebbe senso chiedere la password "line", ma per me, per TACACS raggiungibili, non è stato eseguito il fallback a "line". Forse bug in IOS o in TACACS che fa sembrare che l'autenticazione fallita assomigli a una connessione TACACS fallita (potrebbe valere la pena provare senza 'single-connection')

— ytti

La seconda richiesta password senza una seconda richiesta nome utente corrispondente ci dice definitivamente che la linepassword su un sistema non è riuscita senza che nessun utente locale sia stato creato per l' localautent? [ aaa authentication login default group tacacs+ local line.] tacacs + ha esito negativo, locale ignorato come nessun utente locale, quindi la password di linea?

— generalnetworkerror,

Non penso che dovrebbe fare fallback su tacacs + auth_failure, dovrebbe farlo solo per tacacs mancanti + risposta. Quindi ricercai le opzioni per cui IOS pensa che tacacs + non stia rispondendo (presumo che stia rispondendo). Forse una cosa da provare è la diversa configurazione di tacac (come rimuovere la connessione singola), se si tratta di un bug IOS, potrebbe rimuovere il trigger di bug.

— ytti,

Probabilmente non hai visto il mio commento su un'altra risposta sul debug che mostra che tacacs + sta impiegando> 30s per rispondere solo quando la password è errata; a quel punto, il sistema considera mancante la risposta del server tacacs e passa alla successiva in auth. Quando la password è corretta, la risposta di tacac è immediata.

— generalnetworkerror,

Non sono sicuro che la tua configurazione di dispositivo locale sarebbe da incolpare per questo, ma piuttosto il tuo server TACACS stesso. TACACS inoltra la richiesta nome utente / password dal server TACACS (e possibilmente un archivio di identità esterno) al dispositivo, quindi se stai usando ACS (ad esempio) e hai configurato per parlare con AD per fare l'autenticazione utente, devi pensare al prompt nome utente / password come proveniente da un controller di dominio piuttosto che dal dispositivo stesso.

Recentemente ho riscontrato un problema esattamente come questo che è stato risolto da una patch su ACS - di nuovo, presumo che tu stia utilizzando ACS e lo stia tirando da AD per la verifica dell'autenticazione / gruppo dell'utente ecc. L'ID bug Cisco era CSCtz03211 e fondamentalmente ACS 5.3 stava inviando più tentativi di autenticazione ad AD per un singolo tentativo di autenticazione "nome utente / password" sul dispositivo. Ciò comporterebbe il comportamento in cui se un utente digitava a fatica la password al primo tentativo, più istanze della combinazione errata nome utente / password venivano inviate ad AD e l'account dell'utente veniva effettivamente bloccato, causando quindi successivi tentativi di accesso non riusciti a il dispositivo anche se un utente ha digitato correttamente il proprio nome utente / password al secondo tentativo (questo comportamento ovviamente varia con le soglie di blocco impostate sugli account utente in AD).

Solo qualcosa da considerare (senza conoscenza dell'implementazione del server TACACS).

— John Jensen
fonte