Tracking Logon and Logoff Activity in Win2K

What's new and what's not in the Security log

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," page 84.) I received many requests to write a similar series about the Windows 2000 Security log. Although Win2K 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.

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 Win2K's Event Viewer, which Figure 1, page 84, 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 Win2K MMC snap-ins, see Kathy Ivens, Getting Started with Windows 2000, "The Mighty Win2K Microsoft Management Console, Part 1," September 2000.)

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 Win2K, Group Policy centrally controls event-log settings—as it does most areas of Win2K. 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 Win2K Group Policy and GPOs, see "Controlling Group Policy, Part 1," November 2000, and "Controlling Group Policy, Part 2," Winter 2000.)

Activating Audit Policy
You won't see Security-log events until you activate the system's audit policy, which Group Policy also controls in Win2K. 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 Win2K applies Group Policy, Win2K 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 Win2K applies all relevant GPOs. Win2K 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).

Successful Logons
Win2K 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, page 86, shows, describes a successful logon. However, whereas NT used event ID 528 for every type of logon, Win2K 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, Win2K logs the new event ID 540, which Figure 5, page 86, 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.)

Win2K 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 Win2K 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-Win2K 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 Win2K used when the user connected to the system. When a user connects to a Win2K system from over the network, Win2K 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.

Win2K prefers to use the stronger Internet-standard Kerberos but can do so only between two Win2K 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-Win2K Massachusetts Institute of Technology (MIT) Kerberos 5.0 systems can also use Kerberos with Win2K systems. In all other cases (e.g., when either computer is a Win2K system that doesn't belong to a domain, when either computer is an NT system), Win2K 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 Win2K. 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 Win2K uses Kerberos.)

To link a successful logon event (i.e., event ID 528 or event ID 540) to its corresponding logoff event (Win2K 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. Win2K suffers from the same strange bug that NT suffers from: The OS occasionally neglects to log event ID 538. (So far, in Win2K, 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 Win2K haven't changed much from NT. When a user attempts to log on with an invalid username or password, Win2K 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, Win2K 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, Win2K 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 Win2K 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 Win2K's new Audit account logon events audit category. I'll delve into that category in the next installment of this series.