The Windows Security Log Revealed

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.



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

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






user name does not exist




user name is correct but the password is wrong




user is currently locked out




account is currently disabled




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



workstation restriction

Logged only for domain accounts that are configured with workstation restrictions



account expiration

Logged only for domain accounts that are configured with an account expiration



expired password




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



Evidently a bug in Windows and not a risk



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





Client's entry in database has expired




Server's entry in database has expired




Requested protocol version # not supported




Client's key encrypted in old master key




Server's key encrypted in old master key




Client not found in Kerberos database

Bad username, or new computer/user account that has not replicated to DC yet



Server not found in Kerberos database

 New computer account that has not replicated yet or computer is pre-Windows 2000



Multiple principal entries in database




The client or server has a null key

 Administrator should reset the password on the account



Ticket not eligible for postdating




Requested start time is later than end time




KDC policy rejects request

Workstation/logon time restriction



KDC cannot accommodate requested option




KDC has no support for encryption type




KDC has no support for checksum type




KDC has no support for padata type




KDC has no support for transited type




Clients credentials have been revoked

Account disabled, expired, or locked out



Credentials for server have been revoked




TGT has been revoked




Client not yet valid - try again later




Server not yet valid - try again later




Password has expired

The user’s password has expired



Pre-authentication information was invalid

Usually means bad password



Additional pre-authentication required*




Integrity check on decrypted field failed




Ticket expired

Frequently logged by computer accounts



Ticket not yet valid




Ticket not yet valid




Request is a replay




The ticket isn't for us




Ticket and authenticator don't match




Clock skew too great

Workstation’s clock too far out of sync with the DC’s



Incorrect net address

 IP address change



Protocol version mismatch




Invalid msg type




Message stream modified




Message out of order




Specified version of key is not available




Service key not available




Mutual authentication failed

 May be a memory allocation failure



Incorrect message direction




Alternative authentication method required*




Incorrect sequence number in message




Inappropriate type of checksum in message




Generic error (description in e-text)




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




Kerberos Authentication Service

A Kerberos authentication ticket (TGT) was requested

Success or failure


Kerberos Service Ticket Operations

A Kerberos service ticket was requested

Success or failure


Kerberos Service Ticket Operations

A Kerberos service ticket was renewed



Kerberos Authentication Service

Kerberos pre-authentication failed.



Kerberos Authentication Service

A Kerberos authentication ticket request failed

We have not seen this event.


Kerberos Service Ticket Operations

A Kerberos service ticket request failed.

Not used; event 4769 failure used instead


Other Account Logon Events

An account was mapped for logon.

We have not seen this event


Other Account Logon Events

An account could not be mapped for logon.

We have not seen this event


Credential Validation

The domain controller attempted to validate the credentials for an account.

NTLM authentication. Not necessarily a DC. May be any Windows server.


Other Account Logon Events

The domain controller failed to validate the credentials for an account

We have not seen this event


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

Next Chapter

Back to top

Supercharger Enterprise

Load Balancing for Windows Event Collection



Additional Resources