Section 9.1. Kerberos Fundamentals

9.1. Kerberos Fundamentals

Kerberos is a centralized login tool. This statement, although true, is deceptively simple. Kerberos was designed to solve certain authentication problems that aren't easily handled by other protocols. Understanding these problems, and how Kerberos solves them, will help you configure a Kerberos server, as well as determine whether you want to do so. You'll also have to decide what Kerberos software you want to run, both in terms of the server itself and the Kerberos application servers and clients you'll run with it. Many of these decisions are likely to be Linux-centric, but depending on your needs, chances are you'll need to make Windows-related Kerberos decisions, as well.

9.1.1. The Problem: Centralized Single-Authentication Logins

Large local networks are likely to host many servers. This arrangement makes centralized authentication tools, such as NT domains and LDAP, desirable. However, centralizing login control in one server is just part of the answer. Kerberos was actually designed to meet three major needs:

Centralize authentication

The most fundamental Kerberos design goal is to centralize authentication. This goal is basically the same as the primary goal of NT domains and is one of the many possible functions of LDAP. Kerberos also gives considerable weight to a sort of reverse authentication: providing an assurance to clients that the servers they connect to are the ones they claim to be. This identity verification helps ensure that, for instance, you're actually saving your departmental budget on your real departmental file server, rather than on the laptop of an industrial spy who's pretending to be a photocopier technician.

Protect passwords

One problem with many network protocols that require authentication is that they're susceptible to password sniffing. To be sure, the last few years have seen great strides in this area, with secure protocols such as SSH largely displacing less secure protocols, such as Telnet. Still, Kerberos was designed with a high degree of attention to password security. It's also designed as a tool that can be used by many protocols, so any Kerberized client and server (that is, programs that have been designed to use Kerberos authentication) can gain the Kerberos password security benefits. Many Kerberized applications also provide encryption of non-password data, although this isn't a necessary feature of such tools.

Provide single-login operation

This is arguably Kerberos's most unusual design feature. The idea is that users frequently log into a computer and proceed to use it to access many other computers. You might retrieve your email from a POP server, use a remote login protocol to run programs on another system, upload files to a third computer using FTP, submit print jobs using a printing protocol, and so on. Typing a password for each access becomes tedious at best. To be sure, some tools save your password on disk to mitigate the problem, but this practice is a potential security risk. Kerberos was designed to solve the problem by enabling single logins: once you've authenticated yourself to the Kerberos server, you don't need to do so again with any Kerberos application server that defers to the main Kerberos server.

