Audit Account Logon Events

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 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 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).