cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
617
Views
0
Helpful
3
Replies

EMM submits null user to aaa authentication

lyranvolcrane
Level 1
Level 1

I attempted to setup an mdf for the emm system on one of our lab routers. The router duplicates the common conditions at all of our retail locations.

The router (an 871 with IOS advanced IP services 12.4(22)T), and you can see the aaa configuration in the attached text file.

And there are pre-shared keys that allow the router to authenticate with the Cisco ACS server (ACS for windows version 4.1)

I used the example from http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_emm.pdf to test the functionality of the application example at the end of the document.

Overall the mdf file is working correctly, the tcl shell appears to be correctly parsing xml script when you use "eem mdf ..." in configuration exec mode to bring the MDF into memory for user exec access. However when I attempt to login with a tacacs user in a group that has shell access, and then a separate enable login with privilege 15 rights.

When I attempt to run the menu "Test" using "emm Test" the menu does appear and I don't receive any errors. But when I attempt to do something as basic as the option for "show ver" The TCL engine reports command authorization failed.

I am befuddled as to why this is the case, and all of the research I have done on this issue (which is about 3 hours of research sadly) points to something about the emm system attempting to use another user session to execute the command, instead of using the existing user session I am in.

I have looked at the debugging of the emm system while running the "Test" menu and I get the following result from debugging aaa authentication when attempting to use option 1 in the script (show ver):

Jul 25 01:39:34 CDT: AAA/MEMORY: create_user (0x837F10A8) user='NULL' ruser='XREMOTE2gw' ds0=0 port='tty2' rem_addr='async' authen_type=ASCII service=NONE priv=1 initial_task_id='0', vrf= (id=0)

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): Port='tty2' list='' service=CMD

Jul 25 01:39:34 CDT: AAA/AUTHOR/CMD: tty2(3761820496) user=''

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): send AV service=shell

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): send AV cmd=show

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): send AV cmd-arg=version

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): send AV cmd-arg=<cr>

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): found list "default"

Jul 25 01:39:34 CDT: tty2 AAA/AUTHOR/CMD(3761820496): Method=tacacsserver (tacacs+)

Jul 25 01:39:34 CDT: %AAA/AUTHOR/TAC+: (3761820496): no username in request

Jul 25 01:39:34 CDT: AAA/AUTHOR/TAC+: (3761820496): send AV service=shell

XREMOTE2gw#

Jul 25 01:39:34 CDT: AAA/AUTHOR/TAC+: (3761820496): send AV cmd=show

Jul 25 01:39:34 CDT: AAA/AUTHOR/TAC+: (3761820496): send AV cmd-arg=version

Jul 25 01:39:34 CDT: AAA/AUTHOR/TAC+: (3761820496): send AV cmd-arg=<cr>

Jul 25 01:39:34 CDT: AAA/AUTHOR (3761820496): Post authorization status = FAIL

Jul 25 01:39:34 CDT: AAA/MEMORY: free_user (0x837F10A8) user='NULL' ruser='XREMOTE2gw' port='tty2' rem_addr='async' authen_type=ASCII service=NONE priv=1 vrf= (id=0)

It appears that the script is attempting to execute "show ver" as a null user, and the aaa system fails authentication for the related command immediately.

I do know that other tcl scripts work on this router, but those scripts always authenticate as the user who runs them. The menu appears to execute commands with a null user, ignoring what user runs them.

Is there is a workaround, or has this been fixed in subsequent releases?

1 Accepted Solution

Accepted Solutions

yjdabear
VIP Alumni
VIP Alumni

The basic symptom seems like this bug:

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

But quite a number of other aspects don't match, particularly because other tcl scripts work.

The bug is supposedly fixed in 12.4(22)T2, so maybe you're inclined to give that version a try and see if it cures your issue by collateral.

View solution in original post

3 Replies 3

yjdabear
VIP Alumni
VIP Alumni

The basic symptom seems like this bug:

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

But quite a number of other aspects don't match, particularly because other tcl scripts work.

The bug is supposedly fixed in 12.4(22)T2, so maybe you're inclined to give that version a try and see if it cures your issue by collateral.

Yes, this is the bug. I filed this against tclsh, so it also affects EMM. And yes, the fix was integrated into 12.4(22)T2.

Fantastic everyone! I will look at this now, and I think I saw that bug too, but I wasn't 100 percent sure that it was exactly what was being talked about.

I guess it is time to upgrade again!

I will report back what I find.

Getting Started

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: