I'd encountered the following situation – while working with Cisco's CNA (Cisco Network Assistant) on a 2960 switch, any change done by this tool is sent out as an empty set of commands, to a TACACS server to approve.
Let me explain. I have 2960 switch, a PC with CNA on it and brand new ACS 5.2. This switch is set up for TACACS+ authorization. While working with TELNET/SSH, all commands are authorized properly. When doing "debug aaa authorization", you can see the commands are being sent to a TACACS server (as expected) for approval. And what is more important – within the debug output every command appears at "AV CMD= …" and "Arguments = …" Those commands seen by the ACS and approved correctly.
But, when working with CNA, those fields (i.e. av cmd and arguments) are empty in the first place. Hence all what ACS does see are "empty commands" and no clue for the correct ones (say, changing interface's description). The HTTP server has it set of authorization commands.
I had no time to dig into it. Maybe someone encountered a similar problem before? Post here the correct settings (as he/she thinks) to authorize CNA? Anyhow, every suggestion will be appreciated.
I think I have narrowed the issue. Unfortunately, I have bad news
I recreated this on my lab using a 3750 switch running IOS version 12.2(55)SE3, ACS 5.3 and Cisco Network Assistant 4.1 and 5.7.
I configured the following:
aaa authentication login httpauth group tacacs+ local
aaa authorization exec httpauthor group tacacs+ local
aaa authorization commands 0 httpcommands group tacacs+ local
aaa authorization commands 1 httpcommands group tacacs+ local
aaa authorization commands 15 httpcommands group tacacs+ local
ip http server
ip http authentication aaa login-authentication httpauth
ip http authentication aaa exec-authorization httpauthor
ip http authentication aaa command-authorization 0 httpcommands
ip http authentication aaa command-authorization 1 httpcommands
ip http authentication aaa command-authorization 15 httpcommands
ip http secure-server
The above configuration binds the AAA feature for Authentication, User Authorization and Command Authorization for HTTP(S) access to the IOS. However, the ACS reports [CmdAV=] as you stated on your first post when a "Restricted" users performs changes on the IOS device configuration through CNA.
I performed debugs and captures when performing changes with a CLI Restricted user (CLI works fine) when using CNA. No Command is send to the TACACS+ server to validate as no command is send from the Application (CNA) for the IOS to authorize.
Performing a deeper research I found the root cause of the issue
|AAA authorization is very inconsistent when using CNA|
When using CNA to configure the switches not all configuratin options
being done are passed through the AAA command authorization on the switch.
Some configuration options are and some cofniguration options are not
passed through the AAA command authorization
Do not use CNA when command authorization is required
It seems to be a CNA application bug and not an IOS or ACS related issue. The caveat is no fixed yet, however, it is listed to be fixed with CNA 6.0 (I do not have an ETA for CNA 6.0 release).
I hope this helps.