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:
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.
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.
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.)
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:
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.
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:
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.