Problem with ACS/tacacs user for router backups only

[darthnul]

I run a process every night that logs into about 500 routers via ssh and pulls the running-config for backing up. This has run for quite a while with a tacacs login account that has privilege level 15.

I want to change this process to run with a user with privilege level "5", who should only be able to log in a run the "show running-config", "show privilege", and "terminal length 0" commands. I'm using Cisco Secure ACS 5.4. The routers are 891 moodels running IOS 15.1.x(T).

On ACS I created a local user called "shrunni", a shell profile for Priv level 5, a command set that allows only the two commands above, and addded an authorization rule to allow that user to login to the appropriate devices, and assign the shell profile and command sets mentioned above.

On my lab router I added the following commands to my already function aaa config:

aaa authorization commands 5 default group tacacs+

privilege exec level 5 show running-config

privilege exec level 1 show

privilege exec level 5 terminal length

I can log into the lab router with the "shrunni" account without any issues. I get a "#" prompt as that user. ACS reports a successful authentication.

I can verify that I have priv level 5 with the "show privilege" command.

When I try to do a "show running-config", I just get returned to a command prompt. ACS shows that the command was authorized successfully. Running a "debug aaa authorization" from a second ssh session to the router shows everything was authorized.

I'm not sure where to go from here when it ACS logs and router debugs say it should have worked but no config was ever displayed.

I know I could give the "shrunni" user level 15 privs and assign a limited command set but to enforce that command set I'd have to authorize all level 15 commands but for performance (and other) reasons, I don't want to do that.

Full aaa router config follows:

aaa new-model

!

!

aaa authentication login default group tacacs+ local

aaa authentication login NO_AUTHEN none

aaa authentication login SSH group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa authorization commands 1 default group tacacs+

aaa authorization commands 5 default group tacacs+

aaa accounting delay-start

aaa accounting session-duration ntp-adjusted

aaa accounting exec default

action-type start-stop

group tacacs+

!

aaa accounting commands 15 default

action-type start-stop

group tacacs+

!

[nspasov]

You have the following commands:

    aaa authorization exec default group tacacs+ local

     aaa authorization commands 1 default group tacacs+

     aaa authorization commands 5 default group tacacs+

Those commands are instructing the NAD to "look" at the AAA server for authorization. Thus, as long as your AAA server is "alive" I don't think these local commands are considered:

     aaa authorization commands 5 default group tacacs+

     privilege exec level 5 show running-config

     privilege exec level 1 show

I have done something similar before for some NOC users. I configured them to be automatically set to privilege level 15 but then assign them a command shell profile that only permits them show run and some debug commands. Thus, even though they are set to privilege level 15, they are only able to run a limited set of commands.

Let me know if this makes sense.

Thank you for rating helpful answers!

[Richard Burts]

The original poster may not think so, but the behavior that he described is correct and the commands did what they are supposed to do. It is one of the behaviors of setting privilege level that a user at less than level 15 may execute show running-config but the results will only display elements that this user is able to affect or change. And since the privilege level 5 user can not change anything then nothing shows up in the results of show running-config.

The best solution of this is not to use privilege levels but to use a command shell profile as described in the previous post.

HTH

Rick

[darthnul]

Thanks for the reply Rick. It does help!

Is there anything magical about level 15 or would this work if I created a level 14 and made that pretty much a copy of level 15?

I don't have any problem restricting the commands available to the backup user but that requires enabling command authorization on the devices for the priv level they're at, and I don't want to do that for level 15. The human admins with level 15 access often paste large ACLs into their router SSH sessions and I don't want to introduce delays caused by hundreds of command auth checks per ACL reload.

[Richard Burts]

I certainly appreciate your point about not wanting to impact human users who are operating at level 15.

To answer your question there is not much magical about privilege level 15, except that it all just works there. You certainly should be able to configure some other level (14 or 5 or whatever), include the appropriate commands, and then use command authorization to prevent most of the commands from being executed. I predict that there will be a certain amount of trial and error to get the right set of commands specified for the new level - but it should be possible to accomplish.

Good luck with it.

HTH

Rick