cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
696
Views
0
Helpful
9
Replies

Tacacs+ Authorization - Router vs. Switch differences in behavior

mksmith
Level 1
Level 1

I am using ACS for Windows on Win2k for AAA services on a network of routers and switches. I have configured different users with <hopefully> different levels of access to the devices. In short, I have a particular user that should not be able to get to an enable prompt.

I have the following auth configs:

<router>

aaa authorization exec default tacacs+ local

aaa authorization network default tacacs+ local

<switch>

aaa authorization exec default group tacacs+ local

aaa authorization network default group tacacs+ local

When I log in as this particular user on a router and attempt to type in the enable pass, I get an authorization failed message, which is the correct behavior. When I do the same thing on one of the switches (both 3500's and 3550's in this case), I can successfully type the enable password.

Can anyone see anything in the above configuration that would cause different behavior on these devices? The only difference I can see is the "group" keyword in the switch config, which is obviously required as part of the string.

Any help is, as always, greatly appreciated.

Thanks,

Mike

9 Replies 9

4brown
Level 1
Level 1

Where do you wish to maintain your enable secret, on the devices or the AAA Server?

Do you wish to perform command authorization when users type in "enable?"

Do you have authentication configured such as:

aaa authentication enable default group tacacs+

in the switch? If so, the AAA Server is where it is looking for it. Post the entire config. Also, turn on debug aaa author and paste the capture in here.

It is also useful to look at the AAA Server logs.

Thanks

Robert

Hello:

> Where do you wish to maintain your enable secret, on the devices or the AAA Server?

The enable secret password is kept on the routers and switches, not on the AAA server.

> Do you wish to perform command authorization when users type in "enable?"

In this case, no. However, that is coming in the future. From a management perspective, here is what I am trying to accomplish:

1) Technical Level 1 -> cannot issue enable command. This is the user I have been working on in this particular issue. I have checked "no enable" on the ACS user setting and, as I said, it appears to be working on the routers, just not on the switches.

2) Technical Level 2 -> can issue enable, but further commands are restricted by entries on the ACS.

3) Engineer -> All access. We currnently have this working with no trouble.

aaa new-model

aaa authentication login default group tacacs+ local

aaa authentication login no_tacacs enable

aaa authorization exec default group tacacs+ local

aaa authorization network default group tacacs+ local

aaa accounting commands 15 default start-stop group tacacs+

enable secret 05 xxxxxxx

aaa new-model

aaa authentication login default tacacs+ local

aaa authentication login ppp tacacs+ local

aaa authentication login no_tacacs enable

aaa authorization exec default tacacs+ local

aaa authorization network default tacacs+ local

aaa accounting commands 15 default start-stop tacacs+

enable secret 5 xxxxxx

Oct 29 10:27:44 PST: AAA/MEMORY: free_user (0xDFA9FC) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Oct 29 10:27:49 PST: AAA: parse name=tty0 idb type=-1 tty=-1

Oct 29 10:27:49 PST: AAA: name=tty0 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=0 channel=0

Oct 29 10:27:49 PST: AAA/MEMORY: create_user (0x9F0F5C) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Oct 29 10:27:57 PST: AAA: parse name=tty2 idb type=-1 tty=-1

Oct 29 10:27:57 PST: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0

Oct 29 10:27:57 PST: AAA/MEMORY: create_user (0xDFA9FC) user='' ruser='' port='tty2' rem_addr='216.39.168.35' authen_type=ASCII service=LOGIN priv=1

Oct 29 10:28:05 PST: tty2 AAA/AUTHOR/EXEC (608290007): Port='tty2' list='' service=EXEC

Oct 29 10:28:05 PST: AAA/AUTHOR/EXEC: tty2 (608290007) user='tech1'

Oct 29 10:28:05 PST: tty2 AAA/AUTHOR/EXEC (608290007): send AV service=shell

Oct 29 10:28:05 PST: tty2 AAA/AUTHOR/EXEC (608290007): send AV cmd*

