AAA/TACACS+ password on Cisco switch always fails at second password prompt

Question

Whenever logging into a network device using AAA/TACACS+, if I fat-finger the password prompt after the username prompt, the second password prompt always fails even when the password is correct. I have to wait for the username prompt again, and must get the password correct on the first password prompt immediately following that. In other words, any time I see the second password prompt, it will not work.

See the sanitized interaction and config below.

User Access Verification
Username: user-name
Password:

Password:    (always fails here)
% Access denied

User Access Verification
Username: user-name
Password:

Connected to s-site-rack-agg2.example.net on line 1 (site-name).
s-site-rack-agg2#

What could be different with that second password prompt to account for this behavior?

The typical AAA and related config I have is:

aaa new-model
aaa authentication login default group tacacs+ local line
aaa authentication login CONSOLE none
aaa authentication enable default group tacacs+ enable
aaa authorization exec default group tacacs+ local if-authenticated
aaa authorization commands 1 default group tacacs+ local if-authenticated
aaa authorization commands 7 default group tacacs+ local if-authenticated
aaa authorization commands 15 default group tacacs+ local if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 0 default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 7 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
!
ip tacacs source-interface Loopback0
tacacs-server host -prmiaryipremoved- single-connection
tacacs-server host -secondaryipremoved- single-connection
tacacs-server timeout 10
tacacs-server directed-request
tacacs-server key 7 -removed-
!
line con 0
 login authentication CONSOLE
line vty 0 4
 location -removed-
 exec-timeout 60 0
 password 7 -removed-
 transport input telnet ssh

Answer 1

I would do a debug on your TACACS+ server while you are trying this.

I'll assume that you only want to use TACACS authentication and only fall-back to local logins if it can't access the server?

Try using this:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Also see this site: It has some good examples and explanations

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

My guess is that since you have the "local" keyword in:
aaa authentication login default group tacacs+ local line

The TACACS+ authentication returns a fail, so the router tries doing local authentication. I guess you should provide us with the line vty sanitized configuration. If you have
line vty 0 15
login local

Then it would do a username/password authentication otherwise its doing password

Answer 2

I think your configuration is quite dangerous and you seem indecisive if you are using 'enable/line' or 'local' as fallback, correct answer is local, never use 'enable' and especially never 'line' for anything (line is two-way 'encrypted' not one-way hashed).

I would recommend this configuration instead:

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>

'sikrit' user is to be used when tacacs is not working (it cannot be used if TACACS answers) there is no need for 'line' password under VTY, as it's never consulted. There is no need for 'enable' password, as it is never consulted. If you want non-enabled backup user just create another with 'privilege 1'.
However I did add support for 'enable' if you want to use it for some reason after all.

If you are using OOB, and OOB access is already secured/authenticated, you might want to allow OOB user always to use local authentication, just in case TACACS is broken but IOS mistakenly thinks it is not, then you'd add something like this:

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

Answer 3

I'm not sure your local device config would be to blame for this, but rather your TACACS server itself. TACACS proxies the username/password prompt from the TACACS server (and possibly an external identity store) to the device, so if you're using ACS (for example) and have it set up to talk to AD to do user authentication, you need to think of the username/password prompt as coming from a domain controller rather than the device itself.

I recently ran into an issue exactly like this that was fixed by a patch to ACS - again, I'm assuming that you're using ACS and have it pulling from AD for user auth/group verification etc. The Cisco bug ID was CSCtz03211 and basically ACS 5.3 was sending multiple authen attempts to AD per one single "username/password" authen attempt to the device. This would result in the behavior where if a user fat-fingered the password on the first attempt, multiple instances of the erroneous username/password combo were sent to AD and the user's account was actually locked out, thus resulting in subsequent failed login attempts to the device even if a user typed their username/password correctly on the second try (this behavior of course varies with the lockout thresholds you have set on user accounts within AD). The device itself would of course just give unhelpful "login failed" messages, but the giveaway lied in the ACS TACACS authentication logs where we saw that the account was locked out, so I'd advise looking there for any clues as to what might be causing your problem.

Just something to consider (without knowledge of your TACACS server implementation).