Chapter 4
Account Logon Events

Account Logon events provide a way to track all the account authentication that is handled by the local computer. If the local computer is a DC, you will see events that are logged for the domain accounts that the DC authenticates. If the computer is a member server, you will see only events that are logged for authentication of local accounts on that server.

The Audit account logon events policy category comprises four subcategories shown below. We recommend that you enable the Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, and Other Account Logon Events subcategories. You will not typically see the four event IDs in the Other Account Logon Events subcategory in AD environments.

Subcategories	Comment
Credential Validation	NTLM Authentication; produces events on both DCs and member servers
Kerberos Authentication Service	Kerberos Ticket Granting Tickets (TGT); produces events only on DCs
Kerberos Service Ticket Operations	Kerberos Service Tickets (computers and services accessed); produces events only on DCs
Other Account Logon Events	Dumping ground for four other authentication events, none of which have been observed during our testing

When you enable these policies on a DC, all domain account authentication that occurs on that DC will be logged. When you analyze the combined Account Logon events of all your DCs, you will have a complete picture of the logon activity of all domain accounts in the domain, regardless of whether the logon attempts were initiated from computers of the local or trusted domain or from unknown computers outside your AD forest and external trusted domains.

Windows DCs support both NTLM and Kerberos authentication protocols.

NTLM vs. Kerberos

When a DC needs to find out whether a domain account is authentic, the computer first tries to contact the DC via Kerberos. (If the system doesn’t receive a reply, it falls back to using NTLM. The DCs log different event IDs for Kerberos and for NTLM authentication activity, so you can easily distinguish between them.) In an AD forest comprising computers that are all running Windows 2000 and later, all authentications between workstations and servers should be made via Kerberos. Any NTLM authentication events that you see on your DCs can have only a few explanations:

• Windows will fall back to using NTLM if routers block Kerberos traffic (UDP port 88) or if the system doesn’t receive a reply when trying to contact the DC via Kerberos.
• You might see NTLM events on your DCs if the domain trusts another domain outside the forest (as defined in Active Directory Domains and Trusts). Kerberos doesn’t work for most external trust relationships. (Note that realm trusts between a Windows domain and a non-Windows Kerberos realm use Kerberos, as do transitive, two-way cross-forest trusts between two Windows domains.)
• NTLM events on a DC’s Security log can indicate rogue computers. Contrary to popular belief, Windows does not prevent a user at a stand-alone computer (i.e., a Windows computer that belongs to no domain) or a computer in an untrusted domain from using a domain account to connect to a server in your domain. To prove this, just use the Net use command to map a drive to a computer in an untrusting domain. The following sample command connects me to a file server called NYC-FS-1 in the NYC domain, using the domain Administrator account and a password of #dk32HE4:
  net use \\nyc-fs-1.nyc.acme.local\c$ #dk32HE4 /user:nyc\administrator
• You might see NTLM events as a result of users logging on to an application that uses Microsoft Internet Information Services (IIS) authentication (e.g., an IIS Web application).
• Linux, UNIX, and Mac computers generate NTLM events.
• Pre-Windows 2000 computers in the local domain or in the overall forest can log NTLM events on your DC Security logs.

Why does it matter whether your systems use NTLM or Kerberos? For one thing, Kerberos provides mutual authentication between client and server, whereas NTLM authenticates client-to-server only. For another thing, NTLM is less secure than Kerberos. Although intruders can capture packets from either protocol and can attempt to crack the data back to the password, NTLM is easier to crack than Kerberos. More important, if an outsider (i.e., someone who is not a member of your organization) attacks accounts in your domain, you will most likely see those attacks as NTLM authentication events because the outsider’s computer isn’t a member of your domain or a trusted domain.

How NTLM Works

NTLM is a challenge/response protocol shown in the diagram below. When a user attempts to log on to a workstation, the computer contacts the DC to request authentication of the user. The DC generates a random string of bytes, known as the challenge, and sends it to the workstation. The workstation hashes the password that the user entered, then encrypts the challenge, using the password as the key. The workstation then sends the encrypted challenge, called the response, back to the DC. The DC encrypts its copy of the original challenge and compares it to the response from the workstation. If the challenge and response match, then the encryption keys are the same, and the DC infers that the user correctly entered the password.

