Audit Account Logon Events

Win2K's new category offers valuable information you can't get in NT

In "Tracking Logon and Logoff Activity in Win2K," February 2001, I explained how you can use Windows 2000's Audit logon events audit category to track local logon events on your server or workstation. ("Related Articles in Previous Issues," page 58, lists other articles relating to event-log tracking.) This category captures logon events on the local system on which the logons occur, but tracking a large network's logon activity one system at a time is impractical.

Win2K's new Audit account logon events category captures authentication events in centralized locations: on your domain controllers (DCs—I only wish that Microsoft had given this category a more precise name, such as Audit authentication events). When a user employs a domain account to log on at a workstation, the workstation contacts the DC to verify that the user is authentic and to determine account status and restrictions. When the user then connects to a server over the network, the DC again provides authentication services. To capture these events, open the Microsoft Management Console (MMC) Domain Controller Security Policy snap-in from the DC. This snap-in is a shortcut to the Security Settings portion of the Default Domain Controller Group Policy Object (GPO), which is linked to the Domain Controllers organizational unit (OU) in your Active Directory (AD) domain. In the snap-in's edit window, maneuver to Local Policies, Audit Policy. Right-click Audit account logon events in the right pane, and select Security to open the Security Policy Setting dialog box. To enable the category, select the Success and Failure check boxes and save the settings.

Win2K reports different account logon events depending on which authentication protocol the involved systems use for a given logon request. As I explained in my February 2001 article, Win2K supports both Kerberos and Windows NT LAN Manager (NTLM). When a user logs on interactively at a Win2K Professional workstation or uses a Win2K domain account to connect from a Win2K Pro workstation to a Win2K server, the involved systems use Kerberos and the DC logs Kerberos events. However, when a user logs on interactively at an NT workstation or connects to or from an NT system, the systems use NTLM and the DC logs a different set of events.

Successful Kerberos Events
The Kerberos authentication protocol uses encrypted, time-stamped tickets to control the ability to log on to systems. To give you access to a system—even the workstation in front of you—Win2K first requests a service ticket from the DC. This service ticket contains information that assures your authenticity to the system you're trying to access. However, before the DC will grant you service tickets, you must first authenticate yourself to the DC and thereby acquire a ticket-granting ticket (TGT). The only time the DC actually verifies your password is when you initially log on at your workstation and the workstation requests your TGT. After acquiring your TGT, your workstation includes your TGT with each new service ticket request as you connect to other network services (e.g., file servers, Microsoft SQL Server, Microsoft Exchange Server). Win2K logs different event IDs for successful and failed TGT and service-ticket requests. (For information about Kerberos, see Jan De Clercq, "Kerberos in Win2K," October 1999.)

