9

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
1
  • Never got to the bottom of this as failed-passwords took > the timeout for TACACS to return a reply, so the second prompt was from the line password. Correct passwords got a response from TACACS immediately. Moved to newer ACS servers resolved the issue, same config, so looks like it was an ACS issue. Jun 25, 2013 at 0:45

3 Answers 3

4

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

2
  • Added sanitized line configs to Q. Jun 3, 2013 at 8:00
  • From just a very brief look at debug, it looks like ACS doesn't come back quick enough on a bad password as that condition is the only time I see timeouts with the TACACS server reported. All other times there are zero timeouts. Jun 3, 2013 at 8:25
4

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
6
  • The idea with having aaa authentication login default group tacacs+ local line was to use the line password as a catchall if the AAA template was deployed on a device where TACACS was broken and no local users were defined. And I actually had aaa authentication login CONSOLE none in my config that I didn't originally show. (Yes, I do tend to trust physical console access to the devices more than I probably should.) Jun 3, 2013 at 7:58
  • I actually couldn't replicate in lab the problem you are seeing. If you don't have 'local' password configured and IOS thinks TACACS is not reachable, then it would make sense to ask the 'line' password, but for me, for reachable TACACS it didn't fallback to 'line'. Maybe bug in IOS or in TACACS which makes failing authentication look like failing TACACS connection (might be worth trying without 'single-connection')
    – ytti
    Jun 3, 2013 at 8:08
  • Does the second password prompt without a second corresponding username prompt tells us definitively that it failed to the line password on a system without any local users created for the local auth? [aaa authentication login default group tacacs+ local line.] tacacs+ fails, local skipped as no local users, so then line password? Jun 18, 2013 at 5:56
  • I don't think it should do fallback on tacacs+ auth_failure, it should only do it for missing tacacs+ reply. So I'd research into options why IOS thinks tacacs+ is not responding (I presume it is responding). Maybe one thing to try, is different tacacs config (like remove the single-connection), if it's IOS bug, it might remove the bug trigger.
    – ytti
    Jun 18, 2013 at 6:06
  • You probably didn't see my comment on another answer about debug showing that tacacs+ is taking > 30s to respond only when the password is wrong; by that time, the systems considers tacacs server reply missing and moves to next in auth. When password is correct, tacacs response is immediate. Jun 18, 2013 at 6:16
4

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.