As you can see, NTLM never sends the password or the hash across the network. However, attackers who can capture the challenge/response packets might be able to crack the information back to the original password because of weaknesses associated with NTLM’s backward-compatibility support with ancient LanManager technology. An attacker might use this backward-compatibility to crack passwords even when NTLM is used.

NTLM Events

Windows logs event ID 4776 (see example below) for NTLM authentication activity (both Success and Failure). Earlier versions of Windows Server log different event IDs. Windows 2000 logs two event IDs—680 and 681—for all types of NTLM authentication activity. A successful NTLM authentication yields event ID 680; a failure produces event ID 681. (Windows 2003 merges these two events into event ID 680.)

The domain controller attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: Administrator Source Workstation: WIN-R9H529RIO4Y Error Code: 0x0

An NTLM event description's Logon Account field lists the name of the user account that attempted the authentication. The Source Workstation field provides the name reported by the computer on which the user is present. In the case of non-Windows systems (e.g., Apple computers), the Source Workstation field might contain a domain name instead of workstation name.

To determine why an authentication attempt failed, look at the description's Error Code field. NTLM provides very specific error codes listed in the chart below. You might be surprised when you compare these codes to Kerberos failures, which are far less specific because of the Request for Comments (RFC) 1510 Kerberos standard.

NTLM Error Code		Error Description	Comments
Decimal	Hexadecimal
3221225572	C0000064	user name does not exist
3221225578	C000006A	user name is correct but the password is wrong
3221226036	C0000234	user is currently locked out
3221225586	C0000072	account is currently disabled
3221225583	C000006F	user tried to logon outside his day of week or time of day restrictions	Logged only for domain accounts that are configured with logon-hour restrictions
3221225584	C0000070	workstation restriction	Logged only for domain accounts that are configured with workstation restrictions
3221225875	C0000193	account expiration	Logged only for domain accounts that are configured with an account expiration
3221225585	C0000071	expired password
3221226020	C0000224	user is required to change password at next logon	Usually logged the first time a user logs on after the account is created or after the password is reset
3221226021	C0000225		Evidently a bug in Windows and not a risk
0	0x0		A successful authentication rather than an error

NTLM yields an Account Logon event whenever a user logs on to a computer, either interactively or over the network as you can see in the diagram below.

For instance, imagine that Bob uses a domain account to log on to his Windows NT workstation, then uses a shared folder on Server A and one on Server B. On whichever DC handles those authentication requests, you’ll see a total of three event ID 4776 instances: one for the interactive workstation logon and two for the network logons to Server A and Server. However, you won’t be able to discern that Bob accessed three systems; the events will be identical except for the date and time stamp.

On DCs, NTLM authentication events give you a record of all logon attempts that used domain accounts and that were serviced by the NTLM authentication protocol. You will also see NTLM events on member servers and workstations.

When someone attempts to use a local SAM account to log on to a Windows computer, NTLM always handles the authentication. Therefore, successful event ID 4776 instances on a workstation or member server are a clear indicator that some user, service, or scheduled task successfully logged on by using a local account. Failed event ID 4776 instances on a workstation or member server indicate that some user, service, or scheduled task attempted but failed to log on by using a local account. (You can determine the logon type from the related Logon/Logoff event, which we’ll consider in the next chapter.) If your environment encourages the use of domain accounts and avoids the use of local accounts, then enabling the Audit account logon events policy on workstations and member servers is an easy way to identify the improper use of local accounts.

Kerberos Basics

Although tracking NTLM authentication is important, don’t forget about Kerberos authentication, which will likely represent the bulk of authentication activity in your DC Security logs. Kerberos is the default authentication protocol for Windows 2000 and later computers in an AD domain. To understand Kerberos events, you'll benefit from understanding the basic functioning of the Kerberos protocol.

Kerberos uses the concept of tickets. A ticket is a small amount of encrypted, session-specific data that is issued by the DC. When a client needs to access a server on the network, the client first obtains a ticket from the server's DC. The ticket and other data supplied by the client vouch for the client’s identity and provide a way for the client to authenticate the server. In this way, Kerberos provides mutual authentication of both client and server. Using timestamps and other techniques, Kerberos protects tickets from cracking or replay attacks by eavesdroppers on the network.

The two kinds of tickets are authentication tickets (aka ticket-granting tickets) and service tickets. Kerberos issues an authentication ticket when a client first authenticates itself to the DC. The DC sends back the authentication ticket and a session key that’s been encrypted with the client’s personal key (in this case, the user’s password). The client uses its personal key to decrypt the session key. Then the client uses its authentication ticket and session key to obtain a service ticket for each server that it needs to access.

