Actually the disparity between logon & logoff events is usually due to token leaks: Here's an excerpt from an offline mail I sent to Rainer: A logon audit is generated when a logon session is created, after a call to LogonUser() or AcceptSecurityContext(). The logon session is uniquely identified by a number called a Logon ID, which is listed in the audit. A logoff audit is generated when a logon session is destroyed. The logoff audit can be correlated to the logon audit using the Logon ID, regardless of the logon type code. A logon session is associated with a token, and can't be destroyed until the token is destroyed. A token can't be destroyed while it is being used. When an application or system component requests access to the token, the system increases the reference count on the token, to keep it around even if the original owner goes away. A well-behaved application closes the handle to the token when it's finished with it, causing the reference count to be decremented. When the reference count reaches 0, the token is destroyed, the logon session is destroyed, and the logoff event 538 is generated. A poorly-behaved application can exhibit a class of bug called a token leak. A token leak is when an application requests access to the token, increasing the reference count, and then loses track of the handle- in effect, the reference count is never decremented and can never reach 0, and Windows can't destroy the token and generate the logon event. We identified a number of token leak issues in the OS and fixed them for SP4. It is still possible for tokens to leak; the existing token architecture has no back-reference capability associated with the reference count so we can't eliminate this class of bug at this time. We identify and fix all token leaks that we find in the OS, but many third party applications have this problem. For reference, logon types are all listed in NTLSA.H in the Platform SDK. -----Original Message----- From: loganalysis-bouncesat_private [mailto:loganalysis-bouncesat_private] On Behalf Of Taylor, Gord Sent: Thursday, June 19, 2003 7:00 AM To: 'LogAnalysisat_private'; 'rgerhardsat_private' Subject: [logs] Comments on Event ID 538 Explained I saw your request for comments on the LogAnalysis mailing list, and thought I'd contribute the following experiences. While the logon type may be inaccurate in the 538 event, you can correlate to the associated 528 (Logon) event using the Logon ID which looks something like (0x0,0x5B45F1). This Logon ID is used for all security events occuring during that logon session, including the 538 event. I've also found that, for domain controllers and members servers, you will typically have fewer 538 events than 528 events. I believe this is attributed to users undocking/BSOD/powering off - where no actual logoff occurs - and the resources being used simply timeout. Thanks Gord T. ------------------------------------------------------------ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ============================================================ _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Mon Jun 23 2003 - 10:52:41 PDT