La contraseña AAA / TACACS + en el switch Cisco siempre falla en la segunda solicitud de contraseña

Siempre que inicie sesión en un dispositivo de red con AAA / TACACS +, si hago un dedo gordo en la solicitud de contraseña después de la solicitud de nombre de usuario, la segunda solicitud de contraseña siempre falla incluso cuando la contraseña es correcta. Tengo que esperar la solicitud de nombre de usuario nuevamente, y debo obtener la contraseña correcta en la primera solicitud de contraseña inmediatamente después de eso. En otras palabras, cada vez que veo la segunda solicitud de contraseña, no funcionará.

Vea la interacción desinfectada y la configuración a continuación.

Verificación de acceso de usuario
Nombre de usuario: nombre de usuario
Contraseña:

Contraseña: (siempre falla aquí)
% Acceso denegado

Verificación de acceso de usuario
Nombre de usuario: nombre de usuario
Contraseña:

Conectado a s-site-rack-agg2.example.net en la línea 1 (nombre del sitio).
s-site-rack-agg2 #

¿Qué podría ser diferente con esa segunda solicitud de contraseña para dar cuenta de este comportamiento?

La configuración típica AAA y relacionada que tengo es:

aaa nuevo modelo
aaa autenticación inicio de sesión grupo predeterminado tacacs + línea local
aaa autenticación inicio de sesión CONSOLA ninguno
autenticación aaa habilitar grupo predeterminado tacacs + habilitar
aaa autorización exec grupo predeterminado tacacs + local si está autenticado
comandos de autorización aaa 1 grupo predeterminado tacacs + local si está autenticado
comandos de autorización de aaa 7 tacacs de grupo predeterminados + local si está autenticado
los comandos de autorización aaa 15 tacacs grupales predeterminados + locales si están autenticados
aaa ejecutivo de contabilidad grupo de inicio-parada predeterminado tacacs +
comandos de contabilidad aaa 0 tacacs de grupo de inicio-parada predeterminados +
aaa comandos de contabilidad 1 tacacs de grupo de inicio-parada predeterminados +
comandos de contabilidad aaa 7 tacacs de grupo de inicio-parada predeterminados +
comandos de contabilidad aaa 15 tacacs grupales de inicio-parada predeterminados +
aaa sistema de contabilidad predeterminado grupo de inicio-parada tacacs +
!
ip tacacs fuente-interfaz Loopback0
tacacs-server host -prmiaryipremoved- conexión única
tacacs-server host -secondaryipremoved- conexión única
tacacs-server timeout 10
solicitud dirigida por el servidor tacacs
tacacs-server key 7 -removed-
!
línea con 0
 autenticación de inicio de sesión CONSOLA
línea vty 0 4
 ubicación -removed-
 exec-timeout 60 0
 contraseña 7 -removed-
 entrada de transporte telnet ssh

Haría una depuración en su servidor TACACS + mientras intenta esto.

¿Asumiré que solo desea usar la autenticación TACACS y solo recurrir a los inicios de sesión locales si no puede acceder al servidor?

Intenta usar esto:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

También vea este sitio: tiene algunos buenos ejemplos y explicaciones

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_ dolores de cabeza _4_2 # X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjWcm1X1X1X1X2X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1X1N1X1X1X1X2VX1X1X2X1X2X1X2X1X2VX1X1X1X1X1X2VX1X1X1X1X1-1-9N1V1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJUJUENDOU.COM

Supongo que, dado que tiene la palabra clave "local" en:
aaa authentication login default group tacacs+ local line

La autenticación TACACS + devuelve un error, por lo que el enrutador intenta realizar la autenticación local. Supongo que deberías proporcionarnos la line vtyconfiguración desinfectada. Si usted tiene
line vty 0 15
login local

Luego haría una autenticación de nombre de usuario / contraseña; de lo contrario, está haciendo una contraseña

Creo que su configuración es bastante peligrosa y parece indeciso si está usando 'enable / line' o 'local' como alternativa, la respuesta correcta es local, nunca use 'enable' y especialmente nunca 'line' para nada (la línea es dos- forma 'encriptada' no hash unidireccional).

Recomendaría esta configuración en su lugar:

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>

El usuario 'sikrit' se debe usar cuando tacacs no funciona (no se puede usar si TACACS responde) no hay necesidad de contraseña de 'línea' en VTY, ya que nunca se consulta. No hay necesidad de 'habilitar' la contraseña, ya que nunca se consulta. Si desea un usuario de respaldo no habilitado, simplemente cree otro con 'privilegio 1'.
Sin embargo, agregué soporte para 'habilitar' si desea usarlo por alguna razón después de todo.

Si está utilizando OOB, y el acceso OOB ya está asegurado / autenticado, es posible que desee permitir que el usuario de OOB siempre use la autenticación local, en caso de que TACACS esté roto pero IOS piense erróneamente que no lo está, entonces agregaría algo como esto :

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

No estoy seguro de que la configuración de su dispositivo local sea la culpable de esto, sino más bien de su propio servidor TACACS. TACACS representa el mensaje de nombre de usuario / contraseña del servidor TACACS (y posiblemente un almacén de identidad externo) en el dispositivo, por lo que si está utilizando ACS (por ejemplo) y lo tiene configurado para hablar con AD para realizar la autenticación de usuario, necesita pensar que el mensaje de nombre de usuario / contraseña proviene de un controlador de dominio en lugar del dispositivo en sí.

Recientemente me encontré con un problema exactamente como este que se solucionó mediante un parche para ACS; nuevamente, supongo que está utilizando ACS y lo está sacando de AD para la autenticación de usuario / grupo, etc. El ID de error de Cisco fue CSCtz03211 y básicamente ACS 5.3 estaba enviando múltiples intentos de autenticación a AD por un solo intento de autenticación de "nombre de usuario / contraseña" al dispositivo. Esto daría como resultado el comportamiento en el que si un usuario toqueteó la contraseña en el primer intento, se enviaron varias instancias del combo de nombre de usuario / contraseña erróneo a AD y la cuenta del usuario se bloqueó, lo que resultó en intentos de inicio de sesión fallidos posteriores. el dispositivo incluso si un usuario escribió su nombre de usuario / contraseña correctamente en el segundo intento (este comportamiento, por supuesto, varía con los umbrales de bloqueo que ha establecido en las cuentas de usuario dentro de AD).

Solo algo a considerar (sin conocimiento de la implementación de su servidor TACACS).