Oct 29 10:28:05 PST: tty2 AAA/AUTHOR/EXEC (608290007): found list "default"

Oct 29 10:28:05 PST: tty2 AAA/AUTHOR/EXEC (608290007): Method=tacacs+ (tacacs+)

Oct 29 10:28:05 PST: AAA/AUTHOR/TAC+: (608290007): user=tech1

Oct 29 10:28:05 PST: AAA/AUTHOR/TAC+: (608290007): send AV service=shell

Oct 29 10:28:05 PST: AAA/AUTHOR/TAC+: (608290007): send AV cmd*

Oct 29 10:28:05 PST: AAA/AUTHOR (608290007): Post authorization status = PASS_ADD

Oct 29 10:28:05 PST: AAA/AUTHOR/EXEC: Authorization successful

Oct 29 10:28:15 PST: AAA/MEMORY: free_user (0xD9A2EC) user='' ruser='' port='tty2' rem_addr='216.39.168.35' authen_type=ASCII service=ENABLE priv=15

Oct 29 10:28:20 PST: AAA/MEMORY: free_user (0xDF9A10) user='' ruser='' port='tty2' rem_addr='216.39.168.35' authen_type=ASCII service=ENABLE priv=15

Oct 29 10:28:22 PST: AAA/MEMORY: free_user (0x9F0F5C) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Oct 29 10:28:22 PST: AAA: parse name=tty0 idb type=-1 tty=-1

Oct 29 10:28:22 PST: AAA: name=tty0 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=0 channel=0

Oct 29 10:28:22 PST: AAA/MEMORY: create_user (0x9F0F5C) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Oct 29 18:30:02: AAA: parse name=tty4 idb type=-1 tty=-1

Oct 29 18:30:02: AAA: name=tty4 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=4 channel=0

Oct 29 18:30:09: AAA/AUTHOR/EXEC (3787823555): Port='tty4' list='' service=EXEC

Oct 29 18:30:09: AAA/AUTHOR/EXEC: (3787823555) user='tech1'

Oct 29 18:30:09: AAA/AUTHOR/EXEC: (3787823555) send AV service=shell

Oct 29 18:30:09: AAA/AUTHOR/EXEC: (3787823555) send AV cmd*

Oct 29 18:30:09: AAA/AUTHOR/EXEC (3787823555) found list "default"

Oct 29 18:30:09: AAA/AUTHOR/EXEC: (3787823555) Method=TACACS+

Oct 29 18:30:09: AAA/AUTHOR/TAC+: (3787823555): user=tech1

Oct 29 18:30:09: AAA/AUTHOR/TAC+: (3787823555): send AV service=shell

Oct 29 18:30:09: AAA/AUTHOR/TAC+: (3787823555): send AV cmd*

Oct 29 18:30:09: AAA/AUTHOR (3787823555): Post authorization status = PASS_ADD

Oct 29 18:30:09: AAA/AUTHOR/EXEC: Authorization successful

On the router, I issued the "enable" command and typed in the appropriate password but it just says "% Access denied" which is the expected behavior. I would like the same thing to happen on the switches.

Mike

Note you have created the list:

no_tacacs

and assigned enable authentication for this. Where is the list 'no_tacacs' assigned. For example, on line con 0 you may have 'login authentication no_tacacs' assigned. Where do you have this list assigned in both device?

There are a few ways to do what your requirements state. You could change the default privilege level for 'enable' to a higher privilege level, and enforce command authorization for specific users or groups.

There is good example of this here:

http://www.cisco.com/warp/public/480/PRIV.html

I think your issues lie in how you have the 'no_tacacs' list assigned. Post that information and complete authorization debugs on both devices.

Thanks

Robert

>Note you have created the list:

>no_tacacs

>and assigned enable authentication for this. Where is the list 'no_tacacs' >assigned. For example, on line con 0 you may have 'login authentication >no_tacacs' assigned. Where do you have this list assigned in both device?

I have it assigned to the console on all devices, but that's the only place.

