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.