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).