a Flo + a Blog = a Flog my ブログ

Kerberos Authentication Events

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: 0x2     Failure Code:  0x18     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: 0x2     Failure Code:  0x18     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: 0x2     Failure Code:  0x18     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.

How to enforce RD via GPO?

I was facing a little situation this week. We do have Terminal Servers (TS) with TS licensing server (TSLS) and it works fine, all the settings have been configured properly to let users I have to access it from outside and so on.

But I wanted to enable it for users to access Windows XP boxes (WinXP) , their WinXP from another location (the gateway). And I thought enabling RD and allow access to their Desktop would be less tricky.

First I created a GPO with 2 things:

1. Allow Users to connect remotely using TS from Computer>Adm template>Windows Components/Terminal Services>
2. Set the permisson to the right groups for log on from Computer>Windows settings>Local Policies>User Rights Assignment

But no this did not too much and gave me a nice error message when trying to log on when login with authorized usres: you do not have access to logon this session.

This meant that users can do TS on the WinXPs but cannot logon.

So if you want to avoid this little embarrassment please follow those steps (III being my mistake)

I. Locate the OU contains the Windows XP computers, create a group policy
object.
II. Configure the Remote Desktop policy setting:
1. In the group policy object, click to expand Computer Configuration,
click to expand Administrative Templates, click to expand Windows
Components, and then click to expand Terminal Services.
2. Double-click the "Allow users to connect remotely using Terminal
Services" policy.
3. Set the policy to Enable, and then click OK.

III. Moreover, if you want to specify a group of users who can RDP to the
Windows XP workstations, you can follow the steps below:
1. In Active Directory Users and Computers, create a Global group
containing the users.
2. Locate the OU contains the Windows XP computers, open the related Group
policy object.
3. Right-click Restricted Groups (under Computer Configuration\Windows
Settings\Security Settings\Restricted Groups), and then click Add Group.
4. Type "Remote Desktop Users" and click ADD, click OK. (Note: do not click
Browse to browse the group. )
5. Right-click the Remote Desktop Users group, and then click Properties.
6. To the right side of the Members of this Group box, click ADD, and then
click Browse.
7. Locate the group that you created, and then add it. After you do so,
close the group policy.
8. On the domain controller, at a command prompt, type "gpupdate /force",
and then press ENTER to refresh the policy.
Note: The original users in the Remote Desktop Users group on the Windows
XP clients will be overrided. Again, this is another simple option that screws things up. Always.