cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1316
Views
0
Helpful
8
Replies

6509 Session 15 access using Tacacs

dbnorton
Level 1
Level 1

On our 6509's I have Tacacs setup on both the switch and the router. When I try to session 15 from the switch to the router I get in but when I enter my Tacacs username and password it says Authentication failed. I then go to the Tacacs server to see what the error message say and it tells me that the User Access it filtered. But I can telnet directly to the MSFC and get in just fine. Any help would be great.

8 Replies 8

Richard Burts
Hall of Fame
Hall of Fame

I do not understand well what you are describing about the error message on the TACACS server. Perhaps you could post the exact wording of the error message.

If you have problems authenticating for session 15 but no problem authenticating for telnet it seems that there is some difference in how the authentication is configured between the console and the vty ports. Perhaps you could post the part of the config for line con 0 and for the vty ports. It might also be helpful to post the aaa portion of the config.

HTH

Rick

HTH

Rick

Here is the error message from the tacacs server.

11/18/2004 09:13:03 Authen failed XXXXXX Network Group 127.0.0.11 User Access Filtered .. .. tty1 XXX.XXX.XXX.XXX

I see that your original posting reflected pretty accurately the error message on the TACACS server. And I do not recognize the message. I would have thought that the error message indicated that the group defined on the TACACS server to which the user ID belongs was not configured with access rights to that peice of equipment. But that conflicts with the fact that you do not authenticate for session 15 but do authenticate for telnet to the MSFC. So I wonder even more if there is some configuration difference for authenticating the console and the vty ports on the device. Could you post those parts of the config?

Also, just to be sure, you were using the same user ID when you attempted to session 15 and when you telnetted?

HTH

Rick

HTH

Rick

Here is the VTY and Console line configs

line con 0

exec-timeout 5 0

logging synchronous

line vty 0 4

exec-timeout 5 0

logging synchronous

transport input telnet

transport output telnet

Well there is not a configured difference in authentication between the console and the vty. So they both should be using the default authentication.

My suggestion for the next step would be to run debug on the MSFC. If you want to do this, I would suggest telnetting to the MSFC, enter enable mode, do terminal monitor so that you will have the output, start debug tacacs authentication and debug aaa authentication.

While the debug is running attempt to session 15 and capture the debug output. Then from another source do a telnet to the MSFC and capture the debug output. Perhaps there will be something in the debug that will help explain why one succeeds and one fails.

I know that some organizations are reluctant to run debug because of its potential impact. I have run these debugs a number of times and have found them to be pretty low impact. Also you can lower the impact of any debug by setting the logging level of the console to informational (or more severe) so that debug output is not sent to the console.

Remember to turn off the debug when you are finished with the test.

HTH

Rick

HTH

Rick

Here is the output from the debug of tacacs.

Nov 18 10:46:33 est: TAC+: Closing TCP/IP 0x42948D3C connection to X.X.X.X/49

Nov 18 10:46:33 est: TAC+: send AUTHEN/START packet ver=192 id=3823540857

Nov 18 10:46:33 est: TAC+: Using default tacacs server-group "tacacs+" list.

Nov 18 10:46:33 est: TAC+: Opening TCP/IP to X.X.X.X/49 timeout=5

Nov 18 10:46:33 est: TAC+: Opened TCP/IP handle 0x41CF90C8 to X.X.X.X/49 using source X.X.X.X

Nov 18 10:46:33 est: TAC+: X.X.X.X (3823540857) AUTHEN/START/LOGIN/ASCII queued

Nov 18 10:46:33 est: TAC+: (3823540857) AUTHEN/START/LOGIN/ASCII processed

Nov 18 10:46:33 est: TAC+: ver=192 id=3823540857 received AUTHEN status = GETUSER

Nov 18 10:46:38 est: TAC+: send AUTHEN/CONT packet id=3823540857

Nov 18 10:46:38 est: TAC+: X.X.X.X (3823540857) AUTHEN/CONT queued

Nov 18 10:46:38 est: TAC+: (3823540857) AUTHEN/CONT processed

Nov 18 10:46:38 est: TAC+: ver=192 id=3823540857 received AUTHEN status = GETPASS

Nov 18 10:46:42 est: TAC+: send AUTHEN/CONT packet id=3823540857

Nov 18 10:46:42 est: TAC+: X.X.X.X (3823540857) AUTHEN/CONT queued

Nov 18 10:46:43 est: TAC+: (3823540857) AUTHEN/CONT processed

Nov 18 10:46:43 est: TAC+: ver=192 id=3823540857 received AUTHEN status = FAIL

Nov 18 10:46:45 est: TAC+: Closing TCP/IP 0x41CF90C8 connection to X.X.X.X/49

I here is another entry in the Tacacs Failed Attempts log. And I noticed that caller-ID is 127.0.0.11 and the NAS-Port is tty not vty.

11/18/2004 10:44:11 Authen failed USERNAME Network Group 127.0.0.11 User Access Filtered .. .. tty2 X.X.X.X

Do you have any Network Access Restrictions setup in the Tacacs server that would be limiting where you can telnet from? If you have restrictions setup for the user account that only allow access from certain IP addresses, this could be causing the problem.