>There are a few ways to do what your requirements state. You could change >the default privilege level for 'enable' to a higher privilege level, and enforce >command authorization for specific users or groups.

>There is good example of this here:

>http://www.cisco.com/warp/public/480/PRIV.html

>I think your issues lie in how you have the 'no_tacacs' list assigned. Post that >information and complete authorization debugs on both devices.

The above URL references configuration hints for the router side of the world. As far as I can tell, the routers are doing exactly what I expect them to do. I have Engineer users that get a # prompt when they log in with their username and passwords as part of the "default" group on the ACS. I have another user that gets the > prompt and cannot get to the enable prompt even if they know the password (that debug output is in the previous message).

It's just the switches that are behaving differently. Same setup, the Engineer users behave exactly as if they are logging in to the router (enable prompt received). However, the lowly user can get to an enable prompt if they know the password.

So, the issue is, why is it operating two different ways on two different device types? All of the routers in question have the same config and all of the switches have the same config, so it would appear Tacacs is operating differently depending on the device.

Oct 29 20:22:40: AAA: parse name=tty3 idb type=-1 tty=-1

Oct 29 20:22:40: AAA: name=tty3 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=3 channel=0

Oct 29 20:22:44: AAA/AUTHOR/EXEC (3413984402): Port='tty3' list='' service=EXEC

Oct 29 20:22:44: AAA/AUTHOR/EXEC: (3413984402) user='mksmith'

Oct 29 20:22:44: AAA/AUTHOR/EXEC: (3413984402) send AV service=shell

Oct 29 20:22:44: AAA/AUTHOR/EXEC: (3413984402) send AV cmd*

Oct 29 20:22:44: AAA/AUTHOR/EXEC (3413984402) found list "default"

Oct 29 20:22:44: AAA/AUTHOR/EXEC: (3413984402) Method=TACACS+

Oct 29 20:22:44: AAA/AUTHOR/TAC+: (3413984402): user=mksmith

Oct 29 20:22:44: AAA/AUTHOR/TAC+: (3413984402): send AV service=shell

Oct 29 20:22:44: AAA/AUTHOR/TAC+: (3413984402): send AV cmd*

Oct 29 20:22:44: AAA/AUTHOR (3413984402): Post authorization status = PASS_ADD

Oct 29 20:22:44: AAA/AUTHOR/EXEC: Processing AV service=shell

Oct 29 20:22:44: AAA/AUTHOR/EXEC: Processing AV cmd*

Oct 29 20:22:44: AAA/AUTHOR/EXEC: Processing AV priv-lvl=15

Oct 29 20:22:44: AAA/AUTHOR/EXEC: Authorization successful

Oct 29 20:23:30: AAA: parse name=tty3 idb type=-1 tty=-1

Oct 29 20:23:30: AAA: name=tty3 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=3 channel=0

Oct 29 20:23:36: AAA/AUTHOR/EXEC (2728515295): Port='tty3' list='' service=EXEC

Oct 29 20:23:36: AAA/AUTHOR/EXEC: (2728515295) user='tech1'

Oct 29 20:23:36: AAA/AUTHOR/EXEC: (2728515295) send AV service=shell

Oct 29 20:23:36: AAA/AUTHOR/EXEC: (2728515295) send AV cmd*

Oct 29 20:23:36: AAA/AUTHOR/EXEC (2728515295) found list "default"

Oct 29 20:23:36: AAA/AUTHOR/EXEC: (2728515295) Method=TACACS+

Oct 29 20:23:36: AAA/AUTHOR/TAC+: (2728515295): user=tech1

Oct 29 20:23:36: AAA/AUTHOR/TAC+: (2728515295): send AV service=shell

Oct 29 20:23:36: AAA/AUTHOR/TAC+: (2728515295): send AV cmd*

Oct 29 20:23:36: AAA/AUTHOR (2728515295): Post authorization status = PASS_ADD

Oct 29 20:23:36: AAA/AUTHOR/EXEC: Authorization successful

