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

9

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
erreur générale de réseau
la source
Je ne suis jamais allé au fond de cela car les mots de passe ayant échoué ont pris le temps imparti pour que TACACS renvoie une réponse, la deuxième invite provenait du linemot de passe. Les mots de passe corrects ont immédiatement reçu une réponse de TACACS. Déplacé vers des serveurs ACS plus récents, le problème a été résolu, même configuration, il semble donc que ce soit un problème ACS.
generalnetworkerror

Réponses:

4

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

knotseh
la source
Ajout de lineconfigurations aseptisées à Q.
generalnetworkerror
D'un bref aperçu du débogage, il semble que ACS ne revienne pas assez rapidement sur un mauvais mot de passe car cette condition est la seule fois où je vois des délais d'attente avec le serveur TACACS signalés. Toutes les autres fois, il n'y a aucun délai d'attente.
generalnetworkerror
4

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
ytti
la source
L'idée de l'avoir aaa authentication login default group tacacs+ local lineétait d'utiliser le mot de passe de ligne comme fourre-tout si le modèle AAA était déployé sur un appareil où TACACS était cassé et aucun utilisateur local n'était défini. Et j'avais en fait aaa authentication login CONSOLE nonedans ma config que je n'avais pas montré à l'origine. (Oui, j'ai tendance à faire plus confiance à l'accès à la console physique aux appareils que je ne le devrais probablement.)
generalnetworkerror
En fait, je n'ai pas pu reproduire en laboratoire le problème que vous voyez. Si vous n'avez pas de mot de passe `` local '' configuré et que IOS pense que TACACS n'est pas accessible, alors il serait logique de demander le mot de passe `` ligne '', mais pour moi, pour TACACS accessible, il n'est pas revenu à `` ligne ''. Peut-être un bogue dans IOS ou dans TACACS qui fait échouer l'authentification comme une connexion TACACS défaillante (cela pourrait valoir la peine d'être essayé sans «connexion unique»)
ytti
La deuxième invite de mot de passe sans une deuxième invite de nom d'utilisateur correspondante nous indique-t-elle définitivement qu'elle a échoué au linemot de passe sur un système sans aucun utilisateur local créé pour l' localauthentification? [ aaa authentication login default group tacacs+ local line.] tacacs + échoue, local ignoré comme aucun utilisateur local, alors alors mot de passe de ligne?
generalnetworkerror
Je ne pense pas que cela devrait faire de secours sur tacacs + auth_failure, il ne devrait le faire que pour les tacacs manquants + réponse. Je rechercherais donc les options pour lesquelles IOS pense que tacacs + ne répond pas (je suppose qu'il répond). Peut-être qu'une chose à essayer, c'est la configuration différente de tacacs (comme supprimer la connexion unique), si c'est un bug IOS, cela pourrait supprimer le déclencheur du bug.
ytti
Vous n'avez probablement pas vu mon commentaire sur une autre réponse sur le débogage montrant que tacacs + prend> 30s pour répondre uniquement lorsque le mot de passe est incorrect; à ce moment-là, le système considère que la réponse du serveur tacacs est manquante et passe au suivant dans l'authentification. Lorsque le mot de passe est correct, la réponse tacacs est immédiate.
generalnetworkerror
4

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).

John Jensen
la source