Event ID 538 Explained

Abstract

In this paper, I will try to explain the Event ID 538 and some of the problems associated with it and what can be done to remove these problems.

Events Involved

The following events are involved in the discussion in this paper:

Event 538 — User Logoff

What is Event ID 538?

If you audit for logon events, every time a user logs on or logs off at a computer, an event is generated in the security log of the computer where the logon attempt occurs [3]. As we are specifically interested in Event ID 538 in this paper so I will not digress away by explaining other Event IDs. Event ID 538 is generated when a user log offs. Following are the parameters that are associated with this Event ID 538 [4]:

User Logoff
User Name
Domain
Logon ID
Logon Type

When is Event ID 538 Generated?

Event ID 538 can be generated under one of the following conditions [1]:

Event ID 538 Possibilities	Logon Type
Network Logoff	3
Net use disconnection	3
Auto-disconnect	3
Interactive Logoff	2

Problem with Event ID 538

1. According to the above mentioned table, when a user log offs interactively, an Event ID 538 should be generated with a Logon Type = 2. But in most of the situations this does not happen. When a user log offs interactively, still an Event ID 538 is generated with Logon Type = 3. Due to this problem, a Network Administrator is not able to distinguish between an actual Interactive Logoff and the rest of the types mentioned above in the table. Microsoft has confirmed that this problem occurs in the following products [2]:

Microsoft Windows 2000 Server SP1
Microsoft Windows 2000 Server SP2
Microsoft Windows 2000 Server SP3
Microsoft Windows 2000 Advanced Server SP1
Microsoft Windows 2000 Advanced Server SP2
Microsoft Windows 2000 Advanced Server SP3
Microsoft Windows 2000 Professional SP1
Microsoft Windows 2000 Professional SP2
Microsoft Windows 2000 Professional SP3

2. Sometimes Event ID 538 is logged many times without corresponding Logon Events. This problem is also very commonly seen in the security newsgroup of Microsoft.

Detailed Explanation of Problems

Eric Fitzgerald of Microsoft has explained the cause of the problem # 1 mentioned above. Whenever a user logs on, a logon session is created that is uniquely identified with a number, called Logon ID which is logged as a parameter with the event in the Windows Security Log. Similarly, when a user log offs, then under normal conditions, this logon session is destroyed and an entry is made into the Windows Security Log with a Logon ID similar to the one with which the session was created. In other words, we can correlate these log on and log off events based on the Logon IDs and irrespective of the Log on type that is mentioned above.

The logon session that has been described above is associated with a token. When a system component or any other application requests access to this token, the system increases the reference count to this token. In other words, if the reference count to this token is not zero, the system will assume that it is currently being used by some application or some system component. This token cannot be destroyed until the reference count to it becomes zero and the logon session with which this token is associated with, cannot be destroyed until the token is destroyed. In other words, a logon session can only be destroyed if the reference count to the token that is associated with it is zero.

Theoretically, an application closes the handle to the token when its finished with it and this reduces the reference count to it. When the reference count reaches zero, the token is destroyed which in turn destroys the logon session causing an Event 538 to be generated in the Security Log. Practically this rarely happens! The main reason for this behavior are some applications that exhibit something which is called a “Token Leak”. A “Token Leak” occurs when an application requests access to the token described above and then looses the handle to it. Now when the application is finished, the reference count to the token is not decremented and the system assumes that still the token is in use by some application which further means that the reference count would never reach zero. As explained above, if the reference count to a token is not zero, the logon session would not be destroyed which means that a log off session would not be generated.

Microsoft has identified a number of token leak problems within the OS and have removed them in SP4. Since the current token architecture has no back reference capabilities so Microsoft currently cannot guarantee the complete removal of this problem because of the third party poorly designed applications that are mainly responsible for the Token Leaks.

The above described problem would be more severe with a machine that has lot of applications on it and would be less severe on a freshly installed system. We are currently in the process of testing this problem on a freshly installed OS. I will update this paper as soon as I get some results.

Proposed Solution

In response to Problem 1, Eric Fitzgerald of Microsoft says, “The issue is a class of bug called a “Token Leak”. It is fixed for many cases (but not all) in Service Pack 4. It’s not possible to fix in all cases because applications can cause this problem.”. As explained above that even if you install SP4, some of the Token Leak problems that are associated with the OS will be removed but as far as the third party applications are concerned you cant do much about it.

References

Acknowledgements

I thank Rainer Gerhards of Adiscon for reviewing this paper. Many thanks to Eric Fitzgerald of Microsoft for providing a great description of the actual cause of the problem associated with Event ID 538. I would also like to thank Gord Taylor for providing his feed back on the paper.

Author’s Address

Wajih-ur-Rehman
wrehman@ro1.adiscon.com

Adiscon GmbH
Mozartstrasse 21
97950 Grossrinderfeld
Germany

Disclaimer

The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the authors be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user’s own risk.

Have your logs consolidated but it’s too complicated to review them or create reports? Take a look at MonitorWare Console!

With MonitorWare Console you can not only review your stored log data. You can automatically create reports for Windows events and PIX firewall logs and let them be sent via e-mail and much more.

Take a Quick Tour to MonitorWare Console to know more about its exciting features or directly download the free and full-featured 30 day trial version.

Would you like to discuss this object? Have a look at our Windows event forum or post a question there!

Analysis, monitoring, near-real-time alerting of the Windows event log can be done with by MonitorWare Agent.

All information in this section is to the best of our knowledge but without warrenty of any kind. This is free information – use it at your sole risk.

Event ID 538 Explained