Oct 29 12:24:29 PST: AAA: parse name=tty2 idb type=-1 tty=-1

Oct 29 12:24:29 PST: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0

Oct 29 12:24:29 PST: AAA/MEMORY: create_user (0xDFB0D0) user='' ruser='' port='tty2' rem_addr='66.119.192.4' authen_type=ASCII service=LOGIN priv=1

Oct 29 12:24:33 PST: tty2 AAA/AUTHOR/EXEC (2127628565): Port='tty2' list='' service=EXEC

Oct 29 12:24:33 PST: AAA/AUTHOR/EXEC: tty2 (2127628565) user='mksmith'

Oct 29 12:24:33 PST: tty2 AAA/AUTHOR/EXEC (2127628565): send AV service=shell

Oct 29 12:24:33 PST: tty2 AAA/AUTHOR/EXEC (2127628565): send AV cmd*

Oct 29 12:24:33 PST: tty2 AAA/AUTHOR/EXEC (2127628565): found list "default"

Oct 29 12:24:33 PST: tty2 AAA/AUTHOR/EXEC (2127628565): Method=tacacs+ (tacacs+)

Oct 29 12:24:33 PST: AAA/AUTHOR/TAC+: (2127628565): user=mksmith

Oct 29 12:24:33 PST: AAA/AUTHOR/TAC+: (2127628565): send AV service=shell

Oct 29 12:24:33 PST: AAA/AUTHOR/TAC+: (2127628565): send AV cmd*

Oct 29 12:24:33 PST: AAA/AUTHOR (2127628565): Post authorization status = PASS_ADD

Oct 29 12:24:33 PST: AAA/AUTHOR/EXEC: Processing AV service=shell

Oct 29 12:24:33 PST: AAA/AUTHOR/EXEC: Processing AV cmd*

Oct 29 12:24:33 PST: AAA/AUTHOR/EXEC: Processing AV priv-lvl=15

Oct 29 12:24:33 PST: AAA/AUTHOR/EXEC: Authorization successful

Oct 29 12:25:14 PST: AAA: parse name=tty2 idb type=-1 tty=-1

Oct 29 12:25:14 PST: AAA: name=tty2 flags=0x11 type=5 shelf=0 slot=0 adapter=0 port=2 channel=0

Oct 29 12:25:14 PST: AAA/MEMORY: create_user (0xDFA9FC) user='' ruser='' port='tty2' rem_addr='66.119.192.4' authen_type=ASCII service=LOGIN priv=1

Oct 29 12:25:21 PST: tty2 AAA/AUTHOR/EXEC (3934820085): Port='tty2' list='' service=EXEC

Oct 29 12:25:21 PST: AAA/AUTHOR/EXEC: tty2 (3934820085) user='tech1'

Oct 29 12:25:21 PST: tty2 AAA/AUTHOR/EXEC (3934820085): send AV service=shell

Oct 29 12:25:21 PST: tty2 AAA/AUTHOR/EXEC (3934820085): send AV cmd*

Oct 29 12:25:21 PST: tty2 AAA/AUTHOR/EXEC (3934820085): found list "default"

Oct 29 12:25:21 PST: tty2 AAA/AUTHOR/EXEC (3934820085): Method=tacacs+ (tacacs+)

Oct 29 12:25:21 PST: AAA/AUTHOR/TAC+: (3934820085): user=tech1

Oct 29 12:25:21 PST: AAA/AUTHOR/TAC+: (3934820085): send AV service=shell

Oct 29 12:25:21 PST: AAA/AUTHOR/TAC+: (3934820085): send AV cmd*

Oct 29 12:25:21 PST: AAA/AUTHOR (3934820085): Post authorization status = PASS_ADD

Oct 29 12:25:21 PST: AAA/AUTHOR/EXEC: Authorization successful

Oct 29 12:26:04 PST: AAA/MEMORY: free_user (0xDFB0D0) user='' ruser='' port='tty2' rem_addr='66.119.192.4' authen_type=ASCII service=ENABLE priv=15

