ACS 5.0 geting error "authorization command failed"

Unanswered Question
Sep 6th, 2010

Hi All,

Its a Cisco Acs 1120 device having version 5.0.

I have cerated three basic user group which having privillage leve 15,10 and 1 on ACS Tacacs+.

My configuration for AAA on Switch is as follows

aaa authentication login default group tacacs+ local
aaa authorization config-commands
aaa authorization exec default group tacacs+ local
aaa authorization commands 1 default group tacacs+ local
aaa authorization commands 7 default group tacacs+ local
aaa authorization commands 10 default group tacacs+ local
aaa authorization commands 15 default group tacacs+ loca



ip tacacs source-interface Vlan1
tacacs-server host **** single-connection
tacacs-server directed-request

but I am getting error while login from that spacific user which I have created but getting errror as

"commond authorization failed "

Plz let me know if any one have solution on this or any more information required for this..

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Nathaniel Austin Tue, 09/07/2010 - 13:22

Hi Pranav,

Based on your config below you have command authorization configured on your IOS device, but you only mentioned privilege levels on the ACS configuration. If you enable command authorization on the device then you need to ensure that a command set is referenced in your access policy rules.

Under the Authorization section of your Network Access Policy there should be two "results" columns - one for "Authorization Profiles" and a second for "Command Sets". If the latter does not show, hit the Customize button on that page and select it. Now edit your rule and select a value for the Command Set. I believe by default there is an Allow ALL and Deny ALL set that you can reference. If you would like to get mor granular you can create your own under Policy Elements > Authorization and Permissions > Device Administration > Command Sets.



Pranav Gade Wed, 09/08/2010 - 03:40

Hi Nate,

Thanks for your reply, I tried doing what you have mentioned in your post. It is still not working for me.

The problrm what I see is all users are going under admin profile with privilege level 15. As I also defined command sets for admin just for testing purpose, so that is getting applied. Thus eventhough all users representing privilege level 15 they don't have full access. This case occurs when I define authorization under line vty.

When I remove those commands from line vty the operation is same only thing is as all are under privilege level 15 so they are granted full access.

So basically what is happening is the shell profiles and command sets created by me in reality are not getting called.

All users are somehow getting privilege level 15 and thus no further checks occuring, this is what my understanding says.

I tried doing all different sets and all but nothing working.

Please assist, thanking you all in advance.


Pranav Gade.

Nathaniel Austin Wed, 09/08/2010 - 06:00

Hi Pranav,

You shouldn't have to enable any authorization specifically on the VTY lines since you are using the default method lists for all of them. What does your vty line config look like?

Are there any failed authorization attempt logs on the ACS box when you receive the command authorization failure? It should say what rules were matched on the ACS.



Pranav Gade Wed, 09/08/2010 - 06:52

Hi Nate,

Following is the error message received by me:-


The request command failed to match permit rule in any of the command sets.

When I click on "tacacs Auhorization" for monitoring please find the below table order:-

1. status

2. details

3. Failure reason

4. user name

5. command sets

6. shell profile

7. network device

8. header privilege level

9. access service

10. selected authorization policy

11. selected authorization exception policy

12. selected command set

13. acs

Please assist what can be done.

Waiting for reply.

Thanks and regards,


Nathaniel Austin Wed, 09/08/2010 - 06:59

Hi Pranav,

Can you post the value of those fields instead of just the fields themselves? Or a screenshot of the entire report for a failure (just click on the report icon next to the failure)?

Realistically we are interested in the following fields values:

Access service

Selected authorization policy

Selected command set



Nathaniel Austin Wed, 09/08/2010 - 08:13


What does the "admin" command set contain, can you send a screenshot of that?

In terms of the config for your rules, why do you have Privilege-Level as a condition? The privilege level that you want to send to the clients is sent from the ACS to the NAS in the authorization profile.



Pranav Gade Wed, 09/08/2010 - 08:22

Hi nate,

As of now as we were doing testing, so we have just allowed enable, show*, configure terminal commands for admin, then for netmon enable, show* and for ssst denyall.

Our actual requirement is we want to give full access to admin users, ssst will have access to only show commands and netmon will have interface level command access and few show commands.

But our problem is for all users enable, show*, configure terminal getting applied.

Thanks and Regards,


Pranav Gade Thu, 09/09/2010 - 21:59

I am still waiting for this issue to get resolved........

Please assist....



Nathaniel Austin Fri, 09/10/2010 - 05:09

Hi Pranav,

Its hard to tell from the limited view in the screenshots why all of your users are hitting the same profile. One thing I mentioned before was removing the Tacacs-Privilege-Level as a condition for hitting a rule as I can't see why you would want to do that since you are passing the privilege level back in your shell profile set. It seems like all attempts from the NAS are coming in with a header priv-lvl of 15 and so all are hitting your first rule. So I would remove that "Compound Condition" from your rules and just do it by user group and let the result sets define the privilege levels.

If you send a full screenshot (not just part of the page) from the details section of the authorization then I can tell you exactly why it is hitting those rules, but theres just not enough information in the half page that was sent.

If the above doesn't help then at this point I would open up a case as it is becoming difficult to go back and forth on this forum and I believe if you opened a case and someone saw this live it would go much faster.



Pranav Gade Sat, 09/11/2010 - 08:48

Thanks nate for your reply, I will try today doing it without privilege-level.... and will update, I am also trying to open a case but as its not inside warranty things not moving in my favor...

let me work on it again fresh.. will get back to you ASAP....



Pranav Gade Sun, 09/12/2010 - 04:46

Hello all,

Please find below attached slides of my entire ACS configuration...

Please assist... attaching more in next posts...



ranjit123 Tue, 07/09/2013 - 00:55

Hi Pranav,

Any resolution on the same as i am also facing the same issue.



Tushar Gaba Tue, 07/09/2013 - 01:36

Hi Pranav and Ranjit ,

Lets start fresh on this .

The configuration on switch is ok .

We first need to differentiate if we want to restrict commands based on different user groups on ACS or we just want to differentiate privilege levels .

The simplest way to do it is that on ACS we create different authorization rules for different groups with a shell profile of privilege 15 in every rule and differentiate on command sets .

With this implementation every user no matter which group they belong to will land on the switch with privilege 15 but will have differentiated access based on command sets .

Basic Concept :: when we use default as method list we do not need to apply the same going individually on the vty lines .

example : aaa authentication login default group tacacs+ local .

Look forward to hear from you .

Regards ,

Tushar Gaba .

mmangat Tue, 07/09/2013 - 19:39


Just to know have you have you associated network group with the user group? and have you enabled  command set?

ranjit123 Wed, 07/10/2013 - 01:24

Hi Tushar & Mantej,

The issue of authorization has been resolved now and i am able to define 3 different groups with corresponding access priviledges. Same has been mapped in shell profiles and command sets.

Now as per my requirement my 1 User in particular location (NDG) should not get access to other region or NDG, i am not able to achieve this.

waiting to hear from you all




This Discussion