topic More "command authorization failed" issues in Network Access Control

More "command authorization failed" issues

ghuey — Mon, 11 Mar 2019 01:44:55 GMT

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.

More "command authorization failed" issues

ghuey — Fri, 20 Jan 2012 16:07:13 GMT

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

Re: More "command authorization failed" issues

camejia — Fri, 20 Jan 2012 17:56:57 GMT

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.

Re: More "command authorization failed" issues

ghuey — Fri, 20 Jan 2012 22:22:14 GMT

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

Re: More "command authorization failed" issues

camejia — Tue, 24 Jan 2012 00:03:56 GMT

Hello,

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

Best Regards.

Re: More "command authorization failed" issues

ghuey — Tue, 24 Jan 2012 15:55:23 GMT

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.