Kerberos v.5

Windows 2000 Active Directory relies on a different authentication protocol than Windows NT 4. Where NT 4 used the NT Lan Manager (NTLM) protocol for authentication, Windows 2000 utilizes Kerberos. The Kerberos protocol was developed at MIT, and is named after Cerebus, the three-headed fire-breathing dog that guards the gate to Hades. Why do I bother telling you this? Because it makes it easier to remember that Kerberos is a 3-pronged authentication scheme. The three parts of Kerberos are:

1. Client – the system/user making the request
2. Server – the system that offers a service to systems whose identity can be confirmed
3. Key Distribution Center (KDC) – the third-party intermediary between the client and the server, who vouches for the identity of a client. In a Windows 2000 environment, the KDC in a domain controller running Active Directory (It could be a UNIX-based KDC also)

The way that Kerberos works can seem a little intimidating if you get into all of the tiny little details, but I’ll spare them for an overview of how things work. It is more important that you understand the process to begin with. If you want every behind-the-scenes detail, I’ve provided a link at the end of the section.

In a Kerberos environment a user provides a username, password, and domain name (often referred to as a Realm in Kerberos lingo) that they wish to log on to. This information is sent to a KDC, who authenticate the user. If the user is valid, they are presented with something called a ticket-granting ticket, or TGT. I like to consider the TGT to be like a hand-stamp admission to a country fair – it proves that you have paid admission and have proof. The TGT is helpful in that it does not require you to constantly re-authenticate every time you need to access a server.

However, if you do want to access a server, you still require a ticket for that server or you will not be able to create a session with that machine. Think of a ticket as being like the ticket you need to purchase to get on rides at the country fair – even though you’ve paid admission (proved by the hand-stamp or TGT), you still need a ticket to get into the haunted house. When you wish to access a server, you first need to go to the KDC, present your TGT as proof of identity, and then request a session ticket for the server you wish to contact. This ticket simply acts as authentication between the client and the server you wish to contact. If you are authenticated, whether or not you will be able to actually access anything on the server will depend on your permissions. The TGT and session tickets that you are presented with actually expire after a period of time that is configurable via group policy. The default value for a TGT (also referred to as a user ticket) is 7 days, while the default value for a session ticket (sometimes called a service ticket) is 10 hours.

In a single-domain environment, Kerberos authentication is pretty straightforward. However in a multiple domain environment Kerberos has more steps involved. The reason for this is that when you are attempting to obtain a session ticket for a server, it must be obtained from a KDC in the domain where the server exists. Also, you must obtain session tickets in order to traverse the trust-path to the KDC you need to contact. The example below outlines the steps necessary for a client in west.2000trainers.com to access a server in east.2000trainers.com.

1. The client logs on to the network as a user in east.2000trainers.com, and is presented with a TGT.
2. The client wants to communicate with a server in west.2000trainers.com. It contacts the KDC in east.2000trainers.com, asking for a session ticket for a KDC in the 2000trainers.com domain.
3. After it receives this ticket, it contacts the KDC in 2000trainers.com, requesting a session ticket for the KDC in west.2000trainers.com.
4. After it receives this ticket, it contacts the KDC in west.2000trainers.com, and requests a session ticket for the server in west.2000trainers.com whom it originally wanted to contact.
5. Once granted the session ticket for the server, the client contacts that server directly and can access resources according to the permissions in place.

If this seems like a great deal of steps, that is indeed true. This is one of the reasons that you might consider implementing shortcut trusts, as outlined in my last article. If shortcut trusts exist, the shorter available path would be used. Kerberos is a wonderful protocol in that is makes the network much more secure, due to the necessity of authentication between clients and servers before a session can be established. It is actually much faster than you might think. For a good hands-on experiment, you might consider setting up multiple domains and then running network monitor while accessing resources between domains. Though the packets contents are encrypted, it will still give you a great idea of what is happening behind the scenes. Three utilities that you should be aware of for troubleshooting Kerberos problems are Netdom (discussed in a previous article), as well as the resource kit utilities KerbTray.exe and Llist.exe.