Restricted Command List on Switches using ACS 5.1

Paul Williams · ‎07-13-2010

All

I am working on setting up a restricted command set on ACS 5.1 so that users can access swicthes only at designated privilege levels and hence only get access to certain commands as defined on the ACS servers.

So far I have set up a Shell Profile with Default privilege of 0, and a maximum privilege of 2. The user is authenticated using our AD servers and everything is fine and they can login to the switch and get privilege 0 access.

However I cannot work out how to restrict the commands that are available to them. I have set up a Command Set on the ACS with one command in it ("show run interface" with a wildcard argument), but the commands are not restricted on the switch and it can run some commands that they should not be able to.

I guess what I am looking for is a step-by-step guide as to what configuration needs to be on the switch and how the ACS needs to be set up. There is a lot of information on the Cisco Site, but none of it is really what I need - it tells you everything and explains nothing. I have question that need to be answered like, will the command set accept short form command (i.e. sh run int) or do they have to be word for word as the CLI, if they are defined as per the CLI, what happensif a user tries to use a short code, how do I remove or hide commands from the list when a user types ? at a prompt.

So many questions, so little time.

BTW we are using TACACS.

Paul Williams · ‎07-16-2010

As per previous...

I have now got some commands working on the switch using a command set on ACS. But its not where I want it to be.

All I want is for a user to be able to log in to a switch and get a restricted set of commands available to them, for example I want them to be able to type "show running-config interface fa0/1" and see what the speed and duplex settings are....

I have a shell profile set up that give access at level 0, with a maximum of level 2 (accessed by using the "enable 2" command, and a central password checked against our AD via ACS).

At the moment I am permitting "show priv" and "show interfaces", but I have tried every combination of everything else I can think of and it fails to let me do a show run type command.

I need to know what I am missing on the switch (if anything) and what I need to allow on the command set.

The switch aaa looks like this....

aaa new-model
aaa group server radius accounting-group
aaa group server radius authentication-group
aaa authentication banner ^C
aaa authentication login default group authentication-group local
aaa authentication login MGMTAUTH group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authentication dot1x default group authentication-group
aaa authorization config-commands
aaa authorization commands 1 default group tacacs+ none
aaa authorization commands 2 default group tacacs+ none
aaa authorization auth-proxy default group authentication-group
aaa accounting commands 15 default stop-only group tacacs+
aaa session-id common

Help would be gratefully accepted as I am beginning to think that this does not work as advertised.....!!!!

Przemyslaw Konitz · ‎08-10-2010

Im testing ACS 5.1 by my own right now and I think your problem is that "show run" has priv level 8. This command is not seen when you got level 2.

you can try to change privilege for this:

privilege exec level 2 show running-config

and after that you should be able to run it (with the exception that show runn will show only commands allowd from command set or rather privilege level I think )

hope this helps

regards

Paul Williams · ‎08-10-2010

Unfortunatelty thats what I am trying to avoid. I have about 2500 switches which I would then need to roll out this change to

- and I want to expand the commads available - hence I would need to set up a priv command for each command I want the level 2 users to have access to.

perhaps it is me not understanding what ACS is capable of - but my understanding is that the command sets feature should over-ride the local priv commands, or at least yoy should be able to tell it to do that....

Przemyslaw Konitz · ‎08-10-2010

I see your problem but actually even if you give the user priv-lvl 15 as a shell-profile result, they still will be restricted to command-set (which works fine).

Maybe it sounds like security violation but that user will not be able to do much according to command-set.

Paul Williams · ‎08-10-2010

Ah I get it - give the user level 15 access, but then restrict what commands they can use.

Hence I can have a number of command sets with varying commands available, and then apply the command set based on the user.

Thanks I will try this.

alecchris · ‎10-30-2010

Hi... I have created a shell profile in Policy Elements -> Authorization and Permissions -> Device Administration -> Shell Profiles which has a assigned privilege level of 15 and a max privilege level of 15. Further to this I have added a new commands set via Policy Elements -> Authorization and Permissions -> Device Administration -> commands sets.

I have referenced the shell profile via Access Policies -> Access Services -> Default Device Admin -> Authorization. And this part of it seems to work fine, but the command set I am using to restrict the commands allowed is not being used...do I need to reference the command set somewhere else within the ACS platform as well? The configuration I have added on to the Network Device is as follows: -

aaa new-model

aaa authentication login default group tacacs+

aaa authentication enable default group tacacs+

aaa authorization config-commands

aaa authorization exec default group tacacs+ local

aaa authorization commands 15 default group tacacs+ none

Can you advise what it is I am missing?

jrabinow · ‎10-30-2010

I think you need to include command sets as a result in authorization policy

Goto: Access Policies -> Access Services -> Default Device Admin -> Authorization

Press "Customize" and select Command Sets as an avalable result

You should now be able to select the command set you desire as a result in the authorization policy