Tracking Logon and Logoff Activity in Windows 2000

Article
12/09/2009

By Randy Franklin Smith

My series about the Windows NT Security log generated more feedback than any other articles I've written. (For a list of the articles in that series, see "Related Articles in Previous Issues,") I received many requests to write a similar series about the Windows 2000 Security log. Although Windows 2000 retains most of NT's audit-policy and Security-log functionality, the new OS introduces several changes and many new capabilities, including some exciting developments in one of the Security log's most important areas: tracking logon and logoff activity.

Related Articles in Previous Issues

Articles in the NT Security Log Series

This article presents information about the Windows 2000 Security log. You can find similar information about the Windows NT Security log in Randy Franklin Smith's previous series. For your convenience, we list those articles below. You can obtain these articles from Windows 2000 Magazine's Web site at https://www.windows2000mag.com.

"Archiving and Analyzing the NT Security Log," August 2000, InstantDoc ID 9043

"Protecting the NT Security Log," July 2000, InstantDoc ID 8785

"Monitoring Privileges and Administrators in the NT Security Log," June 2000, InstantDoc ID 8696

"Interpreting the NT Security Log," April 2000, InstantDoc ID 8288

"Introducing the NT Security Log," March 2000, InstantDoc ID 8056

Accessing the Security Log

To access the Security log and determine a system's current log settings, use Event Viewer: Click Start, Programs, Administrative Tools, Event Viewer. The interface has changed a little from the NT interface because Windows 2000's Event Viewer, which Figure 1 shows, is a Microsoft Management Console (MMC) snap-in. Therefore, you can create custom consoles—for example, you can add a copy of the Event Viewer snap-in for each system you need to monitor. (For information about customizing Windows 2000 MMC snap-ins, see Kathy Ivens, Getting Started with Windows 2000, " The Mighty Windows 2000 Microsoft Management Console, Part 1," September 2000.)

Figure 1: Accessing the Security log

To filter, save, sort, or clear a system's Security log, open the Event Viewer snap-in, right-click the desired log, and choose an action from the context menu. You can configure an event log's maximum size and retention settings through the log's Properties dialog box, but I recommend against configuring your event logs this way if your system is a member of an Active Directory (AD) domain. Instead, use domain- or organizational unit- (OU-) level Group Policy Objects (GPOs) in the MMC Active Directory Users and Computers snap-in.

In Windows 2000, Group Policy centrally controls event-log settings—as it does most areas of Windows 2000. This arrangement fixes NT's inconvenient requirement to configure each system separately. To help you centralize settings configuration, Group Policy offers a variety of options, including GPOs that link to OUs. Using Group Policy, you can configure multiple systems simultaneously with the same event-log settings. For example, to configure all the systems in your domain to have a maximum Security-log size of 1024KB, open the Active Directory Users and Computers snap-in, open your domain's Properties dialog box, and go to the Group Policy tab. Select the Default Domain Policy GPO, and click Edit. In the resulting window's left pane, go to Computer Configuration, Windows Settings, Security Settings, Event Log, Settings for Event Log, as you can see in Figure 2. Right click Maximum security log size, select Security, define a log size of 1024KB, and then click OK. (For more information about Windows 2000 Group Policy and GPOs, see " Controlling Group Policy, Part 1," November 2000, and " Controlling Group Policy, Part 2," Winter 2000.)

Figure 2: Using Group Policy to configure Security-log settings

Activating Audit Policy

You won't see Security-log events until you activate the system's audit policy, which Group Policy also controls in Windows 2000. To specify a standard audit policy for every system in your domain, you can again edit the Default Domain Policy GPO. Open the edit window for the Default Domain Policy GPO, but this time maneuver to Computer Configuration, Windows Settings, Security Settings, Local Policies, Audit Policy. Right-click an audit category and select Security, then define the policy setting to audit for the success or failure of that category's event.