In UNIX-based Kerberos implementations, Kerberos simply issues an authentication ticket, without checking the user’s credentials. If the user’s computer can successfully decrypt the session key that comes with the authentication ticket, then the user is authentic. If the client is an impostor, it won’t be able to obtain the session key. Therefore, UNIX Kerberos implementations don’t immediately detect failed logons that happen because of a bad password. However, Windows takes advantage of an optional Kerberos feature called pre-authentication. Using pre-authentication, the DC checks the user’s credentials before issuing the authentication ticket.

Kerberos and the Windows Security Log

Windows generates Security log events at each step of the Kerberos authentication process, so by knowing how to relate general Kerberos events to user activity in the real world, you can closely monitor domain logon activity and pinpoint suspicious events. Let’s look at how a user’s actions relate to Kerberos events.

Imagine that Fred walks into his office one morning, turns on his Windows XP computer, and enters his domain username and password. Fred’s workstation sends an authentication request, via Kerberos, to the DC.

When Fred enters a correct username and password, the DC logs a successful event ID 4768 as you can see below. (A Kerberos authentication ticket (TGT) was requested. When you see an event ID 4768 instance that lists Fred as the account name in the event’s description, you can interpret the event as Fred’s initial logon at his workstation. You can even identify his workstation by using the Client Address field. All Kerberos events include this field, which identifies the client computer's IP address. The Supplied Realm Name field, which identifies the user account's domain (e.g., ACME), is also useful. (Other Kerberos events identity the domain as User Domain or prefix the username with the domain–e.g., ACME\Fred.)

Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 10/28/2008 6:17:28 PM Event ID: 4768 Task Category: Kerberos Authentication Service Level: Information Keywords: Audit Success User: N/A Computer: Lab2008.acme.ru Description: A Kerberos authentication ticket (TGT) was requested. Account Information:                 Account Name:                 Fred                 Supplied Realm Name:      ACME                 User ID:                          ACME\Fred Service Information:                 Service Name:                  krbtgt                 Service ID:                      ACME\krbtgt   Network Information:                 Client Address:                 ::1                 Client Port:                      0   Additional Information:                 Ticket Options:                 0x40810010                 Result Code:                    0x0                 Ticket Encryption Type:     0x17                 Pre-Authentication Type:    2   Certificate Information:                 Certificate Issuer Name:                                     Certificate Serial Number:                 Certificate Thumbprint:                         Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120.

But what if Fred enters a bad password? In this case, Kerberos pre-authentication catches the problem at the DC, and Windows logs event ID 4771 (Kerberos pre-authentication failed), with Failure Code 0x18 in the Failure Code field as you can see in the example below.

Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 10/27/2008 5:47:55 PM Event ID: 4771 Task Category: Kerberos Authentication Service Level: Information Keywords: Audit Failure User: N/A Computer: Lab2008.acme.ru Description: Kerberos pre-authentication failed. Account Information:                 Security ID:                     S-1-5-21-3574173841-1192904138-508017755-1000br />                 Account Name:                Fred Service Information:                 Service Name:                  krbtgt/ACME Network Information:                 Client Address:                 ::1                 Client Port:                      0   Additional Information:                 Ticket Options:                 0x40810010                 Failure Code:                    0x18                 Ticket Encryption Type:     0x17                 Pre-Authentication Type:    2   Certificate Information:                 Certificate Issuer Name:                                     Certificate Serial Number:                 Certificate Thumbprint:                         Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options, encryption types and result codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.

After obtaining a TGT, the workstation attempts to obtain a service ticket from the DC. Windows reports a successful attempt as event ID 4769 (A Kerberos service ticket was requested) with a Service Name of “krbtgt". You’ll always see this instance of event ID 4769, which you can ignore, after an instance of event ID 4768.

The workstation next must obtain a service ticket for itself (i.e., a service ticket that authenticates Fred to his workstation and allows him to log on). This event shows up as another instance of event ID 4769. The Service Name field in event ID 4769 identifies the service for which the ticket was granted—in this case, the workstation’s name. This instance of event ID 4769 is useful because it identifies the workstation by name; the earlier instance of event ID 4768 provided only the workstation's IP address.

That isn’t the end of event ID 4769. You’ll see additional instances for each server that Fred accesses after logging on to his workstation. Imagine that Fred’s logon script or persistent drive mappings initiate connections to a MktgFiles shared folder on a Lab2008 server. The DC will log event ID 4769 when Fred’s workstation obtains a service ticket to Lab2008 as shown below.

Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 10/28/2008 6:17:21 PM Event ID: 4769 Task Category: Kerberos Service Ticket Operations Level: Information Keywords: Audit Success User: N/A Computer: Lab2008.acme.ru Description: A Kerberos service ticket was requested. Account Information:                 Account Name:                 LAB2008$@ACME.RU                 Account Domain:              ACME                 Logon GUID:                    {0530ceb1-de6d-35ca-57b5-17c2e85b3439} Service Information:                 Service Name:                  LAB2008$                 Service ID:                      ACME\LAB2008$   Network Information:                 Client Address:                 ::1                 Client Port:                      0   Additional Information:                 Ticket Options:                 0x40810010                 Ticket Encryption Type:     0x12                 Failure Code:                    0x0                 Transited Services:    -   This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested. This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. Ticket options, encryption types, and failure codes are defined in RFC 4120.

To recap, when Fred logs on at his workstation for the first time that day, the DC that handles the logon will log event ID 4768, closely followed by three instances of event ID 4769 like the diagram shows below. One instance lists “krbtgt” as the service and can be ignored. The second instance lists the DC as the service, and the third instance identifies Fred’s workstation’s name.

Additional event ID 4769 instances are logged as Fred accesses other servers.

Now you know which event that Windows logs when a user enters a bad password (event ID 4768 with failure code 0x18), but what about all the other reasons for which a logon can fail, such as an expired password or disabled account? Windows Server catches all of these other logon failures after pre-authentication and logs event ID 4769 (A Kerberos service ticket was requested. (failure)). Again, you need to look at the failure code to determine the problem. The list of various failure codes are in the chart below. (Because the Kerberos protocol was developed apart from a specific operating system, its failure codes do not always directly map to Windows authentication failure descriptions. Kerberos reports the same code for failures that occur because an account is disabled, expired, or locked out.)

Failure code		Kerberos RFC description	Notes on common failure codes
Decimal	Hexadecimal
1	0x1	Client's entry in database has expired
2	0x2	Server's entry in database has expired
3	0x3	Requested protocol version # not supported
4	0x4	Client's key encrypted in old master key
5	0x5	Server's key encrypted in old master key
6	0x6	Client not found in Kerberos database	Bad username, or new computer/user account that has not replicated to DC yet
7	0x7	Server not found in Kerberos database	New computer account that has not replicated yet or computer is pre-Windows 2000
8	0x8	Multiple principal entries in database
9	0x9	The client or server has a null key	Administrator should reset the password on the account
10	0xA	Ticket not eligible for postdating
11	0xB	Requested start time is later than end time
12	0xC	KDC policy rejects request	Workstation/logon time restriction
13	0xD	KDC cannot accommodate requested option
14	0xE	KDC has no support for encryption type
15	0xF	KDC has no support for checksum type
16	0x10	KDC has no support for padata type
17	0x11	KDC has no support for transited type
18	0x12	Clients credentials have been revoked	Account disabled, expired, or locked out
19	0x13	Credentials for server have been revoked
20	0x14	TGT has been revoked
21	0x15	Client not yet valid - try again later
22	0x16	Server not yet valid - try again later
23	0x17	Password has expired	The user’s password has expired
24	0x18	Pre-authentication information was invalid	Usually means bad password
25	0x19	Additional pre-authentication required*
31	0x1F	Integrity check on decrypted field failed
32	0x20	Ticket expired	Frequently logged by computer accounts
33	0x21	Ticket not yet valid
33	0x21	Ticket not yet valid
34	0x22	Request is a replay
35	0x23	The ticket isn't for us
36	0x24	Ticket and authenticator don't match
37	0x25	Clock skew too great	Workstation’s clock too far out of sync with the DC’s
38	0x26	Incorrect net address	IP address change
39	0x27	Protocol version mismatch
40	0x28	Invalid msg type
41	0x29	Message stream modified
42	0x2A	Message out of order
44	0x2C	Specified version of key is not available
45	0x2D	Service key not available
46	0x2E	Mutual authentication failed	May be a memory allocation failure
47	0x2F	Incorrect message direction
48	0x30	Alternative authentication method required*
49	0x31	Incorrect sequence number in message
50	0x32	Inappropriate type of checksum in message
60	0x3C	Generic error (description in e-text)
61	0x3D	Field is too long for this implementation

Windows doesn’t log event ID 4772, even though it is defined. (It seems that many of the Windows events were defined before the operating system development was finished and are simply not used.) Instead, Windows reuses event ID 4769, changing the type to Failure Audit instead of Success Audit.

Computer Account–Related Kerberos Events

To support Windows infrastructure features such as AD, Group Policy, and Dynamic DNS updates, workstations and servers must communicate frequently with the DC. This communication begins when a computer boots up. Each system that boots up obtains a TGT from the DC, followed by service tickets to krbtgt and the DC. These communications result in a 4768, 4769, 4769 event ID pattern.

Windows logs many Kerberos events that most people consider extraneous and that you can simply ignore. The events are a result of computers authenticating to the DC. You can identify such computer-to-computer authentication events because the listed username will be a computer instead of a user. Computer account names are easily recognizable because they have a $ appended to the name (e.g., FS2$).

You will also see plenty of occurrences of event ID 4769, resulting from ticket expirations. When a computer remains up for an extended period of time, its service ticket reaches the lifetime limit imposed by the domain's Kerberos policy. When that happens, the computer attempts to renew the ticket. When the renewal succeeds, the DC logs event ID 4770. When the ticket has reached its maximum renewal lifetime, the renewal fails and the DC logs event ID 4769. This forces the computer to re-authenticate to the DC and obtain a TGT all over again, thus causing a repeat of the event sequence that is logged when a computer first starts. Ticket expiration is a natural part of Kerberos activity and can be ignored.

Description Fields

Windows is not always consistent with the description fields you find in Kerberos events. Kerberos events always identify the name and domain attempting authentication, but the information can be formatted several different ways, depending on the event and the way it is viewed. For example, the same event lists “TargetUserName” in the Details tab and “Account Name” on the General tab. This is the same piece of information. The Client Address field is valuable because you can use it to determine the source IP address for authentication requests. I’ve used this field for a variety of purposes, including tracing logon attacks back to their source on the Internet. Some fields that don’t appear to have much (if any) value are Ticket Options, Ticket Encryption Type, and Pre-Authentication Type. These fields always seem to list the same undocumented values.

Final Thoughts on Kerberos

You can use Windows Kerberos events, as tracked in event ID 4668 and event ID 4669, to identify a user’s initial logon at the workstation and to then track each server that the user subsequently accesses. See the above chart for a complete listing of Windows Kerberos events. You can use event ID 4671 and failed event ID 4668 to track failed authentication events. Keep in mind that authentication events that are logged on DCs (whether Kerberos or NTLM) don’t include logoff events. DCs perform authentication services but do not record Logon/Logoff activity for the workstations and servers. Each workstation and server keeps track of who remains logged on. To track logoff events, you must analyze the local Security log of the desired workstation or server, looking for Logon/Logoff events like the ones listed below.

Event ID	Task Category	Title	Comment
4768	Kerberos Authentication Service	A Kerberos authentication ticket (TGT) was requested	Success or failure
4769	Kerberos Service Ticket Operations	A Kerberos service ticket was requested	Success or failure
4770	Kerberos Service Ticket Operations	A Kerberos service ticket was renewed
4771	Kerberos Authentication Service	Kerberos pre-authentication failed.
4772	Kerberos Authentication Service	A Kerberos authentication ticket request failed	We have not seen this event.
4773	Kerberos Service Ticket Operations	A Kerberos service ticket request failed.	Not used; event 4769 failure used instead
4774	Other Account Logon Events	An account was mapped for logon.	We have not seen this event
4775	Other Account Logon Events	An account could not be mapped for logon.	We have not seen this event
4776	Credential Validation	The domain controller attempted to validate the credentials for an account.	NTLM authentication. Not necessarily a DC. May be any Windows server.
4777	Other Account Logon Events	The domain controller failed to validate the credentials for an account	We have not seen this event
4782	Other Account Logon Events	The password hash an account was accessed	We have not seen this event

Bottom Line

To sum things up, let’s look at each authentication—in other words, each Account Logon—event that is documented in the Windows manifest. You will notice that a number of the events are apparently not logged. We suspect that during development, Microsoft dropped plans to use some events. For the most recent information on any event ID in the Windows Security log, refer to the Security Log Encyclopedia at www.ultimatewindowssecurity.com.