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

  • 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
    

    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.

  • knotseh

    knotseh Correct answer

    8 years ago

    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

    Added sanitized `line` configs to Q.

    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.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM