7.2 Kerberos

Kerberos is an Internet-standard authentication protocol originally developed at the Massachusetts Institute of Technology (MIT). Kerberos was specifically designed to correct the shortcomings of many older authentication protocols, including Microsoft's LM and a variety of then-popular authentication protocols unique to the Unix platform.

7.2.1 A Brief History of Kerberos

Kerberos is currently in its fifth version and is defined in the Internet Engineering Task Force's (IETF) Request For Comments (RFC) 1510. You can access any of the IETF's RFCs online at http://www.ietf.org. Kerberos is the Greek name for the mythological three-headed dog that guards the gates of Hades. The three heads of the mythical Kerberos correspond to the three basic roles in the Kerberos protocol: client, server, and Key Distribution Center (KDC).

7.2.2 How Kerberos Works

RFC 1510 describes in detail how the standard Kerberos protocol works. A number of MIT-standard implementations of Kerberos are available for various flavors of Unix; Microsoft closely adhered to the RFC standard when implementing Kerberos in Windows 2000 and Windows Server 2003.

7.2.2.1 Kerberos operational theory

To achieve its goals, Kerberos is a fairly complex protocol, involving several layers of encryption. Kerberos relies heavily upon shared secret authentication, which you learned about in Chapter 2. In the next few sections, I'll walk you through the process Kerberos uses to initially authenticate a user, allow a user to access resources, and allow middle-tier applications to access resources on a user's behalf.

All Kerberos transactions involve three parties:

The client: Who is attempting to access resources.
The server: Which contains the resources the client is attempting to access.
The Key Distribution Center, or KDC: Which provides authentication services. In a Windows Server 2003 environment, every domain controller (DC) in a domain is also a KDC.

7.2.2.1.1 Logging on

The logon process starts when the user types a username and password into the logon dialog box. From there, Kerberos takes over:

As shown in Figure 7-3, the user's client computer runs the password through the standardized one-way hash. The result, in theory, will match what the domain controllers have stored in Active Directory for the user's password. The client computer then builds an authenticator, which includes the current date and time and the user's name. One copy of the authenticator is encrypted, using the user's hashed password as the encryption key. Both copies are then sent to a domain controller.

Figure 7-3. Sending the authenticators to the domain controller
As shown in Figure 7-4, the domain controller receives the two authenticators. It reads the user's name from the unencrypted authenticator and uses that to look up the user's hashed password in Active Directory. The password is then used to decrypt the encrypted version of the authenticator.

Figure 7-4. Decrypting the authenticator
The domain controller analyzes the two authenticators. They must be identical, they must be no more than five minutes old, and they must not have been received before by the domain controller (to ensure an attacker is not trying to replay the authentication sequence). If all those conditions check out, the user is successfully authenticated.

The five-minute interval described here is known as "skew time" and is discussed later in this chapter.
As shown in Figure 7-5, the KDC service builds a special ticket-granting ticket, or TGT, which contains basic information about the user. The TGT also contains a randomly generated session key, which the client and KDC will use to encrypt and decrypt further communications. The KDC uses its own private encryption key to encrypt one copy of the TGT. Both copies are then encrypted by using the user's hashed password as an encryption key, and the combined package is sent to the user's client computer. Note that this is the last time the client or KDC will use the hashed password to encrypt data during this session.

Figure 7-5. Building and sending the ticket-granting tickets
As shown in Figure 7-6, the user's client computer uses the user's hashed password to decrypt the combined TGT package. This reveals a clear-text version of the TGT and an encrypted version that the client computer cannot decrypt. Both are stored as a pair in a special volatile area of memory (RAM) as shown in Figure 7-6. All future requests to the KDC will be encrypted using the session key contained within the TGT.

Figure 7-6. Building and sending the ticket-granting tickets

The area of RAM used to store Kerberos tickets is never swapped out to the system page file. Once the system is shut down, or if power is lost, all tickets are destroyed and must be recreated. This is done intentionally to ensure that a nefarious attacker cannot restart a computer and assume a user's credentials.

Once the user's client computer receives the TGT, the authentication process is done.

7.2.2.1.2 Accessing resources

When a client needs to access resources on a file server, it uses the TGT it received from the KDC to do so. Here's how it works:

As shown in Figure 7-7, the client builds a ticket request, indicating the file server that it needs to access. The request is encrypted using the session key included in the TGT. The encrypted request is bundled along with the encrypted copy of the TGT and sent to the KDC.

Figure 7-7. Sending a ticket request to the KDC

As shown in Figure 7-8, the KDC decrypts the TGT using its private encryption key. That reveals the session key within the TGT, and the fact that the KDC was able to decrypt the TGT ensures that it hasn't been tampered with. The KDC uses the session key to decrypt the main request and uses that information to build a ticket, which includes a list of the user's security group membership. The ticket also includes another randomly generated session key. One copy of the ticket is encrypted using an encryption key shared by the KDC and the target file server. The entire package is encrypted using the session key from the TGT and then sent to the client.

Figure 7-8. Building a ticket for a client

All computers have their own domain password, which they store after hashing it. They use this hashed password as a shared secret encryption key with the KDC, since the KDC has access to the identical copy of the password in Active Directory.

