a Flo + a Blog = a Flog

I found myself locked out a few times this week.
After a some locking out I thought it was me locking up my account as it is a fairly new password. However, it still locks out every day.

A quick “Account lockout status” tool use showed me that I am being locked out some other DC somewhere else in the world (and then replication locks me out here).

Then a scan on the eventlock using EventCombMT (from the same account tools kit) on this remote DC showed that some computer over there locks me out.

Generally in the event log you’ll see event id 529, event id 644, event id 675, event id 676, event id 681. Sometimes event id 12294 is also worth scanning for. But this tools also have some build-in eventID templates.

And I found a few:

675,AUDIT FAILURE,Security,Wed Sep 19 10:08:56 2007,NT AUTHORITY\SYSTEM,Pre-authentication failed:     User Name:  ME     User ID:  %{S-1-5-ME}     Service Name:  krbtgt/domain Pre-Authentication Type: 0×2     Failure Code:  0×18     Client Address:  10.X.8X.4X
675,AUDIT FAILURE,Security,Wed Sep 19 10:08:54 2007,NT AUTHORITY\SYSTEM,Pre-authentication failed:     User Name:  ME User ID:  %{S-1-5-ME}     Service Name:  krbtgt/domain     Pre-Authentication Type: 0×2     Failure Code:  0×18     Client Address:  10.X.8X.4X
675,AUDIT FAILURE,Security,Wed Sep 19 10:08:53 2007,NT AUTHORITY\SYSTEM,Pre-authentication failed:     User Name:  ME User ID:  %{S-1-5-ME}     Service Name:  krbtgt/domain     Pre-Authentication Type: 0×2     Failure Code:  0×18     Client Address:  10.X.8X.4X

A quick nslookup showed that 10.X.8X.4X is some evil users on another subnet as descovered with atsn.
atsn 10.X.8X.4X
IP Count: 1
>10.X.8X.4X;tokyo-TKO;10.X.8X.4X/24
Bad Bad Bad. First I would like to review how keberos and windows work…

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.

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.

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.

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 on this website. 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.

Now what can I do? Someone is trying to authenticate with my account and locks me out.