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

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

More "command authorization failed" issues

I have read the other posts from users with this issue, but their solutions have not helped in my case.

Fully patched 5.3 ACS virtual server.  Sample switch config AAA setup:

aaa new-model

aaa authentication login default group tacacs+ local-case

aaa authentication enable default group tacacs+ enable

aaa authorization commands 15 default group tacacs+ if-authenticated

Now I can authenticate against the ACS server with no problem, and I even show the user as being at priv level 15 but attemting to run a "sh run" causes the command authorization failed issue.  See below:

username: jack

password:

OPS-3524PWR>sh priv

Current privilege level is 1

OPS-3524PWR>en

password:

OPS-3524PWR#sh priv

Current privilege level is 15

OPS-3524PWR#sh run

Command authorization failed.

OPS-3524PWR#

Now I am not super strong with cisco so I am not totally clear on all the AAA settings.  What is even stranger is that when I tested this in a lab environment against a 3400 it worked fine.

In my ACS I simply have a shell profile called Level 15 that should give any authenticated user that level of access.  Under the Common Tasks for the shell profile the only setting I have set is Maximum Pirvilege as "Static" and Value is "15".

Appreciate any help.

5 REPLIES
New Member

More "command authorization failed" issues

Just to add more info, the ACS log appears to show that everything is fine:

Authentication Details

Status:

Passed

Failure Reason:

Logged At:

Jan 20, 2012 4:04 PM

ACS Time:

Jan 20, 2012 4:04 PM

ACS Instance:

sls-acs.testdomain.com

Authentication Method:

PAP_ASCII

Authentication Type:

ASCII

Privilege Level:

15

User

Username:

jack

Remote Address:

172.30.1.152

Network Device

Network Device:

SL-OPS-3524PWR

Network Device IP Address:

172.30.1.57

Network Device Groups:

Device Type:All Device Types, Location:All Locations

Access Policy

Access Service:

Default Device Admin

Identity Store:

Internal Users

Selected Shell Profile:

Level 15

Active Directory Domain:

Identity Group:

All Groups:Engineers

Access Service Selection Matched Rule :

Rule-2

Identity Policy Matched Rule:

Default

Selected Identity Stores:

Internal Users, Internal Users

Query Identity Stores:

Selected Query Identity Stores:

Group Mapping Policy Matched Rule:

Authorization Policy Matched Rule:

Rule-1

Authorization Exception Policy Matched  Rule:

Other

ACS Session ID:

sls-acs.slfiber.com/116213333/139

Service:

Enable

AV Pairs:

Response Time:

10

Other Attributes:

ACSVersion=acs-5.3.0.40-B.839
ConfigVersionId=66
Protocol=Tacacs
Type=Authentication
Action=Login
Port=tty1
Action=Login
Port=tty1
UserIdentityGroup=IdentityGroup:All  Groups:Engineers

Authentication Result

Type=Authentication
Authen-Reply-Status=Pass

Steps

Received TACACS+ Authentication START  Request

Evaluating Service Selection Policy

Matched rule

Selected Access Service - Default Device  Admin

Evaluating Identity Policy

Matched Default Rule

Selected Identity Store - Internal  Users
Looking up User in Internal Users IDStore -  jack
Found User in Internal Users  IDStore
TACACS+ will use the password prompt from global  TACACS+ configuration.
Returned TACACS+ Authentication  Reply
Received TACACS+ Authentication CONTINUE  Request
Using previously selected Access  Service

Evaluating Identity Policy

Matched Default Rule

Selected Identity Store - Internal  Users
Looking up User in Internal Users IDStore -  jack
Found User in Internal Users  IDStore

Authentication Passed

Evaluating Group Mapping Policy

Evaluating Exception Authorization  Policy

No rule was matched

Evaluating Authorization Policy

Matched rule

Returned TACACS+ Authentication  Reply

Additional Details

Diagnostics ACS Configuration Changes
Silver

Re: More "command authorization failed" issues

Hello,

As you have "aaa authorization commands 15 default group tacacs+ if-authenticated" configured have you created the appropriate Command Set allowing ALL commands on the ACS and are you matching the appropriate authorization rule?

I am attaching an example of command authorization.

If this was helpful please rate.

Regards.

New Member

Re: More "command authorization failed" issues

Thank you Carlos for the information, but I am still running into issues.  I have mainly been focusing on Profile Shells, but did attempt using Command Sets.

Based on the screenshots in your example it appears that you are using Command Sets only and no Profile Shells as part of your Policy rules.

When I only use Command Sets my two test users from each of the test groups can log in, but now my superadmin user cannot go into "enable" mode using this example.  Here is the error, but I am confused as I removed the Shell Profile as a condition all together.

Failure Reason > Authentication Failure Code  Lookup

Failure Reason :

13029  Requested privilege level too high
Generated  on:January 20, 2012 10:20:52 PM UTC

Description

The TACACS+  user requested a higher privilege level than the Maximum Privilege Level  configured in the Shell Profile

Resolution Steps

Check the  SelectedShellProfile attribute to verify that the expected Shell Profile was  selected by the Authorization policy
Silver

Re: More "command authorization failed" issues

Hello,

You need to use Shell Profiles (Assigning Privilege level 15) and Command Sets allowing the appropriate commands for the restricted user.

Best Regards.

New Member

Re: More "command authorization failed" issues

Update...appears that I have the basics working although I am not real comfortable with the process.  First I removed all "aaa authorization" commands hoping that I could just deal with authentication.

Changed this line:

aaa authentication enable default group tacacs+ enable

to this:

aaa authentication enable default group tacacs+

So aaa was only configured with the following lines:

aaa new-model

aaa authentication login default group tacacs+ local-case

aaa authentication enable default group tacacs+

With this change everything worked as expected.  My non-admin level users were stuck at priv 1 and could not change to enable mode.  My admin level user could switch to enable mode and run all privileged commands.  Not really understanding why that worked I set the changed line back by adding "enable" on the end again and everything continued to work.

So I am really at a loss as to what happened, and I am concerned that there is something else going on to give me these inconsistent results.


3876
Views
0
Helpful
5
Replies
CreatePlease login to create content