As shown in Figure 7-9, the client receives the ticket from the KDC, decrypts it, and stores it in volatile RAM, along with the TGT and any other tickets. One copy of the ticket is unencrypted, allowing the client to access the ticket's expiration date and the ticket's session key. Until that ticket either expires or is destroyed, the client will continue to use the copy now in RAM to access the file server, rather than asking the KDC for another ticket each time.

Figure 7-9. Receiving the ticket and sending it to the server
As shown in Figure 7-10, the client builds an authenticator, encrypts it using the ticket's session key, and sends it to the server. The client also sends the encrypted version of the ticket that the client received from the KDC. The server decrypts the ticket by using its shared secret encryption key, thus revealing the ticket's session key. The server uses the ticket's session key to decrypt the authenticator and verify the timestamp. The server knows that only the KDC could have encrypted the ticket with the server's own private key, and so the server trusts the ticket.

Figure 7-10. Examining the ticket and granting access

The resource request is finished. The file server never had to contact a domain controller to validate the user's identity or security token, and the server doesn't have to keep the user's ticket in memory. The user's computer will resend the ticket every time access is required, preventing the server from having to manage authentication information on its own.

Although the resource request is finished and authentication information is provided, the resource access is not necessarily granted. A second process, authorization, now takes place to determine if the known-authentic entity is allowed to access the requested resource. This authorization is based on the identity of the user and the list of the user's security groups included in the ticket.

7.2.2.1.3 Proxy authentication

Multitier applications are becoming more and more common in business environments. In a multitier application, users run a client application, which communicates with one or more middle-tier applications. The middle-tier applications generally perform data validation and other business logic, before passing data on to a backend tier such as a database server. One example is a proxy service that accepts database queries from a web server, sends them to a database on an intranet, and then returns the data to that web server. The proxy service prevents the user from directly accessing the data while providing the desired data access services.

Although the users never physically interact with the backend data, they should be prevented from accessing any data that they are not authorized to view or change. In the past, middle tier applications used powerful administrator credentials to access the backend tier and implemented their own security mechanisms to determine what data the user should have access to. This technique presents a security risk, because if the middle-tier's security mechanism is flawed or circumvented, the middle tier may provide users with data they are not authorized to have. For example, many middle-tier applications are designed to use a powerful administrator account and to determine users' permissions through the use of a simple database table. That table is rarely protected or encrypted, making it easy to modify the information it contains. By modifying the table, an attacker could easily grant himself additional permissions and take advantage of the middle-tier application's full administrator privileges.

Kerberos includes two methods for a middle-tier application to use a user's credentials on their behalf, effectively impersonating the user when accessing upper application tiers. This impersonation assures that the user won't have access to any data she shouldn't, because the backend tier believes that the user, rather than a generic middle-tier application, is actually accessing the data.

Domain policy must be configured to allow either type of impersonation discussed next. Setting domain policy is described in Chapter 5.

Kerberos' first form of impersonation is proxy tickets. When a client needs to access backend resources through a middle tier, the client asks the KDC for a proxiable ticket. The KDC generates the ticket and sends it to the client, who then forwards it to the middle-tier application. Because the ticket is marked as proxiable, the middle-tier application is able to use the ticket to access resources on the backend server. The primary disadvantage of proxy tickets is that the client must know the name of the backend server. Most multitier applications don't make that information available to a client, because the backend is often composed of several servers that load-balance work between them.

Kerberos' other form of impersonation is forwardable tickets. The process for obtaining and forwarding a ticket is more complex and requires more overall computing power, but it allows clients to access backend resources through a middle-tier application without knowing backend server names. Here's how it works:

The client contacts the KDC and requests a forwardable TGT. The client provides the name of the middle-tier server it plans to forward the ticket to, and the KDC encrypts the TGT using that server's shared secret. The TGT contains the security group membership list for the requesting user.
The KDC sends the forwardable TGT to the client, who is unable to read it but simply forwards it to the middle-tier server.
When the middle-tier application needs to access resources, it uses the forwarded TGT to request a ticket from the KDC. The KDC sees the request as coming from the original user and builds a ticket for the backend server that includes the list of the user's security groups.
The middle-tier application uses that ticket to access the backend resource. The backend server sees the request as coming from the original user and limits the available resources to those that the user is authorized to access.

Kerberos' ability to allow software applications to impersonate users allows administrators and software developers to create multitier applications that are significantly more manageable and secure than they could using older authentication protocols like NTLM. However, using Kerberos' impersonation features does require extra development effort on the part of software developers, although that extra effort is minimal in most cases.

7.2.2.2 Microsoft's Kerberos implementation

The Kerberos protocol included in Windows Server 2003 closely adheres to the RFC 1510 standard. In fact, Windows Server 2003 is basically compatible with non-Windows servers and clients that also use a standard MIT implementation of Kerberos, as I'll discuss later in this chapter. While this compatibility is far from turn-key, it can be made to work with a reasonable amount of effort.

