Specific shell command authorization - ACS/TACACS+ on 2900XL

[3m.landry]

Hello all -

I've been struggling with one particular issue here. I'm running ACS 3.2, and trying to set up secure access to my switches. I have "grad students" from my university that I want to allow to perform specific functions, i.e. change a port's vlan, and write to memory, etc.

I successfully set up the authorization piece, and my test account can log in. I successfully assign a privilege level of 7 also, which gives me basic look rights by default. Accounting is also working, showing the connections and commands I enter.

What I want to do is use ACS to enable a specific group of commands, so I can change them if needed in one place (ACS) and not have to touch 400+ devices. ACS says it can do it, but it doesn't seem to work. I created a Shell Command Group and specififed the commands, no luck. Even if I modify the "Unmatched commands" toggle to "permit" (which should allow any commands, right?) it still doesn't allow any commands. I added the Shell Command group to the group the students are members of...

My AAA commands are as follows:

aaa new-model

aaa authentication login default local group tacacs+

aaa authorization exec default local group tacacs+

aaa authorization commands 7 default group tacacs+

aaa accounting exec 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+

Any ideas? Any thoughts?

Thanks!

Michael

QU.edu

[sstudsdahl · Accepted solution]

Michael,

You are performing command authorization for commands that exist with a privilege level of 7. By default, configuration commands have a privilege of 15. There are two ways that you can go about solving this issue. The first would be to setup command authorization for level 15. The second would be to change the privilege level of the commands that you want your grad students to be able to run from level 15 to level 7. This can be done with the privilege command. Here is a link that shows the use of it locally within the device. http://www.cisco.com/warp/public/480/PRIV.html

I am not sure if ACS can push the config to the device on a per-user basis, so the first option may be your best bet. Just remember to permit access to all commands for yourself.

Steve

[3m.landry]

Steve -

Thanks for the prompt response. I figured out the first solution late last night, and was able to make it work by giving the test account Privilege 15 access, but restricting commands through the ACS.

I knew about the second solution, but I'm trying to avoid any configurations that would require touching each device in order to make future changes.

Thanks again for your help!

[3m.landry]

THIS JUST IN! :)

Things are working perfectly EXCEPT one thing. When I use local console access to the switch, I can authenticate against the TACACS server, or login with a "local" admin account. Unfortunately, it spits the user out at Privilege 1, not with full enable rights. This defeats my goal of letting my grad students get in, without giving out the local telnet and/or enable passwords. Anyone have any ideas?

Current AAA config:

aaa new-model

aaa authentication login default local group tacacs+

aaa authorization exec default local group tacacs+

aaa authorization commands 15 default local group tacacs+

aaa accounting exec default start-stop group tacacs+

aaa accounting commands 15 default start-stop group tacacs+

aaa accounting system default start-stop group tacacs+

[sstudsdahl]

Michael,

You can use the TACACS+ server to define the privilege level you want the specific accounts to have. You can do this on a per group basis or a per user basis. If you edit a group or username within ACS, the particular location to set this up would be in the "TACACS+ Settings" section, then under "Shell (exec)" you will find an option for "Privilege Level". For the local account, you can define a privilege level by adding the keywork privilege 15 to the username.

One thing you might keep in mind is what happens if the switch is unable to talk to the TACACS+ server. I am not sure how command authorization will work when using a local user account. In the event that the TACACS+ server is unreacheable, you may not be able to configure the switch. You might consider the keywork if-authenticated on your aaa authorization line as a last resort. This should allow you to still configure the switch if TACACS+ is down and you are using local authentication.

Steve

[3m.landry]

Hello Steve -

Thanks for the quick responses. Please let me clarify a bit, I guess I didn't give enough info.

I _do_ have the Privilege 15 setting in place in ACS, and if I login to the switches via telnet, I receive a level 15 Privilege, with only a single username/password authentication.

If I connect via the console port, I log in using the same username and password, and I am authenticated by ACS. However, I get spit out at Priv 1, not 15, and I have to enter "enable" and the enable password to reach Level 15. I'm trying to figure out what's different for console login vs. telnet login.

I hope that's more clear. I have to look back through the past discusssions, I remember hearing of a command for the console port that is undocumented, I think it might be related...

Thanks again for your help!

Michael

[sstudsdahl]

Michael,

Sorry about my confusion. I believe I understand now. I think that command that you are refering to may be privilege level 15. Adding this to the "line con 0" configuration will take you directly to level 15 once you authenticate in via the console.

Steve

[3m.landry]

Hey Steve -

I tried your recommendation, and it works, kinda. When I turn on that command, after authentication, I get dropped in at Privlege 15 and have full access to commands.

Unfortunately, this is different than the telnet access in a key way; when I telnet in, I get Priv-15, but I'm restricted on commands I can do based upon ACS authorization of specific commands. When I console in, I have full access to all commands, with no restrictions.

Additionally, my console access has two level security, with a login password (to Priv-1) and an enable password (to Priv-15). When I use the "Privilege level 15" command, it bypasses the enable password for the local accounts and allows full access with just the login password.

Maybe I'm asking for too much. (And I appreciate your patience with me!) What I want on the console port is this:

1. A username prompt

- this is fine

2. A password prompt

- this is fine also

3. User name & PW are authenticated against ACS

- this works

4. If user is a valid ACS user, they should receive Priv-15 rights and be restricted by the commands they are authenticated to use in ACS

- this does not work. They only receive Priv-15 if I use "privilege level 15", but they are not restricted at all to certain commands. (They _are_ restricted under telnet however.)

5. If a user is not a valid ACS but a local account exists, the user gets dumped to a Priv-1 prompt, and must enter the enable to get to Priv-15. (This also is how it works under telnet.)

Sorry if this really confusing, it's difficult to explain in a forum. I'm basically looking for the same behavior from a console connection as from a telnet connection; I'm not sure why it's so difficult to do...

Michael

[3m.landry]

Steve -

I felt bad bugging you more, so I opened a TAC case. The answer was immediate: it can't be done on that model switch with that code. They did not allow console authorization, to keep you from hurting yourself. See the response from TAC below. I'm considering this a closed issue now, nothing I can do, they won't put out new software for this old switch. THANKS for all your help!!

Michael

==========

Hi! For many years, console port authorization was not supported on IOS devices (the idea was this would make it easier for folks to accidentally shoot themselves in the foot). This was eventually implemented in later images with CSCdi82030 which you can view on the web at http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl. If the version you're running has this feature, you would enable with the 'aaa authorization console' command. If you don't see the version you're on listed in Bug Toolkit & the version you're on does not have the command & it's a fairly recent version, this would be unimplemented on the switches at this time. Please let me know if this answers your question.

[sstudsdahl]

Michael,

Thanks for the update. I am glad that I could help out as much as I could, it has not been a bother what so ever. I find I learn quite a bit in the forums and that they are a good way to keep my skills up to date.

From the looks of it, your best implementation would be to have your grad studens telnet into the switches to perform the work. This will definitely be an issue if the switch is offline or the tacacs+ server is unavailable for some reason.

Another option that you could look at for console access would be changing the levels of some of the commands as you were previously looking at. The problem there goes back to having to touch every device. If you have CiscoWorks2000 at all, the process of touching all of the devices can be automated. Basically you would create a job to do the configuration for you. I am not sure if there is an open source application out there that could do that in place of CW2K or not. If not, that sounds like it could be a good project for a grad student to undertake. :)

Steve