Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

enable_1 command authorization failed after "disable"

I have AAA configured on an ASA 8.0(3) to a CiscoSecure ACS server as follows:

aaa authentication http console tacacs-group LOCAL

aaa authentication enable console tacacs-group LOCAL

aaa authentication serial console tacacs-group LOCAL

aaa authentication ssh console tacacs-group LOCAL

aaa authorization command tacacs-group LOCAL

aaa accounting enable console tacacs-group

aaa accounting ssh console tacacs-group

aaa accounting serial console tacacs-group

aaa accounting telnet console tacacs-group

aaa accounting command privilege 15 tacacs-group

aaa authorization exec authentication-server

Everything works except when disconnecting - a privileged exec account is able to "exit" or "logout" as expected, but if a privileged exec account first reverts to User Exec mode by issuing the "disable" command, no further commands are authorized.

For Example:

ASAPrimary# disable

ASAPrimary> exit

Command authorization failed


In the Failed Attempts log of the ACS server I see the "Author Failed" message type from the user "enable_1" ...

It seems that when an authenticated/authorized user exits enable mode the ASA "loses" the account name, and any further commands are issued by this "enable_1", which does not exist locally or on the ACS server or any external DB's so authorization is failing. This is annoying, as it disallows the ability to change modes, as after a user "disable"s they can then not "enable" again either...

Is this behavior expected? Any insight appreciated.

P.S. When first connecting to the ASA a user is in User Exec mode. Before issuing the "enable" command, the user is able to "exit", "logout", etc. so I know those commands are authorized for known users.


Re: enable_1 command authorization failed after "disable"

To send accounting messages to the TACACS+ accounting server when you enter any command other than show commands at the CLI, use the aaa accounting command command in global configuration mode. To disable support for command accounting, use the no form of this command.If you customize the command privilege level using the privilege command, you can limit which commands the security appliance accounts for by specifying a minimum privilege level. The security appliance does not account for commands that are below the minimum privilege level.

use the command "aaa accounting command privilege 0 tacacs-group" instead of "aaa accounting command privilege 15 tacacs-group " which may solve the issue.

Refer the url below for more information:

New Member

enable_1 command authorization failed after "disable"

I just ran into this issue also.  I use PERL's Net::Appliance::Session modules to login to devices and it will attempt to disable the terminal paging automatically if configured to do so.

It will connect, enable, "terminal pager lines 0", and disable before handing back to PERL for the next call.

On my ACS integrated firewall (FWSM 4.x, multi-context) it will stop due to "Command authorization failed" when I try to do anything.

Recreated condition manually and confirmed it.  ACS reports that "enable_1" user does not exist.  "Subject not found in the applicable identity store(s)"

Is there a way to maintain the username when the "disable" command is given?

Cory C.

New Member

I have the exact same issue.

I have the exact same issue. Have you found a solution to this yet?