When Windows 2000 applies Group Policy, Windows 2000 creates a composite of all the GPOs that link to a computer's site, domain, and OUs. When you use the Active Directory Users and Computers snap-in to browse GPOs, you can easily miss settings. To accurately determine a system's current audit policy, open the MMC Local Security Policy snap-in and go to Security Settings, Local Policies, Audit Policy, which Figure 3 shows. This snap-in's Local Setting column shows you the system's local GPO settings, which are the least influential GPOs. More important, the Effective Setting column shows you the system's current settings after Windows 2000 applies all relevant GPOs. Windows 2000 includes three new categories: Audit logon events, Audit account logon events, and Audit directory service access. (For information about these new categories, see the sidebar "New Audit Categories.") You can use the Audit logon events category to track local logon events in the same way you use NT's Logon and Logoff category; the other new categories apply to domain controllers (DCs).

Figure 3: Determining a system's current audit policy

New Audit Categories

When you view a system's audit policy through the Microsoft Management Console (MMC) Local Security Policy snap-in, you might notice two new audit categories that apply to domain controllers (DCs): Audit directory service access and Audit account logon events. The Audit directory service access category lets you track changes to Active Directory (AD) objects (e.g., users) down to the property level. For example, you can use this category to distinguish password resets from phone-number changes.

The Audit account logon events category name is confusingly similar to the Audit logon events category name. Window 2000's Audit logon events is the same as Windows NT's familiar Logon and Logoff audit category. The problem with Audit logon events and Logon and Logoff is that Windows 2000 and NT record these events on the system on which the logon occurs. When a user logs on interactively at a workstation, Windows 2000 and NT record the logon event in the local workstation's Security log—if you've turned on audit policy at the workstation. When a user connects to a server over the network (e.g., by using a drive mapping), Windows 2000 and NT record the network logon on the server's Security log. As a result, logon and logoff activity events are scattered across every system in your network. Microsoft heard our complaints and added the Audit account logon events category, which tracks user authentication at centralized points: the DCs in your domain.

Successful Logons

Windows 2000 uses the Audit logon events category when a user logs on interactively (i.e., at the local keyboard and screen) or remotely (i.e., from over the network). The Logon Type field in the event's description contains a number that specifies the logon's nature: interactive (2), network (3), batch (4), service (5), unlocked workstation (7), network logon using a cleartext password (8), or impersonated logons (9).

As in NT, event ID 528, which Figure 4 shows, describes a successful logon. However, whereas NT used event ID 528 for every type of logon, Windows 2000 uses a different event ID for network logons. When you map a drive to a server, connect to the server's registry, or otherwise perform a network logon, Windows 2000 logs the new event ID 540, which Figure 5 shows. This new event is useful because it lets you separate network logons from other logon types. (I'd like Microsoft to create a separate event for the other important logon type: interactive logons.)

Windows 2000 logs a lot of irrelevant event ID 540 occurrences. To distinguish these events from relevant events, look at the event's User Name field, which will be either a normal user account, SYSTEM, or a computer name ending with the dollar sign ($) character. A normal user account notifies you that a user logged on to the system from over the network; you want to pay attention to these events. You can ignore events in which the User Name is SYSTEM, which indicates that one system service was connecting to another service on the same system. You can also discount events in which the User Name is a computer followed by the $ character, which means that the system services on a remote system are connected to the system services on this system. (For example, when a Windows 2000 Professional workstation starts up, it connects to the DC for AD information and other domain services. To access these domain services, the workstation must first authenticate itself to the DC.)

The Domain field in event ID 528 and event ID 540 identifies the domain on which the user's account resides. This field uses the pre-Windows 2000 NetBIOS domain name rather than the DNS version of the domain name. If a user uses a local account in a system's local SAM to log on to that system, the event's Domain field will reflect the computer's NetBIOS name. You won't often see local user account logons in a domain environment; however, attackers like to target local SAM accounts—especially the Administrator account—so keep an eye out for event ID 528 or event ID 540 occurrences in which the Domain field matches the Computer field.

Event ID 540's Logon Process and Authentication Package fields let you determine which authentication protocol Windows 2000 used when the user connected to the system. When a user connects to a Windows 2000 system from over the network, Windows 2000 negotiates the use of one of two possible authentication protocols: NT LAN Manager—NTLM—or Kerberos. Identifying systems that aren't using Kerberos is important: Those systems are more vulnerable to attack because NTLM is weaker than Kerberos.

