Showing results for 
Search instead for 
Did you mean: 
Choose one of the topics below to view our ISE Resources to help you on your journey with ISE

This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.


Why does "Only Show" allow the enable command, but prevent "show" commands?

I'm having trouble understanding AAA processing logic. I just followed this guide to set up differentiated user level authentication profiles via TACACS+ on ACS version 5.6:

This aaa model on the switch did not work at all:

aaa new-model
aaa authentication login default group tacacs+ local enable
aaa authorization console
aaa authorization exec default group tacacs+ 

Because even though ACS was configured to allow his user group "Only show" commands, a "maximum privilege level" of 1 still allows a user to enable the device if he knows the enable password. It wasn't until the following was added to the configuration:

aaa authentication enable default group tacacs+ enable

That the users were prevented from enabling the router, but only after it allowed them to attempt to input the enable password:

% Error in authentication.

We would rather prevent users in this lower level group access to the enable command all-together and prefer that the command set "Only Show" really meant "Only Show".

Is there a reference somewhere that clearly outlines the aaa decision tree and the configuration elements that affect each branch of that tree. Why would authorization associated to a shell profile that allows "Only show" commands NOT allow a SHOW RUN which is a show command, but would allow "enable" which is NOT a show command?  

(I get that the reason "show run" failsis that "show run" is a priv 15 command, but does that mean "enable" is a priv 1 comand?)



I guess what I'm saying is

I guess what I'm saying is that it functions like command authorization doesn't do anything - that the authentication part of aaa is really what's in control of access to certain commands. Regardless of the authorization policy assigned to a given user, if the authentication piece doesn't preclude a user from enabling the device, then command authorization has no effect. Why does it appear this way?


I ran into a similar issue.

I ran into a similar issue. For command authorization to work in the first place, the switch/router needs to be send the commands for authorization to the ACS using  a command similar to:

aaa authorization commands X MyList group tacacs+ local

where X is the command level.

I found out that "enable" is a level 0 command, while I was authorizing level 1 and 15 only, so my command set blocking the "enable" command was never invoked.


" There are five commands associated with privilege level 0: disable, enable, exit, help, and logout. If you configure AAA authorization for a privilege level greater than 0, these five commands will not be included in the privilege level command set. "

Hope this helps.