Each morning when a user sits down at his or her workstation and enters his or her domain username and password, the workstation contacts a local DC and requests a TGT. If the username and password are correct and the user account passes status and restriction checks, the DC grants the TGT and logs event ID 672 (authentication ticket granted), which Figure 1 shows. The User field for this event (and all other events in the Audit account logon event category) doesn't help you determine who the user was; the field always reads SYSTEM. Instead, you need to look at the User Name and Supplied Realm Name fields, which identify the user who logged on and the user account's DNS suffix. (When you create a user account, you can use the domain's entire DNS name or the name of the tree's root domain in NT's domainusername format.) The User ID field provides the same information in NT style (i.e., the NetBIOS domain name followed by a backslash and the username). The Service Name field identifies which service the DC granted the user a ticket to. In the case of an initial workstation logon, the DC grants the user a ticket to the krbtgt (i.e., Kerberos ticket granting) service.

The next field of interest is Client Address, which identifies the IP address of the workstation from which the user logged on. All Kerberos events, including failed logon attempts, include Client Address. This information is extremely valuable. In NT, you can track failed logon attempts for an individual system, but you have no idea where the attempts are coming from. In Win2K, you not only have centralized logon activity records on DCs but also can tell where the logon events originate.

You'll see other instances of event ID 672 when a computer in the domain needs to authenticate to the DC—typically when a workstation boots up or a server restarts. (Before a computer can access Group Policy information or register its DNS name, the machine must authenticate to the DC.) In these instances, you'll find a computer name in the User Name and User ID fields, as Figure 2, page 58, shows. (You can always recognize computer-account names in account logon events by the dollar sign character—$—appended to the name.)

Whereas event ID 672 lets you track initial logons through the granting of TGTs, event ID 673 (service ticket granted) lets you monitor the granting of service tickets. For example, when a user maps a drive to a file server or connects to some other system resource (e.g., the registry, event log, SAM) on a remote system, the resulting service ticket request generates event ID 673 on the DC.

Win2K also logs event ID 673 in several less-relevant situations. First, you'll see many system-to-system occurrences of this event, which you can recognize by looking for events in which the User Name is a computer account. (This situation occurs, for example, when a workstation connects to a DC to read Group Policy information.) You'll also see occasional instances of event ID 673 in which the User Name is a normal user account and the Service ID field is krbtgt.

Be sure you understand event ID 672's relationship to event ID 673. Being granted a TGT (event ID 672) doesn't give a user access to any system; a TGT simply signifies that the user has proved his or her identity to the DC and can now ask the DC to vouch for the user's identity as he or she requests and receives service tickets (event ID 673) to log on to various systems.

After a user's workstation requests a TGT, the workstation immediately requests a service ticket so that the user can use the workstation. For example, the Security log that Figure 3 shows reveals that an event ID 673 immediately followed an event ID 672. If you review the event ID 673, which Figure 4 shows, you can tell from the User Name, Service Name, and Service ID fields that Maggie logged on to a workstation named W2KPRO-LEFT. You know from the User Domain and Service ID fields that both the user and computer are in the MTG.LOCAL domain.

Figure 5 shows the next event ID 673 in the example log. This event shows that Maggie logged on remotely to the TECRA system from the W2KPRO-LEFT workstation. We can tell from the Service Name and Service ID fields that Maggie logged on to TECRA, but how do we know the logon was a remote logon from W2KPRO-LEFT? Notice the Client Address: 10.0.0.81. The first event ID 673 following an event ID 672 always documents the granting of a service ticket to access the workstation on which the user is interactively logged on. Because Maggie initially requested a TGT from 10.0.0.81 and then immediately requested a service ticket to W2KPRO-LEFT, we can conclude that 10.0.0.81 is the IP address for W2KPRO-LEFT. Subsequent event IDs 673, such as the one that Figure 5 shows, reveal Maggie logging on to other systems from the same client address (i.e., 10.0.0.81) as she maps drives or uses other services.

To prevent time-based attacks, Kerberos limits how long a ticket is valid. If a ticket expires when the user is still logged on, Win2K automatically contacts the DC to renew the ticket. When the DC renews the ticket, it also logs event ID 674 (ticket granted renewed).

Failed Kerberos Events
Which events does Win2K log when authentication fails? When a user attempts to log on at a Win2K Pro workstation and uses a valid domain account name but enters a bad password, the DC records event ID 675 (pre-authentication failed) with Failure Code 24, as Figure 6 shows. This event is extremely valuable: By reviewing each of your DC Security logs for this event and failure code, you can track every domain logon attempt that failed as a result of a bad password. In addition to providing the username and domain name, the event provides the IP address of the system from which the logon attempt originated. This provision is a tremendous advance over NT's failed-logon tracking, which only logs the username and domain name. Win2K also logs event ID 675 when a user attempts to use a different username (i.e., a username other than the one he or she used for the current workstation logon) to connect to a server. For example, a user might try to use the Connect using a different user name feature to use someone else's account to map a drive to a server.

Sometimes a logon fails not because of a bad password but because the user mistyped the username or tried to guess someone else's username. If a logon fails because of an invalid username, Win2K logs event ID 676 (authentication ticket request failed) with Failure Code 6. This event is another important logon auditing advance because in NT you can't distinguish logons that failed because of a bad password from logons that failed because of a bad username. Win2K uses event ID 676 with other failure codes to identify several other types of failed-logon situations. Failure Code 12 indicates the logon failed because of time-of-day or workstation restrictions. Failure Code 23 means the user's password had expired. Failure Code 18 signifies that the account was locked out because of failed logons, disabled by the administrator, or expired. Failure Code 37 occurs when a workstation's clock was too far out of synchronization with the DC's clock.

Sometimes an attempt to acquire a service ticket fails even though the DC successfully authenticated the user and granted a TGT. In this case, Win2K logs event ID 677 (service ticket request failed) with a variety of failure codes depending on the situation. When users try to connect from Win2K Pro workstations to NT servers on your network, you'll regularly encounter event ID 677 with Failure Code 7, which Figure 7, page 61, shows. In this example, the user was logged on at a Win2K Pro workstation (i.e., Client Address 10.0.0.81) as Administrator and mapped a drive to an NT Server system (i.e., Kramer) in a Win2K domain (i.e., MTG.LOCAL). The workstation first asked the DC to grant a Kerberos service ticket, but that request failed because the NT server doesn't support Kerberos. Thus, the DC logged event ID 677 with Failure Code 7. This type of error is transparent to the user because the workstation immediately falls back to using NTLM.

NTLM Events
When the DC uses NTLM to successfully authenticate a user, the DC logs event ID 680 (account used for logon), which Figure 8, page 61, shows. This event, which is similar to Kerberos's event ID 673, not only specifies which user account logged on but also identifies the client system from which the user initiated the logon. This additional detail is similar to event ID 673's Client Address field, but because NTLM can be carried over TCP/IP, NetBEUI, or IPX, Win2K logs the system's name instead of its IP address.

If an NTLM authentication request fails for any reason, the DC logs event ID 681, which Figure 9 shows. The event description's error code provides the reason for the failure. Table 1 lists the event's error codes and their meanings.

A Better View
Win2K's new Audit account logon events category is exciting because it gives a much more centralized view of logon activity. You can distinguish between logons that failed because of bad usernames as opposed to bad passwords. You can track failed logons back to the offending workstation. However, don't stop reviewing your server Security logs for the Audit logon events category—attackers might try to enter a system by using a local SAM account, such as the built-in Administrator account, and DCs won't log attacks that use local accounts. Audit logon events and Audit account logon events combine to give you in-depth tracking of logons at workstations, servers, and DCs. In the next article in this series, I'll look at how other audit categories have changed in Win2K.