12-31-2011 03:20 AM - edited 03-10-2019 06:40 PM
Hi all,
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.
Thank you.
Solved! Go to Solution.
01-09-2012 04:29 PM
Hello Alex,
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 | |
Symptom: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 authorizationConditions: Workaround: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.
Regards.
01-03-2012 11:31 AM
Hello Alex,
Which specific IOS version is your 2960 switch running? Is it running 15.1(4)M or 15.1(4)M1?
I am thinking on known issues that affect AAA behavior on newer IOS versions like 15.0 and 15.1. If you are running on a 15.x version can you downgrade the IOS version of your switch to any 12.2 version other than 12.2.58 and test again?
Will be waiting for your response with the results.
Regards.
01-08-2012 11:41 AM
Hello Carlos,
Thank you for your reply. The switch is running c2960s-universalk9-mz.122-55.SE3. What actual caveats do you suspect?
01-09-2012 10:29 AM
Hello Alex,
There are known issues that affect IOS 15.x when it comes to AAA and HTTP. For example:
Can you share both the "running-config" of your switch along with the "debug aaa authentication", "debug aaa authorization", "debug tacacs" and "debug ip http all" outputs after recreating the issue by managing the device from CNA?
Regards.
01-09-2012 04:29 PM
Hello Alex,
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 | |
Symptom: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 authorizationConditions: Workaround: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.
Regards.
01-13-2012 08:44 AM
Wow, very impressive.
I looked for possible bugs (though I was using goggle) and didn’t find those (and I'm not exactly a novice).
Thank you Carlos and thank you Kush.
01-09-2012 01:10 PM
Hi Alex,
There is a bug in the ACS wherein telnet/SSH auth to switch works however authenticaiton through CNA fails.
Here are the symptoms for the bug:
Symptom: When you attempt to log into a switch running network assistant you get authenticated but fail authorization. The error you get is "13011 Invalid TACACS+ request packet - possibly mismatched Shared Secrets" shared key has been verify as good. It appears that the issue looks more like a problem with "authen_type 0" in the ACS 5 code
Can you please check the ACS --> tacacs authorization logs and verify if this is the error message which you get?
Regards,
Kush
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide