Kerberos Authentication Events Explained

If you want even more advice from Randall F Smith, check out his seminar below:


Attend the only 2-day seminar devoted to the Windows security log

 

Tracking Logon Activity with Domain Controller Security Logs

In my last article I showed you how to read NTLM authentication events on your domain controllers’ security logs. NTLM events help you identify pre-Windows 2000 computers in your forest, logons from computers outside the forest including attacks from unauthorized computers. However the bulk of authentication events you find on your domain controllers are likely Kerberos events since Kerberos is the default authentication protocol for Windows 2000 and later computers in an Active Directory domain. To understand these Kerberos events it helps to understand the basic functioning of the Kerberos protocol. Kerberos uses the concept of tickets. A ticket is small amount of encrypted, session specific data issued by the domain controller. When a client needs to access a server on the network, it first obtains a ticket from the domain controller for that server. The ticket and other data supplied by the client vouches for the clients identity and provides away for the client to authenticate the server as well which means 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.

Kerberos Basics

First, let me explain how the overall ticket process works then I’ll walk you through an actual user’s actions and how they relate to Kerberos events. There are actually 2 kinds of tickets, authentication tickets (aka ticket granting tickets and service tickets). Kerberos issues an authentication ticket when a client first authenticates itself to the domain controller. The domain controller 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 decrypts the session key with it’s personal key. Then the client uses it’s authentication ticket and session key to obtain a service tickets for each server the client needs to access. Windows generate security log events at each step of the Kerberos authentication process and if you know how to relate general Kerberos events to user activity in the real world then you can closely monitor domain logon activity and pinpoint suspicious events.

Kerberos and the Windows Security Log

Imagine Fred walking into his office one morning. Fred sits down in front of his XP computer, turns it on and enters his domain user name and password. Fred’s workstation needs to know if Fred is really Fred so it sends an authentication request via Kerberos to the domain controller. In Unix based Kerberos implementations, Kerberos simply issues an authentication ticket without checking the client’s credentials. If the client can successfully decrypt the session key that comes with the authentication ticket to request service tickets 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 due to a bad password. However, Windows takes advantage of an optional feature of Kerberos called pre-authentication. With pre-authentication the domain controller checks the user’s credentials before issuing the authentication ticket. If Fred enters a correct username and password, Windows logs a successful event ID 672, “Authentication ticket granted”. When you see event ID 672 where Fred is the user name in the event’s description, you can interpret this event as Fred’s initial logon at his workstation. In fact you can even identify his workstation with the Client Address field in event ID 672’s description. All Kerberos events include Client Address which identifies the IP address of the client computer. The other useful field in event ID 672 is “Supplied Realm Name” which identifies the domain of the user account which in figure 1 is Marketing. Other Kerberos events identity the domain as “User Domain” or prefix the user name with the domain as in “Marketing\Fred”. But what if Fred enter’s a bad password? In this case Kerberos pre-authentication catches this at the domain controller and Windows logs event ID 675, “Pre-authentication failed”, with Failure Code 24 in the event’s description (see figure 2).

Assuming the workstation successfully obtains an authentication ticket on behalf of Fred, the workstation next must obtain a service ticket for itself – that is a service ticket that authenticates Fred to the workstation and allows him to logon. This event shows up as event ID 673, Service Ticket Granted. The Service Name field in event ID 673 identifies the service the ticket was granted for – in this case the workstation’s name. To recap just for a moment, when Fred logs on at his workstation for the first time that day, the domain controller that handles that logon will log event ID 672, closely followed by an event ID 673 where the Service Name corresponds to the computer name of Fred’s workstation. That isn’t the end of event ID 673 though. You’ll see an instance of event ID 673 for each server users access after logging into their workstation. For instance let’s imagine that Fred’s logon script or persistent drive mappings initiate connections to the MktgFiles shared folder on the FS2 server. The domain controller will log an event ID 673 when Fred’s workstation obtains a service ticket to FS2 as shown in figure 3.

I showed you what Windows logs when a user enters a bad password but what about all the other reasons a logon can fail such as an expired password or disabled account?  Windows 2000 catches all of these logon failures after pre-authentication and therefore logs event ID 676, “Authenication Ticket Request Failed”. Again you need to look at the failure code to determine the problem. The most common Kerberos failure codes are noted below in figure 4. Windows Server 2003 doesn’t log event ID 676. Instead Windows Server 2003 re-uses event ID 672 but changes the type to Failure Audit instead of Success Audit.

Extraneous Kerberos Events

Windows logs a lot of what most people consider extraneous Kerberos events that you can simply ignore.  For instance to support Windows infrastructure features like Active Directory, Group Policy, Dynamic DNS updates and more, workstations, servers and domain controllers must frequently communicate with each other. At such times, the Windows computer authenticates to the domain controller using its own Active Directory computer account which in turn generates Kerberos events. You can identify such computer to computer authentication events because the user name listed in the event is a computer instead of a user. Computer account names are easily recognizable because they have a $ appended to the name. See FS2$ in figure 3. You will also see plenty of occurrences event ID 677 resulting from ticket expirations. Ticket expiration is a natural part of Kerberos activity and Windows handles ticket renewal automatically. Because of issues like this and because of the quantity of Window systems on a typical network, some kind of event monitoring tool is critical if you want to stay on top of account activity throughout your network. For instance Lan Guard SELM allows you to monitor multiple Windows computers and merge the activity into central database for reporting. Additionally SELM allows you to automatically filter out extraneous events such as computer to computer authentication and ticket renewal activity so that you can concentrate on the important data.

As you can see, Windows Kerberos events allow you to easily identify a user’s initial logon at his workstation and then track each server he subsequently accesses using event ID 672 and 673. You can track failed authentication events using event IDs 675 and 676 or on Windows Server 2003 domain controllers – event IDs 676 and failed event ID 672. However keep in mind that authentication events logging on domain controllers (whether Kerberos or NTLM) doesn’t record logoff events. That’s because domain controllers only perform authentication services, 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 and in this case use the “audit logon events” instead of “audit account logon events”.

Fig 1 – Event ID 672

Fig 2 – Event ID 675

Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 675
Date: 2/12/2004
Time: 3:22:32 AM
User: NT AUTHORITY\SYSTEM
Computer: DC1
Description:
Pre-authentication failed:
User Name: Fred
User ID: MKTG\Fred
Service Name: krbtgt/MKTG
Pre-Authentication Type: 0x2
Failure Code: 24
Client Address: 10.42.42.10

Fig 3 – Event ID 673
Event Type: Success Audit
Event Source: Security
Event Category: Account Logon
Event ID: 673
Date: 2/12/2004
Time: 3:22:32 AM
User: NT AUTHORITY\SYSTEM
Computer: DC1
Description:
Service Ticket Granted:
User Name: fred
User Domain: MKTG.COM
Service Name: FS2$
Service ID: MKTG\FS2$
Ticket Options: 0x40810010
Ticket Encryption TypE: 0x17
Client Address: 10.42.42.10

Fig 4 – Kerberos Failure Codes

Error Code Cause
6 The username doesn’t exist.
12 Workstation restriction; logon time restriction.
18 Account disabled, expired, or locked out.
23 The user’s password has expired.
24 Pre-authentication failed; usually means bad password
32 Ticket expired. This is a normal event that get frequently logged by computer accounts.
37 The workstation’s clock is too far out of synchronization with the DC’s clock.

For other Kerberos Codes see http://www.ietf.org/rfc/rfc1510.txt

Attend Randy’s Intensive 2 Day Seminar


Security Log Secrets

Security Log Secrets is an intensive 2 day course in which Randy shares the wealth of knowledge he has gleaned over years of research on the Windows Security log. You will cover all 9 audit categories of the security in depth and learn how to query the security log using simple SQL like query commands. You will come away with tons of sample scripts for helping you monitor automate security log tasks such as monitoring, alerting, archival, clearing and more. You’ll also learn how to interpret other important security related logs of components like RRAS, IAS, DHCP server and more. Security Log Secrets is available now for on-site classes and scheduled as a public seminar on October 4, 5 in New York City. To register and learn more browse to http://ultimatewindowssecurity.com/seclogsecrets.asp and download your free Security Log Quick Reference chart.

Author’s Bio:
Randy Franklin Smith, president of Monterey Technology Group, Inc. and a Systems Security Certified Professional, specializes in Windows security. Randy is the creator and exclusive instructor for the Ultimate Windows Security seminar and the new Security Log Secrets course.

You can contact Randy at [email protected]

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top