Windows 2000 prefers to use the stronger Internet-standard Kerberos but can do so only between two Windows 2000 systems that trust each other (e.g., systems in the same forest, systems in domains connected by explicitly defined one-way trusts). If set up correctly, non-Windows 2000 Massachusetts Institute of Technology (MIT) Kerberos 5.0 systems can also use Kerberos with Windows 2000 systems. In all other cases (e.g., when either computer is a Windows 2000 system that doesn't belong to a domain, when either computer is an NT system), Windows 2000 falls back to the older and weaker NTLM protocol, which attackers can sniff and crack with relative ease. (Although you can upgrade your systems to NTLMv2 to provide some protection against malicious activity, you'll have those risky NTLM packets on your network until you migrate all your systems to Windows 2000. To learn more about NTLMv2, see " Inside SP4 NTLMv2 Security Enhancements," September 1999.)

When you've upgraded all the client computers that will connect to a given server, check the server's Security log for event ID 540 in which the Authentication Package field is NTLM instead of Kerberos. If you find some NTLM logons, you can look at the event's Workstation Name field to determine the client computer's NetBIOS name. (This field is blank when Windows 2000 uses Kerberos.)

To link a successful logon event (i.e., event ID 528 or event ID 540) to its corresponding logoff event (Windows 2000 records successful logoffs with event ID 538, just as NT does), use the Logon ID number that appears in both events. For example, suppose you see a logon event for Administrator at 1:27 p.m., and you want to know when Administrator logged off. Note the Logon ID in event ID 528 (e.g., 0x0, 0xEC87 in Figure 4), then right-click the Security log in Event Viewer and click View/Find to search the event log for that number. I have a bit of bad news, though. Windows 2000 suffers from the same strange bug that NT suffers from: The OS occasionally neglects to log event ID 538. (So far, in Windows 2000, I've noticed this problem only for interactive logons.) In other words, you might see an event ID 528 that doesn't have a corresponding event ID 538.

Failed Logons

The events for failed logons in Windows 2000 haven't changed much from NT. When a user attempts to log on with an invalid username or password, Windows 2000 records event ID 529. When a user has a disabled account or is locked out, the system logs event ID 531 and event ID 539, respectively. When a user tries to log on outside the times or days permitted for that user account, Windows 2000 logs event ID 530. When an account has reached its account expiration date or when a user's password has expired, the system logs event ID 532 or event ID 535, respectively. When you limit a user to logging on at specific workstations and the user tries to violate this restriction, Windows 2000 records event ID 533.

You can also use rights to restrict users to certain types of logons for specific systems. If a user doesn't have rights to access a computer from the network and the user tries to map a drive to that system or view that system's registry, the system logs event ID 534. This event also occurs when a user tries to log on at the console and doesn't have the right to log on locally. If a service that attempts to start using an account that doesn't have the Logon as a service right, it triggers event ID 534. Processes that try to log on as a batch job using an account that doesn't have the Logon as a batch job right also trigger event ID 534. If a logon fails for some other reason, you'll see event ID 537 with the following Logon Failure explanation: An unexpected error occurred during logon. All these failed logon events also provide Logon Type information, which lets you distinguish failed logons at the local console from someone trying to connect from over the network.

Stay Tuned ...

The Audit logon events category can provide plenty of useful information. However, remember that Windows 2000 records all the events in this category in the local system's log. Thus, you must view logon and logoff activity and track suspicious failed logons one workstation and server at a time—an impractical practice on a large network. Thankfully, we can turn to Windows 2000's new Audit account logon events audit category. I'll delve into that category in the next installment of this series.

About the Author

Randy Franklin Smith is a contributing editor for Windows 2000 Magazine and president of Monterey Technology Group. He writes the biweekly Windows 2000 Security column for the Windows NT Security Channel on the Windows 2000 Magazine Network. You can reach him at rsmith@montereytechgroup.com.

The above article is courtesy of Windows 2000 Magazine. Click here to subscribe to Windows 2000 Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

Click to order