Of these features, the first two are handled reasonably well by both NT domains and LDAP, although neither really addresses the issue of server authentication for clients. (The NT domain controller and LDAP servers' identities may be authenticated, but other servers are not.) The single-login feature of Kerberos isn't well addressed by either of these alternatives. (Windows caches passwords for file server access, which presents the illusion of a single logon to the NT domain. This caching only helps with certain protocols, though.)

On the flip side, Kerberos wasn't designed with account management at the forefront. In particular, tools for delivering full account information to Linux clientsthe tasks performed by NSS in Linuxare lacking in Kerberos. Although you can use Kerberos as part of a workstation login procedure, you need to maintain local accounts using local databases, LDAP, or some other tool.

Microsoft's Active Directory uses LDAP in conjunction with Kerberos. These two tools provide some overlap in function, but they also complement each other very well. Unfortunately, Microsoft's Kerberos implementation is a bit odd and doesn't interact well with some non-Microsoft versions. These matters are described in Section 9.1.4 and Section 9.5.

9.1.2. An Overview of Kerberos Operation

Discussions of Kerberos, like those of LDAP and NT domains, tend to be filled with lots of jargon. Understanding these terms is necessary for understanding how Kerberos works and how to configure it.

KDC

The key distribution center is the heart of Kerberos; it's the system that manages Kerberos logins. In other words, it's the Kerberos server. Some networks host multiple KDCs, in which case one is a master KDC, and the others are slave KDCs. For brevity's sake, this chapter describes only master KDC configuration. Slave KDCs are configured in much the same way as their masters, but both master and slave require additional components to propagate the password database to all KDCs.

Kerberized

This adjective describes server or client programs that support the Kerberos protocols. They rely on the KDC for authentication, albeit in an indirect way, as described shortly. They can often also authenticate users in more conventional ways as a backup to their Kerberos functionality.

Kerberos application server

An application server runs Kerberized servers.

Kerberos client

This term refers to any computer that obtains a ticket (described shortly) from a KDC. Normally, the Kerberos client is a client program run by a user.

Realm

A Kerberos realm is the range of the KDC's responsibility. Kerberos realms are often named after DNS domains or subdomains, but realm names are case-sensitive and are conventionally uppercase. For instance, if you're configuring a Kerberos system for the example.com domain, you'd probably call the realm EXAMPLE.COM. The realm need not correspond exactly to the domain, though; it can include or exclude specific computers, as you see fit.

Tickets

Tickets are at the heart of Kerberos authentication. A ticket is an encrypted hunk of data that's passed between systems as a mode of authentication. Most tickets are encrypted using a password, meaning that proper encryption of the ticket is proof of the ticket's validity.

TGT

A ticket-granting ticket is a special type of ticket that can obtain additional tickets. The KDC delivers a TGT to a user; the Kerberos client tools use the TGT to request tickets for accessing specific servers.

TGS

The ticket-granting service is the KDC subsystem that's responsible for granting TGTs.

Principals

A Kerberos principal is a user or server identification. Principals take the form primary/instance@REALM, where primary is a name (frequently a username), instance is an optional expansion that enables one user to have multiple principals, and REALM is the realm name. For instance, [e-mail] is a possible principal for the user fluffy on the EXAMPLE.COM realm. Administrators frequently have a secondary principal with the instance name of admin, so if fluffy were an administrator, the account's administrative instance would be fluffy/[e-mail]. Principals for application servers are named after the server, as in telnet/[e-mail] for the Telnet server on mandragora.example.com. Computers that run application servers also require principals, on which the primary name is host, as in host/[e-mail]. Much of the administrative work of running Kerberos involves managing principals.

The fact that Kerberos is reliant on tickets makes its operation a bit different from that of most other network authentication tools, although many details can be hidden from users. In broad strokes, the system works like this: the user requests a TGT from the KDC, which delivers the TGT to the Kerberos tools on the user's system. When the user then initiates a connection to an application server, the Kerberos utilities on the client pass the TGT back to the KDC along with information on the server the user wants to connect to. The KDC replies with a new ticket, which is encrypted with the application server's password. This ticket includes the username and other relevant information. The user's system then forwards this ticket to the application server, which knows the ticket is valid because it's been encrypted with its own password (which is known only to the application server and the KDC). At this point, the user is authenticated to use the application server, and the session can proceed much as it would with a more direct username/password exchange. (The application server can, of course, apply its own local security rules to limit access on a user-by-user basis, up to and including denying specific users access even if they've been authenticated by the KDC.)

Kerberos tickets include time stamps, and they expire after a limited period of time, which varies depending on your Kerberos options and the type of ticket. Thus, if a computer's clock is set incorrectly, it may not be able to authenticate on a Kerberos network. For this reason, if you use Kerberos, you should also use a network clock-setting tool to ensure that your systems' clocks are all set correctly. Chapter 15 describes one tool you can use for this purpose, the Network Time Protocol.

In practice, and from a user's point of view, using Kerberos involves two operations: authentication with the KDC and accessing servers. Tools for the former, and for managing Kerberos sessions, are described in Section 9.4.3. Some tools can integrate KDC authentication with a desktop system's basic login, so the process can be quite seamless from a user's perspective. Still, the focus for Kerberos is on providing centralized network accesses, whereas the focus for LDAP, and to a lesser extent NT domains, is in providing centralized authentication for desktop logins. This distinction can be subtle, but is important in understanding when and how to deploy Kerberos, as opposed to other tools. Kerberos is best suited to environments in which users must frequently access a variety of password-protected servers for which Kerberized variants are available. Kerberos is less useful in environments in which users log into their desktop systems and then seldom need to access other password-protected computers. For desktop authentication alone, LDAP or NT domains do a better job. (NT domain logins, particularly for Windows desktop systems, also provide the illusion of password-less access to file and printer shares, but not to most other types of servers.)

9.1.3. Kerberos Tools for Linux

One of the difficulties with Kerberos is in deciding which Kerberos to use. Broadly speaking, Kerberos packages can be classified as V4 or V5, V5 being the latest. Linux implementations of both versions include:

MIT Kerberos

Kerberos originated at MIT, and so many people consider the original MIT Kerberos to be the standard. You can peruse its official web site, http://web.mit.edu/kerberos/www/, and download it from there. Kerberos is available in source code form and as binary packages for several OSs, including Linux, Windows, and Mac OS (both pre-X and X versions). MIT's Linux binaries, though, are available only in the form of a tarball. The latest version, 1.3.5, is a Kerberos V5 implementation.

Heimdal

This version of the Kerberos V5 protocol is hosted in Sweden, at http://www.pdc.kth.se/heimdal/. This site hosts source code and some binary packages, including versions for Linux, Solaris, DEC Unix, and Mac OS X. Version 0.6.3 is the latest as I write.

eBones

This package, headquartered at http://www.pdc.kth.se/kth-krb/, is a Kerberos V4 implementation. It's sometimes released with Linux distributions under a package name such as krb4. As a Kerberos V4 implementation, it's a bit dated, but if your site uses Kerberos V4, you might consider using it. The latest version as I write is Version 1.2.2.

Many distributions ship with one or more of these implementations in binary form. Typically, MIT Kerberos is available under the package name mit-krb5 or krb5, whereas Heimdal is available as heimdal or something similar. Some distributions split the Kerberos package into parts, separating base tools, application servers, and clients. In theory, you should be able to mix and match Kerberos V5 implementations (MIT Kerberos and Heimdal, for instance); however, in practice you may find it easier to stick to a single product whenever possible. Problems are most likely to crop up in administrative tools and trying to mix master and slave KDCs of different types; problems between clients and KDCs or application servers are less common. Likewise, cross-OS mixes (using Linux MIT Kerberos clients and a MacOS MIT Kerberos KDC, for instance) should work, although problems sometimes crop up. Because Kerberos V4 is becoming rather elderly and has some protocol security bugs, this chapter describes V5 exclusively.

This chapter uses Heimdal and MIT Kerberos V5 implementations as references. The reference realm's primary KDC runs Heimdal 0.6 on SuSE 9.1, but this chapter describes both Heimdal and MIT Kerberos tools and commands for most tasks.

Linux Kerberos packages ship with several Kerberized servers and clients, including Telnet, rlogin, FTP, rsh, and rcp programs. Subsequent sections of this chapter describe some of these tools in greater detail.

Kerberos was designed to enable just about any protocol that requires authentication to use it. Thus, the list of Kerberized protocols isn't limited to those that ship with the main Kerberos package. If you want to use Kerberos in conjunction with a protocol that's not supported by a client or server that ships with Kerberos, you should search for support elsewhere. Although Kerberos support is far from universal, many clients and servers do support the protocol. Sometimes this support comes in the form of a compile-time option, so you may need to recompile your software to include the Kerberos features. In other cases, you may need to switch from one client or server package to another one. Unfortunately, Kerberos support, although far from restricted to the clients and servers provided with Kerberos packages, is also far from universal; you may need to search long and hard to find Kerberized tools for a particular task.

9.1.4. Windows and Kerberos

In theory, Windows can fit into a Kerberos realm as easily as Linux. In practice, of course, you'll need to learn to configure both Linux and Windows; configuration file locations and the like will differ between the two platforms. You might also run into compatibility problems related to specific Kerberos implementations.

Of particular note along these lines is the fact that Windows 2000 and later ship with AD support, and AD includes Kerberos as one of its components. Microsoft, however, implemented Kerberos in a slightly different way than did other providers. Some notable areas of divergence include:

Encryption algorithms

For political and technical reasons, Microsoft chose to support a different set of encryption algorithms than did the versions of Kerberos available in 2000. The practical upshot of this decision is that, if you use an AD controller as your KDC, you must either enable Data Encryption Standard (DES) encryption on the KDC and change users' passwords or use a recent version of Kerberos (such as MIT Kerberos 1.3 or later) on the non-Microsoft systems.

The PAC

Perhaps the biggest Windows/non-Windows Kerberos compatibility issue is the Privilege Access Certificate (PAC). This is an extra field added to tickets returned by a Windows KDC. Microsoft's own Windows clients typically refuse to work with a KDC that doesn't return a PAC, which makes interoperating with a Linux KDC difficult, for example. Microsoft developed the PAC in a proprietary way, but in late 2003 some documentation on the PAC became available, so this problem is also fading in importance. Fortunately, non-Microsoft Kerberos implementations typically ignore the PAC, so Linux Kerberos application servers and clients should be able to operate with a Windows KDC.

Cached credentials

Windows systems cache their login credentials as a way of supporting logins on laptops or in case of a KDC or network failure. Ordinarily, this practice poses no problems, but if a user logs on using a cached credential and a non-Microsoft KDC then becomes available, the system isn't likely to notice the KDC, resulting in an inability to access network resources.

Overall, using Microsoft's own KDC as your network's KDC in conjunction with Linux application servers and clients works well. If you're using older Kerberos implementations, though, you may need to enable DES support and then change users' passwords so that the new password is encoded in DES form. This step shouldn't be necessary with recent Kerberos V5 implementations for Linux, though. (If in doubt, check whether the Kerberos implementation supports the RC4-HMAC encryption algorithm.) For the most part, the details of administering a Windows KDC are beyond the scope of this book.

Using Windows clients with a non-Microsoft KDC is a bit trickier, but it is possible. You must create local Windows accounts on the Windows system for your users and use special tools to configure Windows to use the KDC for authentication. This process is described later in this chapter, in Section 9.5.3. Alternatively, you can install a non-Microsoft Kerberos package and run it without using Kerberos for logon authentication. Instead, you'd use regular Kerberized clients and servers under Windows, much as you would their equivalents under Linux.