cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
583
Views
5
Helpful
6
Replies

Username field in RME Change Audit Standard Report

Jeff Law
Level 1
Level 1

I am using RME 4.0.5 on a Windows Server.

I have just noticed a problem, or what I think is a problem, relating to the Username field on the Change Audit Standard Report.

I have a Daily Periodic Polling job configured to run at 22:10 in the COnfig Collection Settings.

It does this, and when I run the report I can see lots of entries with the message "System Config Polling Job: VLAN-RUNNING" (see attached snapshot), so I gather it is running.

The question I have relates to the Username. Every now and then it changes. It starts with admin, but when it gets to a device it will change the user name. This name is the name of a user who has connected to the device during the course of the day. The Connection Mode for this device is TELNET, and this username will continue to be displayed as the user of the job until the next time it comes across a device with Connection Type of Telnet and a different user has logged on to that device.

I would have thought that as the job is a scheduled one, through the system, the user name would always be admin (that is what it starts with), and would not change.

I should point out that each days results are different in which device the username changes.

For eaxmple, yesterdays report started with the user admin and changed after 49 devices. Todays report started with user admin and changed after 19 devices (it also changed to a different user from the one yesterday)

Thankfully the polling of the devices is always done in the same order so it makes it easy to check this - when the report is sorted by Creation Time.

Has anyone else experianced a similar result? (I hope the above makes sense)

Regards

Jeff

6 Replies 6

Joe Clarke
Cisco Employee
Cisco Employee

The way Change Audit works is this. If a config change is detected via a syslog message, and that message has a username in it, then RME will record that username as the one that made the change. If, however, there is no username in the message, or the change is picked up via polling, RME will attempt to resolve a username using the ccmHistoryEventTerminalUser object from the CISCO-CONFIG-MAN-MIB. If that username is missing, then RME will insert an internal user ID.

This sounds good until you look at the case where the config change is picked up via polling, and the method for retrieving the config is one of TELNET or SSH (i.e. an interactive protocol). In that case, the user RME uses to login to the device is recorded as the last ccmHistoryEventTerminalUser. Then, when Change Audit polls that object it gets the RME user, and not the actual user that made the config change.

The moral of the story is that the username shown in Change Audit should strive to be the user that made the relevant change. If you are seeing obviously wrong information, then you may have found a bug.

isn't it in fact a problem of the workflow, i.e. the sequence of the individual steps? If the config change is picked up via polling a potential config change did occure. At this point ccmHistoryEventTerminalUser could still reveal the last username. So RME should first try to get the username and afterwards fetch the config to check if a real config change did occure.

With this little change telnet/ssh as the config fetch method would still give the correct username. I know that there is the potential of unecessary traffic in case no config change will be detected but I think due to accuracy this is ok.

would it be possible to have this little change reflected in LMS 3.2 ?

No. LMS 3.2 is already set. The bits are getting ready for manufacturing now.

And in general? would it be possible to let LMS be more accurate with a change like this ?

Possible, yes, but not as trivial as you might expect. The biggest problem comes when you have multiple LMS (or other config archive servers). We see this in our lab all the time, but customers with redundant LMS servers would see this as well. Even if you get the CONFIG-MAN record before the archive op, you're still in a race with other servers, or other people trying to make a config change.

That said, I did find a bug in the way we fetch this data. We are treating every row in the ccmHistoryEventTable as a potential config change, when that is not the case. This bug was relatively easy to fix, and gives a much higher chance that the Change Audit record will be correct. I filed CSCsz91572 to track this.

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: