Command Auth Failure on ASA5510 using ACS5.1

[stevedaviescisco]

Hi all,

I'm having trouble getting things working on a pair of ASA5510's using Cisco Secure ACS v5.1. We were previously using a much older version of ACS to these (and a lot of other) devices which worked OK for remote access for read/write use. Am in the process of migrating to the new ACS software and have got it working OK to everything (many Cisco switches and other IOS devices) except these ASA5510s.

I can get TACACS authenticating fine and am able to log on and go into enable mode. Any subsequent commands are then met with 'command authorization failure', including 'show run', 'conf t' and even 'exit'!

My ASA5510 config has not changed, other than to define the new AAA server, which leads me to think its something to do with how I have the ACS user profile set up. I have configured the ACS5.1 device administration Shell Profile to have the maximum privilege level (15) and the command set I'm using has the box checked 'permit any command that is not in the table below'.

Have tried several suggestions of adding custom attributes to the shell profile, but to no avail. I'm totally stuck! - can anyone help?

Cheers,

Steve

[Jatin Katyal]

Steve,

You're getting "command authorization failure" because the request is not matching the right authorization policy where you have sleceted the command set. I would suggest you to open Monitoring and reports >> Launch Monitoring and report viewer >> catalog >. AAA protocol >> Tacacs authorization.

Looks for the latest attempt and click on the magnifying glass there to fetch detailed information. If you won't able to figure it out then post it here.

Regards,

Jatin

Do rate helpful posts-

[stevedaviescisco]

Hi Jatin,

Thanks for responding - I'll try that out and let you know how I get on. Hopefully it should give me some more clues!

Cheers,

Steve

[stevedaviescisco]

Hi all,

OK, have followed Jatin's suggestion of finding my unauthorised commands in the TACACS authorization logs in ACS. Have compared them to some working commands on other devices managed by the same ACS piece and the results have completely stumped me again!

When I examine a failed command, I can see that it has recognised all the correct profiles (device name, device group, user name, user identity group), and has matched the Access Service Selection rule for 'Default Device Admin' and then also matched the Authorization Policy rule within that - all exactly the same as any working command on any of the other devices (switches etc). However, every command put in on the ASA still fails to select a shell profile and instead I pick up a command set 'DenyAllCommands'.

I have tried changing the default shell profile to the one we use generally (called 'Priv 15') in Device Administration Authorization Policy, but that also makes no difference.

I've been through the configuration of all aspects of the Network resources, User & identity stores, Policy elements and access policies and I cannot find any discrepencies or indeed anything that would differ these ASA5510s from any of the other devices that are working fine. Again, I'm stuck!

Does anyone know why these ASAs would be treated any differently to other AAA clients? Are there any precidents set for ASAs working with this level of ACS?

Thanks again,

Steve

[stevedaviescisco]

Hi Jatin,

OK, I have followed your suggestion of finding my unauthorised commands in the TACACS authorization logs in ACS. Have compared them to some working commands on other devices managed by the same ACS piece and the results have completely stumped me again!

When I examine a failed command, I can see that it has recognised all the correct profiles (device name, device group, user name, user identity group), and has matched the Access Service Selection rule for 'Default Device Admin' and then also matched the Authorization Policy rule within that - all exactly the same as any working command on any of the other devices (switches etc). However, every command put in on the ASA still fails to select a shell profile and instead I pick up a command set 'DenyAllCommands'.

I have tried changing the default shell profile to the one we use generally (called 'Priv 15') in Device Administration Authorization Policy, but that also makes no difference.

I've been through the configuration of all aspects of the network resources, User & identity stores, Policy elements and Access policies and I cannot find any discrepencies or indeed anything that would differ these ASA5510s from any of the other devices that are working fine. Again, I'm stuck!

Do you know why these ASAs would be treated any differently to other AAA clients? Are there any precidents set for ASAs working with this level of ACS?

Thanks again,

Steve

[m-avramidis]

I have exactly the same problem/issue on a 2901 running IOS 15.2(X). Below is the AAA configuration that I use:

tacacs-server host XX.XX.XX.XX single-connection key 0 XXXXXXXXXXX

tacacs-server host XX.XX.XX.XX single-connection key 0 XXXXXXXXX

aaa authentication fail-message ^Wrong Username/password, Try Again or Use Local Account^

aaa authentication login default tacacs+ local

aaa authentication enable default tacacs+ enable

aaa authorization commands 15 default if-authenticated

aaa authorization reverse-access default if-authenticated

aaa accounting exec default start-stop tacacs+

aaa accounting commands 15 default start-stop tacacs+

aaa accounting connection default start-stop tacacs+

aaa accounting system default start-stop tacacs+

!

ip tacacs source-interface loopback81  

!

line vty 0 4

exec-timeout 10 0

session-timeout 5

logging synchronous

transport input telnet ssh

!

I do not have this problem when using our "old" 4.1.X ACS Appliances... Btw, I have followed exactly the same configuration (on the ACS 5.3) that can be viewed in AAA section (coomunity). I am not in the office when writing this response = will add the output from debugging AAA authorization later today. But the output ends with an %authorization-failed%... Any ideas? Anyone?

[stevedaviescisco]

Hi,

I think I've sussed my problem out and got it working this end eventually - it wasn't a problem with the ACS config after all, but for some reason the newer versions of ACS don't seem to like it when you have the 'aaa authorisation commands*' command in your config.

Try removing the line 'aaa authorization commands 15 default if-authenticated' from your 2901 config and see if that makes a difference. I'm not sure of the long-term implications, but doing the same on my ASA5510 certainly seemed to resolve things for me.

Cheers,

Steve

[Jatin Katyal]

So you're saying the request is matching all the condition's and parameters. Did you check if we are getting the right command set.

What is default rule set to, deny all commands?

If yes, could you please set it to permit all commands for a testing purpose.

Here is link for your refrence:

http://www.security-solutions.co.za/Cisco-ACS-5.2-Role-Based-Authentication-Authorization-For-Different-Privilege-Levels-Configuration-Example.html#_Toc299569582

Regards,

Jatin