Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Success Audit|
User Name: <user name>
Logon ID: <logon id>
Logon Type: <logon type>
|English: This information is only available to subscribers. An example of English, please!|
This event indicates a user logged off. The corresponding logon event (528) can be found by comparing the <logon id> field.
A logon id (logon identifier or LUID) identifies a logon session. A logon ID is valid until the user logs off. A logon ID is unique while the computer is running; no other logon session will have the same logon ID. However, the set of possible logon IDs is reset when the computer starts up.
A logon id has the following format (0x0, 0x4C37A2) and it is unique for each logon/logoff process.
Events that generate a logoff and their corresponding logon type:
- Interactive logoff will generate logon type 2
- Network logoff will generate logon type 3
- Net use disconnection will generate logon type 3
- Autodisconnect will generate logon type 3
For a list of logon types see the link to the "Windows Logon Types" article.
In many cases, the user listed for this event will be "ANONYMOUS LOGON" from "NT AUTHORITY" domain. This logon is used by processes that use the null session logons (logons that do not require a user/password combination). Any program or service that is using the System user account is in fact logging in with null credentials.
If the operating system encounters a user without any credentials, the user is regarded as having NULL credentials. When the system attempts to access a secured network resource based on NULL credentials, this is referred to as a NULL session. Access is only allowed if the remote machine allows NULL session access. This is configurable through the registry. (See Knowledge Base article ME122702 for more information.)
One typical example is a computer that register itself with the Master Browser for that network segment at startup. This registration will generate several logon/logoffs from "ANONYMOUS USER". Since the registration is renewed by default every 12 minutes, such events will occur at regular intervals.
From a mailing list, a post from a Microsoft engineer:
"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."
One of the consequences of a token leak that you may find that not all the logon events (i.e. event id 528) have a corresponding logoff (538).
See the link to "Event-ID-538-Explained" for further explanations on this event.
This event record indicates that a user has logged off. See MSW2KDB for more details.
See ME318253 for a hotfix applicable to Microsoft Windows 2000 if you do not receive this event when you should.
If you configure an audit policy to audit successful logon and logoff events, you may find that the user logoff audit event ID 538 is not logged to the security event log after you shut down your computer and then restart it. See ME828857 for information on how to troubleshoot this particular problem.
See ME140714 for additional information on this event.
Kevin N Chapman
As per Microsoft: "If you configure an audit policy to audit successful logon and logoff events, the user logoff audit event ID 538 may not be logged to the security event log after you log off or shut down your Microsoft Windows 2000-based computer. However, the user logon audit event ID 528 is logged to the security event log every time that you log on". See ME828020 for a hotfix applicable to Microsoft Windows 2000.
|Private comment: Subscribers only. See example of private comment|
|Links: ME122702, ME140714, ME174074, ME318253, ME828020, ME828857, Windows Logon Types, Tracking Logon and Logoff Activity in Windows 2000, Online Analysis of Security Event Log, Event-ID-538-Explained, MSW2KDB|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (3) - More links...|
Send comments or solutions
- Notify me when updated