Bugzilla – Bug 79096
connmgr.nlm notifies nsure audit of a user logout after the logout is finished
Last modified: 2006-04-19 16:56:12 UTC
------- Bug moved to this database by jkestner@novell.com 2005-04-20 11:08 ------- This bug previously known as bug DEFECT000397120 at remedy/ remedy/show_bug.cgi?id=DEFECT000397120 Originally filed under the Nsure Audit product and Instrumentation - NetWare FS component. --------- <remedy_details> PROBLEM STATEMENT: connmgr.nlm notifies nsure audit of a user logout after the logout is finished. Nsure Audit is suscribed for notifications of the nwds logout event. When this event is triggered, cnnmgr is sending the event info after the logout function is done. Auditnw.nlm calls getconnidentity and getconninfo to obtain the information about who logged out. The problem is, that when the notification happens after the logout is complete, the information that should be returned in those calls is gone. In the 6.5 SP1 build, they changed the code in LogoutConnection to send the event at the end (after the connection had been logged out). Ross Doxey says that this happened to fix a defect that he will now do some research on. PLATFORM / CONFIGURATION: NetWare 6.5 SP1/SP2/OES, Nsure Audit 1.0.2/1.0.3/Huron (1.5) STEPS TO REPRODUCE: Install Nsure Audit per TID 10091433. Configure the NetWare instrumentation to notify us of NetWare logouts. Log into the tree using the novell client, and then log out of the workstation. Query the naudit database for Log Outs, the logout event will be present, but the end user name will not be present. Additionally, map a drive to the server using CIFS with NO Novell client. After connecting to the server, log off the workstation. The log out event will not contain any data. RESULTS:Log out event does not contain the necessary data to determine who logged out. EXPECTED RESULTS: We should be able to see the user name and IP address of the perpetrator. WORKAROUNDS / COMMENTS: We were not registered properly in 1.0.2, and 1.0.3, however in NSure Audit Huron, our latest build will have a change made to notify us inline. However this change still requires connmgr.nlm to work as it did prior to SP1. We are now the RegisterForEventNotification call instead of the RegisterForEvent call. </remedy_details> --------- <remedy_notes> dhorne ( 1/6/2005 11:08:24 AM Fixing - ) Request for NetWare to own their own instrumentation in accordance with changes made to their event processing within their product. bhieb ( 1/5/2005 3:56:38 PM Fixing - ) Can we have Nile look into the latter part of what rdoxey has suggested? rdoxey ( 1/5/2005 2:34:15 PM Open - ) I did a little research and found that the EVENT_LOGOUT_CONNECTION event was moved/changed quite a long time ago. In fact, it was moved to the end of the LogoutConnection routine on 3-5-2000. Here's the changes.log entry that went along with it: 27) FIXED a problem from the Data Center. We now generate the Logout event after finishing the Logout code. The problem was that DS assumes the connection is usable when they receive the Logout Event (which was being generated at the beginning of the Logout code). (LOGIN.C) 3-5-2000 Jim This change was made and would be fixed this way in v5.sp5, v51.sp1 and all of v6.x. It is a little surprising that it was only noticed now. Anyway, there are several things to consider. I don't think that it would be an option to move this same event back up to where it used to be. It obviously was causing problems that have gone away since the fix. I don't want to add or change the existing event since it is a fairly heavily used one and might affect behavior of registered callers. So I see several options. One, we can define a new event and put it just after (or before) the existing EVENT_LOGOUT_CONNECTION and have it return in a structure, the connection number, the login name, and the connection address. Then you wouldn't have to query the connection manager APIs to get the info that you need. The downside to this, is that it would only exist in v65.sp3 and newer unless patches were made and distributed for prior versions. The other option is to have nsure audit register for the EVENT_LOGIN_CONNECTION which will provide the connection number. Then nsure could make the same API calls that it currently does on the logout event, and store this info based on the connection number. Then when a logout event occurs, nsure would already have the name and connection address. The advantage of this is nsure would then work correctly on all version of netware that it runs on instead of having to have a patched connection manager and server to recognize the new event. I am willing to go either route, depending on what people think. </remedy_notes>
This has been recently duplicated. The suggestion being made on this bug, basically says that auditnw should keep a list of all of the connection numbers and the data that goes with them, and then when the logout is triggered, reference that information to log the data. This would probably make auditnw unstable, and make auditnw hog memory. This suggestion also assumes that auditnw would not ever be unloaded, as if we were unloaded, we would then lose the little connection table we keep. Something to consider would be, what happens when someone logs out after auditnw has been loaded. What happens if someone logs in before auditnw gets loaded? We will not have matching information, or worse mismatched information when the log out event occurs. We should push the OS team to work on creating a new API that we can register for.
We discussed this in a defect review meeting a month or two ago. Those present were Tom Larsen, Rich Brunt, Brian Hieb, Doug Eddy, and Rob Beauchamp. We discussed the pros and cons of an API and we came to a conclusion that a new API for Novell Audit would not be an appropriate thing to do. Rich suggested that the Audit team do what Ross Doxey suggests, and that is to keep track of connections similar to what connection manager does. Yes, it is a duplication of effort, but it does ensure that we get the data we are looking for. As far as memory is concerned, it does not appear to be very memory intensive. The downside to this is time. It would take time to write the code and then to test it. Since they had Novell Audit 2.0 (Huron) in beta, it was decided that they would not be able to add it in until a future time. I think this is more of a defect than an enhancement. We sell our product as an auditing solution and we tell our customers that we audit logins and logouts. Yet when you look closely at the product, the logout information provided is incomplete. And that doesn't look good to our customers because in their eyes, it simply does not work.
Talked to Troy Rovig on CPR team. We need to understand the changes that were made to Login.c back on March 2000. I called and left a message for Ross Doxey to see if we can track down the original defect from March 2000 and find out who fixed it then, etc. Maybe if we can get the original defect number from March 2000, we can look it up and see what happened.
Added 2 fields in what gets passed to the callback for anyone registered for the event EVENT_LOGOUT_CONNECTION. This was requested by the NSure audit team. Now, in addition to the connection number, the login name and the network type, length and address are passed to the callback. This won't affect anyone not looking for these fields, but for those that are, they will be available. (LOGIN.C) Fixed in v65.sp5. The additional info that is now returned besides the connection number is the username and the network address info. This is composed of three parameters: UINT32 connection number /*existing parameter previously returned */ unsigned char * loginName /* this is the new 2nd parameter returned consisting of a byte length preceeded login name */ unsigned char * addressBuffer /* This is the new 3rd parameter returned consisting of a buffer that has the network address type in the first byte, the network address length in the second byte, and then the network address according to the length of the 2nd byte */
This needs to be assigned to Doug now, I think. Either that or marked resolved and verified, once Doug is finished with the fix
Doug Eddy has worked this through with the NW OS folks. They provided another callback to get the proper information. With the new connmgr from 10/25/05 and the auditnw.nlm for 1.0.3 of 10/25/05 this appears to be fixed. The same fix must be merged into the 2.0 tree. The 1.0.3 bug is fixed. The bug is now set to monitor getting this merged into the 2.0 FCS product.
now merged into 2.0
*** Bug 105016 has been marked as a duplicate of this bug. ***