Oct 29 12:26:04 PST: AAA/MEMORY: free_user (0xDF9DCC) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Oct 29 12:26:04 PST: AAA: parse name=tty0 idb type=-1 tty=-1

Oct 29 12:26:04 PST: AAA: name=tty0 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=0 channel=0

Oct 29 12:26:04 PST: AAA/MEMORY: create_user (0xDFB0D0) user='' ruser='' port='tty0' rem_addr='async' authen_type=ASCII service=LOGIN priv=1

Mike

Where is the list no_tacacs assigned in the configs, if anywhere?

I forgot to ask you to send debug aaa authentication as well.

Hello:

Well, leave it to a CCIE to have me check log output. :-) Okay, so I actually have a different problem, and I think you had eluded to this previously.

On both the router and switches, you can get enable access with a user that is specifically set up as a non-enabled user on the ACS. Here is the output from the authen log:

Oct 29 21:34:51: AAA/AUTHEN/START (3748040429): port='tty3' list='' action=LOGIN service=ENABLE

Oct 29 21:34:51: AAA/AUTHEN/START (3748040429): non-console enable - default to enable password

Oct 29 21:34:51: AAA/AUTHEN/START (3748040429): Method=ENABLE

Oct 29 21:34:51: AAA/AUTHEN (3748040429): status = GETPASS

Oct 29 21:34:53: AAA/AUTHEN/CONT (3748040429): continue_login (user='(undef)')

Oct 29 21:34:53: AAA/AUTHEN (3748040429): status = GETPASS

Oct 29 21:34:53: AAA/AUTHEN/CONT (3748040429): Method=ENABLE

Oct 29 21:34:53: AAA/AUTHEN (3748040429): status = PASS

Oct 29 21:34:53: AAA/AUTHEN: free_user (0x54622684) user='' ruser='' port='tty3' rem_addr='66.119.192.4' authen_type=ASCII service=ENABLE priv=15

I apologize for leading you (and myself) down the wrong path. So, the short question is, how to block an un-privileged user's access to enable?

Mike

Hi Mike,

My guess is you have the list 'no_tacacs' assigned the the tty ports above.

Keep in mind the statement:

aaa authentication enable no_tacacs enable

Creates a list named 'no_tacacs" and means to use the enable secret in the router/switch instead of consulting the AAA Server for enable. This is of course, if you have the 'no_tacacs' list assigned to the ports with the 'login authentication no_tacacs' command applied.

There are many ways to do this, but here is my suggestion, beginning with the end in mind.

Assuming you do not want anyone except the router superusers into privilege level 15, change the privilege of the enable command from 1 to 15 by using this command:

privilege-exec level 15 enable

BEFORE you do this ensure you have assigned privilege level 15 to your superuser group and it is a good idea to create a local as a backup like:

aaa authorization commands 15 default group tacacs+ local

username mike privilege 15 password

Now, anyone without privilege level 15 will be denied with this message in the router when attempting to get into enable mode:

%Authorization failed command

This is not the recommended solution if you wish to allow the tech2 group to get into enable mode and perform some priv lvl 15 commands. Let me know if this is what you want, I have another solution for that.

Hope this helps...

Robert

Hi Robert:

Okay, I think I have it figured out now, with the help of the URL you sent. Here's my "new" AAA config:

aaa new-model

aaa authentication login default group tacacs+ local

aaa authentication login no_tacacs enable

aaa authentication enable default group tacacs+ enable

aaa authorization exec default group tacacs+ local

aaa authorization commands 1 default group tacacs+ local

aaa authorization network default group tacacs+ local

aaa accounting commands 1 default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

Now, it checks the AAA server for commands and I have given them the Tech a level of 1, which is duplicated on the ACS. It seems to be working as expected now.

Thanks for all of the help!

Mike

Great, and if tne no_tacacs list is not used on any port, you can delete that line.

Thanks for using Cisco products.

Cheers

Robert