Audit Account Logon Events

By Randy Franklin Smith

This article is from the March 2001 issue of Windows 2000 Magazine.

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

In " Tracking Logon and Logoff Activity in Windows 2000," 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," 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.

Windows 2000'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.

Windows 2000 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, Windows 2000 supports both Kerberos and Windows NT LAN Manager (NTLM). When a user logs on interactively at a Windows 2000 Professional workstation or uses a Windows 2000 domain account to connect from a Windows 2000 Pro workstation to a Windows 2000 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.

On This Page

Successful Kerberos Events
Failed Kerberos Events
NTLM Events
A Better View

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—Windows 2000 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). Windows 2000 logs different event IDs for successful and failed TGT and service-ticket requests. (For information about Kerberos, see Jan De Clercq, " Kerberos in Windows 2000," 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 domain\username 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 Windows 2000, 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, 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.

Windows 2000 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.

Figure 3: Tracking the order of events

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, Windows 2000 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 Windows 2000 log when authentication fails? When a user attempts to log on at a Windows 2000 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. Windows 2000 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, Windows 2000 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. Windows 2000 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, Windows 2000 logs event ID 677 (service ticket request failed) with a variety of failure codes depending on the situation. When users try to connect from Windows 2000 Pro workstations to NT servers on your network, you'll regularly encounter event ID 677 with Failure Code 7, which Figure 7 shows. In this example, the user was logged on at a Windows 2000 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 Windows 2000 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 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, Windows 2000 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.

Table 1 Error Codes for Event ID 681

A Better View

Windows 2000'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 Windows 2000.

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 IT 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