Guarding the Gates:
Understanding Kerberos in Windows 2000

by debra littlejohn shinder, mcse etc

Greek mythology is full of fearsome imaginary beasts. Perhaps one of the most well known is Kerberos (sometimes denoted by the Latin spelling Cerberus), a three-headed dog who was said to stand guard at the gates of Hades.

One might wonder why a guard would be needed at that particular location (were there really that many ancient Greeks trying to sneak in, compelled by a late night-craving for a little fire and brimstone?). Aside from that “burning” question, though, it’s not difficult to see why the name was appropriated by the engineers at MIT who developed the network authentication protocol that is a cornerstone of Windows 2000’s security model. Kerberos is a “three-headed” protocol that uses the client, the server and a trusted third party to validate identity and determine whether to “open the gates” to the requesting user, machine or application.

Although Kerberos is an industry standard, available in several implementations and used for quite some time in UNIX-based networking, many experienced Windows NT administrators are only vaguely aware of what the protocol is and what it does. As they seek to upgrade their skills to work with Microsoft’s newest network operating system, it will be imperative that they understand the Kerberos authentication process in Windows 2000, where and when it is (and isn’t) used, and how it provides interoperability in a hybrid network environment.

This article will give you a basic overview of Kerberos version 5, as implemented in Windows 2000, how it works, and where it fits into your network security scheme.

Why a New Authentication Method?

Why did Microsoft ascertain a need to introduce a new authentication protocol in Windows 2000? Windows NT 4.0 used the NTLM protocol for network authentication. Windows 2000 still supports NTLM (which is necessary for "downlevel" NT/Win9x clients on the W2K network), but its default authentication method is Kerberos v5. Let's look at a few of the advantages Kerberos offers over NTLM:

Performance: Because Kerberos authentication allows a client to obtain credentials for a specific server once and then reuse them during the logon session, rather than the server contacting a domain controller to authenticate each client, connections can be faster.
Server authentication: Kerberos allows clients to verify the identity of the server, as well as allowing servers to verify the identity of clients. This two-way, or mutual authentication is different from NTLM, which assumes the server's identity is not in question.
Two-way transitive trusts: One of the most important differences between Windows 2000 and NT 4.0 networking is the nature of trust relationships between domains. NTLM trusts are one-way and non-transitive, and must be explicitly created. By default, no trust relationships exist between the different domains in an NT network. Kerberos trusts, on the other hand, are two-way and transitive (meaning if domain A trusts B, and B trusts C, then A trusts C as well). Even better, these trust relationships within a Windows 2000 Active Directory forest are implicit. There is no need for an administrator to create trusts, as they already exist by default.

We can see, then, that Kerberos authentication offers some very real benefits over NTLM that can make a network administrator's job easier while improving the security of network communications. Another very important reason that Microsoft made the switch to Kerberos is interoperability with other network operating systems. Kerberos v5 is used for authentication by UNIX servers, and adopting a standard authentication protocol makes it easier for Microsoft networks to interoperate with other networks.

What is Kerberos and Where Did It Come From?

Engineers at MIT, working on a project called Athena that involved the validation of user identity on UNIX workstations, developed Kerberos as a solution to network security problems. MIT distributes Kerberos to citizens of the U.S. and Canada via their website at http://web.mit.edu/network/kerberos-form.html (However, note that Kerberos is built into Windows 2000; it is not necessary to obtain or install additional software to use it).

