We have a authentication named list that has TACACS+ as the primary and "local" as the back-up method.
In my understanding the backup method should only be used when the TACACS+ is un-available ?
But what happens is that when i try to connect with a username that is defined locally on the Switch\Router and doesn't exist in the TACACS+ database, the eventual result is still successful.i.e. The TACACS+ server rejects the attempt but then the Router\Switch goes to the local authentication method and authenticates the user instead of failing the authentication.
When i Use RADIUS instead of TACACS+ , then it works as expected and the authentication is failed.
Is TACACS+ supposed to work this way ?
It may depend a bit on how you have the TACACS server defined. But in general the way it is supposed to work is that if the TACACS server returns a FAIL response then the router should deny authentication and should not go to the locally configured userID and password.
So part of the question becomes how the TACACS server is configured and what it does when it receives an authentication request for a userID that it does not recognize. Does it return a FAIL response or does it do something else?
It might be helpful if you would run debug tacacs authentication and debug aaa authentication, and then try the connection again. If you post the output from the debug it might give us a better understanding of what is happening.
Thanks for pointing in the right direction. It seems the problem is with the connection method. When i use "telnet" then it works as expected and authentication is denied. However with SSH, it doesn't work properly and it moves to the LOCAL method , if the authentication fails through the server.
So with Telnet, when the password is in-correct the TACACS+ response is
108276: Feb 13 11:57:35: AAA/AUTHEN (259252400): status = FAIL
However with SSH, the failed response is Error instead of Fail,so the system moves to the Local method as below
108033: Feb 13 11:55:55: TAC+: periodic timer stopped (queue empty)
108034: Feb 13 11:55:55: TAC+: ver=192 id=4146453995 received AUTHEN status = GETPASS
108035: Feb 13 11:55:55: AAA/AUTHEN (4146453995): status = GETPASS
108036: Feb 13 11:55:55: AAA/AUTHEN/CONT (4146453995): continue_login (user='naman')
108037: Feb 13 11:55:55: AAA/AUTHEN (4146453995): status = GETPASS
108038: Feb 13 11:55:55: AAA/AUTHEN (4146453995): Method=tacacs+ (tacacs+)
108039: Feb 13 11:55:55: TAC+: send AUTHEN/CONT packet id=4146453995
108040: Feb 13 11:55:55: TAC+: periodic timer started
108041: Feb 13 11:55:55: TAC+: 172.17.4.5 req=152DE8C Qd id=4146453995 ver=192 handle=0x15CCE1C (ESTAB) expire=5 AUTHEN/CONT queued
108042: Feb 13 11:55:55: TAC+: 172.17.4.5 ESTAB id=4146453995 wrote 23 of 23 bytes
108043: Feb 13 11:55:55: TAC+: 172.17.4.5 req=152DE8C Qd id=4146453995 ver=192 handle=0x15CCE1C (ESTAB) expire=4 AUTHEN/CONT sent
108044: Feb 13 11:55:56: %SEC-6-IPACCESSLOGP: list 141 denied udp 172.28.21.3(138) -> 172.28.21.127(138), 2 packets
108045: Feb 13 11:56:00: TAC+: 172.17.4.5 (4146453995) AUTHEN/CONT -- TIMED OUT
108046: Feb 13 11:56:00: TAC+: req=152DE8C Tx id=4146453995 ver=192 handle=0x15CCE1C (ESTAB) expire=0 AUTHEN/CONT processed
108047: Feb 13 11:56:00: TAC+: periodic timer stopped (queue empty)
108048: Feb 13 11:56:00: TAC+: Closing TCP/IP 0x15CCE1C connection to 172.17.4.5/49
108049: Feb 13 11:56:00: AAA/AUTHEN (4146453995): status = ERROR
108050: Feb 13 11:56:00: AAA/AUTHEN/START (4069608499): port='tty2' list='' action=LOGIN service=LOGIN
108051: Feb 13 11:56:00: AAA/AUTHEN/START (4069608499): Restart
108052: Feb 13 11:56:00: AAA/AUTHEN/START (4069608499): Method=LOCAL
108053: Feb 13 11:56:00: AAA/AUTHEN (4069608499): status = GETPASS
108054: Feb 13 11:56:00: AAA/AUTHEN/CONT (4069608499): continue_login (user='naman')
108055: Feb 13 11:56:00: AAA/AUTHEN (4069608499): status = GETPASS
108056: Feb 13 11:56:00: AAA/AUTHEN/CONT (4069608499): Method=LOCAL
108057: Feb 13 11:56:00: AAA/AUTHEN (4069608499): status = PASS
I am glad that we are making progress in understanding what is happening. So telnet works as expected but SSH does not. Would you be able to post the configuration of the router (at minimum I would like to see the aaa parts and the configuration of all vty).
Below is the relevant config
aaa authentication login telnet group tacacs+ local
username naman secret 5 xxxxxxxxxxxxxxxxxxxx
ip ssh time-out 120
ip ssh authentication-retries 3
line vty 0 4
access-class 1 in
exec-timeout 30 0
login authentication telnet
This is quite strange. The configuration does not differentiate between authentication of telnet and SSH and I would think that the interaction between router and TACACS would be the same for telnet and SSH. But TACACS seems to be acting differently when you test SSH. When you test with telnet it seems that there is a FAIL response but the messages that you posted show that with SSH there was no response from TACACS (which is why the router used local authentication). Were you using the same userID and same password to test SSH as to test telnet?
I do not understand the different processing of telnet and SSH. Would you be able to run debug tacacs packet and then do both a telent and an ssh test and post the output?