Le mot de passe AAA / TACACS + sur le commutateur Cisco échoue toujours à la deuxième invite de mot de passe

Chaque fois que vous vous connectez à un périphérique réseau à l'aide de AAA / TACACS +, si je tape du doigt l'invite de mot de passe après l'invite de nom d'utilisateur, la deuxième invite de mot de passe échoue toujours même lorsque le mot de passe est correct. Je dois à nouveau attendre l'invite du nom d'utilisateur et je dois obtenir le mot de passe correct à la première invite de mot de passe immédiatement après. En d'autres termes, chaque fois que je vois la deuxième invite de mot de passe, cela ne fonctionnera pas.

Voir l'interaction et la configuration nettoyées ci-dessous.

Vérification de l'accès utilisateur
Nom d'utilisateur: nom d'utilisateur
Mot de passe:

Mot de passe: (échoue toujours ici)
% Accès refusé

Vérification de l'accès utilisateur
Nom d'utilisateur: nom d'utilisateur
Mot de passe:

Connecté à s-site-rack-agg2.example.net sur la ligne 1 (nom du site).
s-site-rack-agg2 #

Qu'est-ce qui pourrait être différent avec cette deuxième invite de mot de passe pour expliquer ce comportement?

La configuration typique AAA et connexe que j'ai est:

aaa nouveau modèle
Tacacs de groupe par défaut de connexion d'authentification aaa + ligne locale
connexion d'authentification aaa CONSOLE aucune
authentification aaa activer les tacacs de groupe par défaut + activer
aaa autorisation exec groupe par défaut tacacs + local si authentifié
commandes d'autorisation aaa 1 tacacs de groupe par défaut + local si authentifié
commandes d'autorisation aaa 7 tacacs de groupe par défaut + local si authentifié
commandes d'autorisation aaa 15 tacacs de groupe par défaut + local si authentifié
aaa comptabilité exec tacacs de groupe start-stop par défaut +
commandes de comptabilité aaa 0 tacacs de groupe start-stop par défaut +
commandes de comptabilité aaa 1 tacacs de groupe start-stop par défaut +
commandes de comptabilité aaa 7 tacacs de groupe start-stop par défaut +
commandes de comptabilité aaa 15 tacacs de groupe start-stop par défaut +
système de comptabilité aaa tacacs de groupe start-stop par défaut +
!
interface source ip tacacs Loopback0
tacacs-server host -prmiaryipremoved- single-connection
tacacs-server host -secondaryipremoved- single-connection
délai d'attente du serveur tacacs 10
demande dirigée du serveur tacacs
tacacs-server key 7 -removed-
!
ligne con 0
 authentification de connexion CONSOLE
ligne vty 0 4
 emplacement -supprimé-
 temporisation d'exécution 60 0
 mot de passe 7 - supprimé -
 entrée de transport telnet ssh

Je ferais un débogage sur votre serveur TACACS + pendant que vous essayez cela.

Je suppose que vous ne souhaitez utiliser que l'authentification TACACS et ne recourir aux connexions locales que s'il ne peut pas accéder au serveur?

Essayez d'utiliser ceci:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Voir aussi ce site: il contient de bons exemples et explications

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

Je suppose que puisque vous avez le mot-clé "local" dans:
aaa authentication login default group tacacs+ local line

L'authentification TACACS + renvoie un échec, donc le routeur essaie de faire l'authentification locale. Je suppose que vous devriez nous fournir la line vtyconfiguration aseptisée. Si tu as
line vty 0 15
login local

Ensuite, il ferait une authentification par nom d'utilisateur / mot de passe, sinon son mot de passe

Je pense que votre configuration est assez dangereuse et vous semblez indécis si vous utilisez 'enable / line' ou 'local' comme solution de repli, la bonne réponse est locale, n'utilisez jamais 'enable' et surtout jamais 'line' pour quoi que ce soit (la ligne est deux- façon «cryptée» et non un hachage unidirectionnel).

Je recommanderais plutôt cette configuration:

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'utilisateur 'sikrit' doit être utilisé lorsque tacacs ne fonctionne pas (il ne peut pas être utilisé si TACACS répond) il n'y a pas besoin de mot de passe 'line' sous VTY, car il n'est jamais consulté. Il n'est pas nécessaire d'activer le mot de passe, car il n'est jamais consulté. Si vous souhaitez qu'un utilisateur de sauvegarde non activé crée simplement un autre avec le «privilège 1».
Cependant, j'ai ajouté un support pour «activer» si vous voulez l'utiliser pour une raison quelconque après tout.

Si vous utilisez OOB et que l'accès OOB est déjà sécurisé / authentifié, vous voudrez peut-être autoriser l'utilisateur OOB à toujours utiliser l'authentification locale, juste au cas où TACACS est cassé mais que IOS pense à tort que ce n'est pas le cas, alors vous ajouteriez quelque chose comme ceci :

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

Je ne suis pas sûr que votre configuration de périphérique local soit à blâmer pour cela, mais plutôt votre serveur TACACS lui-même. TACACS envoie par proxy l'invite de nom d'utilisateur / mot de passe du serveur TACACS (et éventuellement un magasin d'identités externe) au périphérique, donc si vous utilisez ACS (par exemple) et qu'il est configuré pour parler à AD pour effectuer l'authentification des utilisateurs, vous devez de penser à l'invite de nom d'utilisateur / mot de passe comme provenant d'un contrôleur de domaine plutôt que de l'appareil lui-même.

J'ai récemment rencontré un problème exactement comme celui-ci qui a été résolu par un correctif sur ACS - encore une fois, je suppose que vous utilisez ACS et que vous le retirez d'AD pour la vérification de l'authentification / du groupe de l'utilisateur, etc. L'ID de bogue Cisco était CSCtz03211 et, fondamentalement, ACS 5.3 envoyait plusieurs tentatives d'authentification à AD pour une seule tentative d'authentification "nom d'utilisateur / mot de passe" vers l'appareil. Cela entraînerait le comportement selon lequel si un utilisateur tapait du doigt sur le mot de passe lors de la première tentative, plusieurs instances du combo nom d'utilisateur / mot de passe erroné étaient envoyées à AD et le compte de l'utilisateur était en fait verrouillé, entraînant ainsi l'échec ultérieur des tentatives de connexion à l'appareil même si un utilisateur a correctement tapé son nom d'utilisateur / mot de passe lors du deuxième essai (ce comportement varie bien sûr avec les seuils de verrouillage que vous avez définis pour les comptes d'utilisateurs dans AD).

Juste quelque chose à considérer (sans connaissance de l'implémentation de votre serveur TACACS).