Solved: Cisco CNA: Sending empty commands

Alex Kitaichik · ‎12-31-2011

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.

camejia · ‎01-09-2012

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

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz24369

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 authorization

Conditions:

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.

View solution in original post

camejia · ‎01-03-2012

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.

Alex Kitaichik · ‎01-08-2012

Hello Carlos,

Thank you for your reply. The switch is running c2960s-universalk9-mz.122-55.SE3. What actual caveats do you suspect?

camejia · ‎01-09-2012

Hello Alex,

There are known issues that affect IOS 15.x when it comes to AAA and HTTP. For example:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtq94595

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.

camejia · ‎01-09-2012

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

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsz24369

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 authorization

Conditions:

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.

Alex Kitaichik · ‎01-13-2012

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.

Kush Srivastava · ‎01-09-2012

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