Microsoft also wanted a way for Kerberos to work in the broader environment of the Internet. As written, Kerberos relies on shared secrets for its encryption. Shared secrets are fine within an organization, but when you want to authenticate outside users, there's no way for a shared secret to work. Also, as designed in RFC 1510, Kerberos provides no means to interoperate with smart cards, an increasingly popular form of authentication for many companies. Microsoft responded by modifying their implementation of Kerberos to include support for public key infrastructure, or PKI, allowing Kerberos to work with smart cards and, in theory, with any PKI infrastructure. Rather than working in a vacuum, though, Microsoft submitted their modifications as an Internet Draft to the IETF, helping ensure that future versions of the standard MIT Kerberos will include PKI compatibility. As of the time of this writing, this submission is still in Internet Draft form. You can learn more about PKI in Chapter 9 and the AppendixAppendix A.

7.2.3 Configuring Kerberos

While Kerberos doesn't require any configuration to operate properly, you can customize Kerberos' operation slightly by modifying policies within your domain. The following settings control Kerberos' behavior:

Maximum life for service tickets (default: 600 minutes): This is the maximum length of time a service may hold a Kerberos ticket before a new ticket is required. You shouldn't change this policy unless you have a specific reason to do so or have been advised to do so by Microsoft Product Support.
Maximum life for user tickets (default: 10 hours): This is the maximum length of time a user may hold a Kerberos ticket before a new ticket is required. Lowering this value will make tickets expire more frequently, placing a heavier load on your DCs to issue replacements. Raising this value allows tickets to remain in effect for much longer, increasing the possibility of their being compromised.
Maximum life for user ticket renewals (default: 7 days): When a user's ticket expires, his client computer will automatically try to renew the ticket. Renewing places less load on DCs, because they do not need to look up the user's password or perform other steps associated with issuing a new ticket. By lowering this value, you can increase the load on your DCs, as they will have to issue more new tickets than renewals. You also shorten the time between account lockout or expiration and the time when the ticket is destroyed, which can improve security in environments in which account lockouts and expirations occur frequently.

If your users shut down their computers at the end of the day, their Kerberos tickets are destroyed, and the maximum life or maximum number of renewals for those tickets isn't important. So if your users are in the habit of shutting down their computers at the end of the day, there's no benefit in modifying the maximum life for user ticket renewals.

Maximum tolerance for computer clock synchronization (default: 5 minutes): This policy determines how much allowance Kerberos makes for other computers' clocks being out of sync. Since Kerberos communications are time-sensitive, this setting may require adjustment on especially busy networks with extremely high network latency and poor time synchronization.

Keep in mind that, by default, all computers within a domain synchronize their system clocks to a domain controller, and all domain controllers synchronize with the domain controller holding the PDC Emulator role. On a properly functioning network, five minutes of clock tolerance should be sufficient.

You can configure Kerberos' policies in your domain by modifying the domain's Kerberos policy, as shown in Figure 7-11.

Figure 7-11. Modifying the default domain Kerberos policies

7.2.4 Kerberos Pros and Cons

Kerberos offers a number of advantages over older authentication protocols such as NTLM:

Mutual authentication of all parties is assured by Kerberos' use of tickets.
The primary burden of authentication is placed upon the client computer rather than upon servers.
Kerberos provides a means for middle-tier applications to access resources on behalf of a user, by using that user's credentials in a secure fashion.
Because all domain controllers function as Kerberos KDCs, there is no central server bottleneck for authentication requests. This is in contrast to earlier versions of Windows NT, with which the primary domain controller (PDC) often became an authentication bottleneck because of its centralized design.
Kerberos never transmits even a portion of the user's password over the network.
Kerberos is time-sensitive, preventing attackers from capturing and replaying network packets in an attempt to gain network access. Kerberos also tracks authenticators and will reject an authenticator that is used more than once.
Kerberos is compatible with many non-Windows operating systems, making it easier to configure centralized authentication on a heterogeneous network.

Kerberos' single disadvantage, if you can call it a disadvantage, is that it isn't compatible with NTLM. For that reason, Windows Server 2003 maintains an NTLM-based security provider for older Windows clients that do not support Kerberos.

7.2.5 Kerberos Interoperability

Since Kerberos is an Internet-standard protocol, Microsoft's implementation is basically compatible with any other MIT-standard version of Kerberos, whether running on the client or on the server. Here are the details about Windows' Kerberos interoperability:

Unix-based Kerberos clients can authenticate to a Windows KDC by using standard Kerberos utilities such as kinit and either DES-CBC-MD5 or DES-CBC-CRC encryption.
Windows clients can authenticate to Unix-based KDCs in a Kerberos realm.

Kerberos realms are roughly the equivalent of Active Directory domains.

Windows provides the ability to map local computer accounts to Kerberos principals, allowing users a single logon that includes non-Windows Kerberos realms.
Windows can maintain trust relationships with non-Windows Kerberos realms.
Active Directory includes the means to map user accounts to Kerberos principals in trusted realms.

Most Windows-Unix interoperability problems stem not from Kerberos, but rather from the inherent differences in the way the two operating systems handle authorization. For example, without the proper account mapping in Active Directory, principals in a Kerberos realm cannot provide the information necessary to build an access token and therefore be granted access to domain resources.