Bug 79096 (DEFECT000397120)

Summary:	connmgr.nlm notifies nsure audit of a user logout after the logout is finished
Product:	[Novell Products] Nsure Audit	Reporter:	Brian Hieb <bhieb>
Component:	Instrumentation - NetWare FS	Assignee:	Doug Eddy <deddy>
Status:	VERIFIED FIXED	QA Contact:	Will Hoffman <whoffman>
Severity:	Normal
Priority:	P2 - High	CC:	rich.brunt
Version:	1.0.3	Keywords:	English
Target Milestone:	2.0 (Huron) FCS
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Jane Kestner 2005-04-20 17:08:09 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>

Comment 1 Brian Hieb 2005-09-01 23:25:44 UTC

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.

Comment 2 Tom Larsen 2005-10-12 19:59:59 UTC

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.

Comment 3 Tom Larsen 2005-10-13 19:11:53 UTC

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.

Comment 4 Forgotten User vusWmY-zAE 2005-10-18 20:04:46 UTC

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 */

Comment 5 Brian Hieb 2005-10-19 18:09:54 UTC

This needs to be assigned to Doug now, I think. 
Either that or marked resolved and verified, once Doug is finished with the fix

Comment 6 Doug Beattie 2005-10-25 20:40:45 UTC

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.

Comment 7 Doug Eddy 2005-10-26 19:23:58 UTC

now merged into 2.0

Comment 8 Randy Stevens 2005-11-30 02:12:22 UTC

*** Bug 105016 has been marked as a duplicate of this bug. ***