Tracking Logon and Logoff Activity in Win2K

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.

   Previous  [1]  2  Next