The premise on which Kerberos is based is that strong cryptography can be used to provide a way for a client and server to prove their identities to one another (authenticate). The origins of Kerberos can be traced to the authentication model presented by R.M. Needham and M.D. Schroeder way back in 1978, in a paper entitled “Using Encryption for Authentication in Large Networks of Computers.” Specifications for implementation of Kerberos are found in RFC 1510 (see http://www.cis.ohio-state.edu/htbin/rfc/rfc1510.html ).

How Does Kerberos Work?

Kerberos was designed to provide mutual authentication between a client and server on an open, non-secure network (such as the Internet). Shared secrets are used to accomplish this authentication. You may be familiar with the term, used in security documentation to denote a password known to two users. In this case, however, the shared secret is not a password but a cryptographic key. This key is symmetric, meaning it can be used both for encryption and decryption. This is commonly referred to as secret key encryption.

The “third head” of Kerberos is the Key Distribution Center (KDC), which is a service that runs on a trusted (physically secure) server. The KDC actually runs two services: the Authentication Service (AS) and the Ticket Granting Service (TGS). The KDC holds a database in which the cryptographic keys associated with each security principal (users and computers) are stored.

Note: Kerberos is designed around the concept of “realms,” which is a division of the network representing an organization that runs a Kerberos server. In the Windows 2000 implementation, a Windows 2000 domain is the equivalent of a Kerberos realm.

Tickets to Ride

Kerberos authentication is based on the use of tickets to prove the identity of a Kerberos client. A Kerberos client is any entity that requests a service ticket for a Kerberos service (such as the server service on a Windows 2000 machine where resources are stored that the client wants to access).

Here’s an analogy to help you understand how this works:

If you live in the U.S. and wish to visit another country (let’s say it’s France), you will need a means of identifying yourself to French authorities that they will accept as valid. So you apply to the U.S. government for a passport, which is a document that you can then present to the French authorities to enter their country. The U.S. passport agency is a trusted third party that can issue you credentials that are accepted by other countries.

Similarly, a client that wishes to access a resource on a server must first “apply” to the KDC for credentials that can be presented to the server(s) to be accessed.

The credentials issued by the KDC are called tickets. There are a couple of different types of tickets used by Kerberos:

· Ticket Granting Ticket: this ticket is granted by the KDC to allow the client to communicate with the KDC. When the client logs onto the network, the client’s credentials are verified with a domain controller, and the KDC issues this Ticket Granting Ticket (TGT). For the remainder of the logon session, the client can use this TGT to communicate with the KDC, without having to “prove” its identity again (that is, the KDC doesn’t have to verify the client’s credentials with a DC each time). The TGT is issued by the Authentication Service.

· Session Ticket: this ticket is granted by the Ticket Granting Service component of the KDC, to allow clients to access specific servers on which resources are located.

The process, then, goes like this:

1. Client logs on and receives a TGT from the AS.

2. Client presents TGT to TGS.

3. Client receives session ticket (also called a service ticket) from TGS.

4. Client presents session ticket to server it wishes to access.

This is a very simplified version, but illustrates how the tickets are used to provide authentication that is verified by a trusted third party (the KDC) so that the server that the client wants to access doesn’t have to go through the more time-consuming process of contacting a domain controller and verifying the client’s credentials. Session tickets can be reused, so that the client doesn’t have to return to the KDC each time it wants to access the same server during the logon session. When a user logs off, all session tickets are destroyed. Additionally, the administrator can set an expiration period for the session tickets, as we will see in the next section.

For much a much more detailed description of what goes on “under the hood” to accomplish the steps above, see the “Windows 2000 Kerberos Authentication” white paper in the Windows 2000 Server Technical Notes, at
http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.asp

Kerberos Policies

The Windows 2000 implementation of Kerberos allows you, as the administrator, to set policies to control how tickets are handled. For example, in a high security environment you would want to limit the amount of time for which an issued ticket remains valid. Just as passports and driver’s licenses - the credentials issued by government agencies to identify persons - have expiration periods, so do the tickets issued by the KDC.

Note: If a client presents an expired session ticket to a server, the connection will be denied and an error message returned. If the client is already connected to the server and the ticket expires, the connection will not be interrupted. The ticket is needed to authenticate the connection only; its subsequent expiration has no effect on that connection.

Kerberos policies are set, as are most types of policies in Windows 2000, by using Windows 2000 Group Policy. You’ll find the Kerberos policy settings under Computer Configuration | Windows Settings | Security Settings | Account Policies | Kerberos Policy, as shown in the figure below.

The Kerberos policy is defined at the domain level, and it is stored in the Active Directory as part of the domain’s security policy. Only domain administrators can make changes to these policies by default. Options that can be set include:

· Enforce user logon restrictions: This is a high-security setting, that causes the KDC to check the user rights policy on the server for which a client is requesting a service ticket, to ensure that the user has the right to access that computer locally or from the network. This increases security but also slows performance. By default, the option is enabled.

· Maximum lifetime for service ticket: This settings allows administrators to control how long a session ticket will be valid. The minimum setting is ten minutes and the default is ten hours (600 minutes). The value is shown in minutes.

· Maximum lifetime for user ticket: the “user ticket” referred to here is the TGT. Default time to expiration is ten hours.

· Maximum lifetime for user ticket renewal: This setting applies to both TGTs and session tickets (a little tricky, since it uses the same terminology that applies only to TGTs above). This is the time after which no ticket can be renewed, and by default is 7 days.

· Maximum time for computer clock synchronization: in order for ticket issuance to work properly, the clocks of the KDC and the Kerberos client must be synchronized. This settings allows you to specify the tolerance (difference allowed between the clocks), and by default is 5 minutes.

Because Kerberos is the foundation of Windows 2000 network authentication, you will need to understand at least the basics of how it operates, and be able to identify its components, both for the Windows 2000 MCSE certification exams and to aid in troubleshooting authentication problems on your Windows 2000 network.