01-20-2012 07:57 AM - edited 03-10-2019 06:44 PM
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.
01-20-2012 08:07 AM
Just to add more info, the ACS log appears to show that everything is fine:
|
|
01-20-2012 09:56 AM
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.
01-20-2012 02:22 PM
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 | ||
| ||
Generated on:January 20, 2012 10:20:52 PM UTC | ||
| ||
|
01-23-2012 04:03 PM
Hello,
You need to use Shell Profiles (Assigning Privilege level 15) and Command Sets allowing the appropriate commands for the restricted user.
Best Regards.
01-24-2012 07:55 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: