Section 9.4. Linux Kerberos Client Configuration

9.4. Linux Kerberos Client Configuration

Kerberized clients are simpler to configure than KDCs or Kerberized application servers. Nonetheless, these tools do require some basic configuration to work. You may even need to track down Kerberized versions of clients for specific protocols, particularly if you want to use tools that aren't provided with Kerberos. Once everything's set up, you should know something about the basic Kerberos user management tools, because they control user access to the realm.

9.4.1. Preparing Kerberos Clients

The main requirement for Kerberos client configuration is to set up the Kerberos configuration file, krb5.conf, as described earlier. Note that there's no need for a [logging] or [kdc] section, and, consequently, no need for a kdc.conf fileeven if you're using MIT Kerberos.

You can mix and match an MIT Kerberos KDC with Heimdal clients, or a Heimdal KDC with MIT Kerberos clients. As described in the section Section 9.5, still other Kerberos implementations can interact with these common Linux Kerberos tools.

Because the Kerberos clients don't maintain Kerberos databases, you don't need to use kadmin or kadmin.local to set up local Kerberos databases on the clients. You do, though, need to create principals for your users, as described earlier in this chapter.

9.4.2. Installing Kerberized Clients

Kerberized clients can be classified in two categories: those that ship with the main Kerberos package and third-party tools. The "official" Kerberized clients are those that match the "official" Kerberized servers, as described earlier in Section 9.3.3. If you install Kerberos from source code, these clients install with the main Kerberos package, so the easiest way to install them is to compile the whole Kerberos package. Some Linux distributions, though, split the Kerberos clients into a separate package, such as Fedora's krb5-workstation. (Such tools may depend on others, such as Fedora's krb5-libs.) Other distributions place everything in one huge package.

If you want to use additional protocols, such as POP or IMAP, you need to track down Kerberized clientsin the case of POP or IMAP, this is a Kerberized mail reader, such as Pine (http://www.washington.edu/pine/). As with matching Kerberized servers, tracking these down can be tricky. A web search on appropriate terms, such as Kerberos IMAP, may help.

Many clients and servers provide Kerberos support as a compile-time option. If you can't seem to get Kerberos support working, particularly if you're using precompiled binaries and the documentation says that the client supports Kerberos, you can try recompiling the program locally. This may require that you install a Kerberos development package, though.

9.4.3. Using Kerberized Clients

Kerberos is a network login protocol, but Linux Kerberos packages don't automatically enable Kerberized authentication for desktop logins. (This option is described in the next section.) Instead, you can manage a Kerberos session after you've logged into your normal Linux (or other OS) session. Once you've done this, you can use the following four Kerberos client tools to manage your Kerberos session:

kinit

This program initializes a Kerberos session. More precisely, it obtains a TGT from the KDC. Once you've acquired a TGT, the Kerberos utilities can easilyand transparentlyobtain tickets to specific servers. Thus, kinit manages the "single sign-on" feature of Kerberos. To use the tool, type its name; it will ask you for a password, using your Linux username as the primary of the principal and the default realm defined in krb5.conf. You can obtain a TGT for another principal by passing its name to kinit, as in kinit linnaeus/[e-mail]. This is handy if you have multiple principals, such as one for regular use and another for administrative functions.

klist

This program displays information on your current tickets, including the TGT. If you can't seem to log in using a Kerberos client, using klist can be a good starting point. You might discover that you're missing a necessary ticket.

kpasswd

This command is the Kerberos equivalent of the Linux passwd command; it changes your Kerberos realm password. You must have a TGT to use it.

kdestroy

This command destroys all your tickets. In theory, you should run this command just before logging out of the computer from which you're managing your Kerberos session. If you fail to do so, the tickets might remain in memory and could, in theory, be misappropriated by somebody with sufficient privilege. Some session management tools destroy tickets automatically, though, so this may not be necessary. You can also use this tool to destroy tickets you no longer need, which enables you to authenticate using a "clean slate" for testing purposes.

Of these commands, only kinit is necessary for using Kerberos as a client, and it can be replaced by other tools, as described later. To illustrate the use of these tools, though, consider the following sequence of commands:

$ kinit Password for [e-mail]: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [e-mail] Valid starting     Expires            Service principal 06/23/04 19:24:42  06/24/04 19:24:39  krbtgt/[e-mail] Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached $ kpasswd Password for [e-mail]: Enter new password: : Enter it again: : Password changed. $ /usr/lib/heimdal/bin/telnet -af mandragora Trying 192.168.1.3... Connected to mandragora (192.168.1.3). Escape character is '^]'. [ Kerberos V5 accepts you as ``[e-mail]'' ] Last login: Wed Jun 23 19:24:25 from halrloprillalar fluffly@mandragora> logout Connection closed by foreign host. $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [e-mail] Valid starting     Expires            Service principal 06/23/04 19:24:42  06/24/04 19:24:39  krbtgt/[e-mail] 06/23/04 19:26:16  06/24/04 19:24:39  host/[e-mail] Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached $ kdestroy $ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500) Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached

This example begins with a call to kinit, which obtains the initial TGT (krbtgt/[e-mail], as revealed by the first call to klist). The call to klist also displays the TGT's starting and ending timesone day apart in this example. The call to kpasswd results in a password-change exchange much like the one that results from the standard Linux passwd command.

The Kerberized telnet command works much like the stock telnet, but passing the -a and -f parameters are necessary to have the client attempt an automatic login and forward its credentials to the server, respectively. Without these options, you'll be prompted for your username and password. Note also that this example includes the complete path to the Kerberized binary. Depending on your PATH environment variable and where your Kerberized and normal telnet binaries are located, this may or may not be necessary to ensure use of the Kerberized tool. After logging out of the remote system, a second call to klist reveals that the system is still holding onto the TGT but has acquired a new ticket, host/[e-mail], which corresponds to the server system to which you've connected. After using the kdestroy command, klist reveals that no tickets are present. At this point, an attempt to use Kerberized clients will either fail or result in a conventional login prompt, or at least a request for a password. If this happens, Kerberos is not being used for authentication.

Of the clients that ship with Kerberos, ftp provides the most verbose information while connecting to the server. This fact can be useful when you're debugging problems.

Many of the stock Kerberos client programs (telnet, rlogin, and so on) require the -a and/or -f options to enable automatic logins using Kerberos credentials. Some packages use a leading k to differentiate the Kerberized programs from their non-Kerberized counterparts, as in ktelnet. You'll need to consult your local documentation and package information to learn the details for your system.

9.4.4. Using Kerberos for Network Logins

One of the limitations of Kerberos, at least as it's delivered in the main Kerberos package, is that it isn't a very good tool for logging into individual desktop systems. To use Kerberos as just described, you must log into your desktop system, including entering a password, and then use kinit to initialize a Kerberos session. Ideally, you should be able to enter your username and password just once, when you log into the computer. This ideal is achievable using any of several tools; however, some of them require additional configuration to use. Even at their best, though, these tools aren't complete replacements for your local Linux accounts; you must still maintain some information locally or via some other tool, such as LDAP.

9.4.4.1 Kerberized login tools

Linux requires authentication for many different tools. In terms of local login, two broad classes of tools are most notable: text-mode login, which is handled by the login program, and GUI login, which is handled by an X Display Manager (XDM) program. In addition to these login tools, though, other local authentication tools exist, such as screen-locking programs, which lock the console after a period of activity, much like screen savers, but require a password to unlock the screen.

The stock Heimdal and MIT Kerberos packages ship with a replacement for the standard login tool. This replacement is called login in Heimdal and login.krb5 in MIT Kerberos. It's installed in an out-of-the-way directory or under an unusual name to prevent interference with the standard login program. To use the new tool, you must copy it over the original, which is typically located in /bin, but I recommend you first back up the original in case you run into problems:

# mv /bin/login /bin/login-original # cp /usr/sbin/login.krb5 /bin/login

Adjusting your system's login tools is potentially risky. You should ensure that you have some alternate way to log in that doesn't use login (such as via an XDM program or an SSH session) when adjusting login. You may also want to leave a root login running in one virtual terminal while you make changes.

Once you make this change, your system should begin using Kerberos for all text-mode console logins, with the caveat that any currently running login processes may need to be restarted first. (Typically, logging in and then logging out should do the job.) The login program is used by some other tools, too, such as non-Kerberized Telnet servers. Using a Kerberized login program, though, doesn't provide you with any extra security; the client still sends the username and password to the server unencrypted, and the resulting session will also be unencrypted.

One good way to test whether you're using the Kerberized login tool is to use klist. If you destroy your tickets, log out, log in, and then find you have a new TGT after logging in, you can be sure you're using the Kerberized login.

After making these changes, you should test all your user accounts, or at least all of those you can test. Be sure to test your root account, too, and if it doesn't work, create an appropriate Kerberos principal for root.

Using PAM for Kerberized logins, as described next, enables you to use a local root account along with Kerberos for other users. This can make the PAM solution a bit safer because you won't be denied root access if a Kerberos problem develops. This solution also lets you set different root passwords for each computer.

Unfortunately, the standard Kerberos packages don't ship with an equivalent to the Kerberized login for GUI logins. To implement Kerberized GUI logins, you must either track down a Kerberized XDM (they're rare) or implement Kerberos via PAM. The latter is a more flexible approach, and it can also be used in place of the explicitly Kerberized login program, but PAM takes more effort to set up.

9.4.4.2 Kerberos and PAM

Several third-party Kerberos PAM modules exist, but the most popular is the pam_krb5 package, which is available under that name with most distributions. (Debian calls its version libpam-krb5, though.) Its main web site is http://sourceforge.net/projects/pam-krb5/, should you need to install it from source code.

The Kerberos PAM package installs very few files; aside from documentation files, the only important file is /lib/security/pam_krb5.so. Some versions also install a variant known as pam_krb5afs.so, which also supports logins via Andrew File System (AFS) authentication.

You can configure the Kerberos PAM modules by adding references to pam_krb5.so for the auth and account items in the files in /etc/pam.d corresponding to the services you want to use Kerberos authentication. This topic is described in more detail in Appendix A, so consult it for details.

The primary advantage of using PAM for local Kerberos authentication is that you can use Kerberos for just about any service that requires authentication. The list of likely services includes login, XDM (or its GNOME or KDE variants, GDM or KDM), su, sudo, passwd, vlock (a text-mode, console-locking program), xlock (an X-based console-locking program), and xscreensaver (another X-based, console locking program). Using the Kerberized PAM modules for these services (and particularly for the login and XDM, GDM, or XDM services) means that users will have TGTs the moment they log in; they won't need to use kinit to obtain them.

In theory, you can use the Kerberized PAM module to support network-accessible login servers, such as POP, IMAP, FTP, and SSH. In practice, though, the advantages to doing so are slim, because the communication between the client and server is still done in whatever way it would be done if you used the normal PAM configuration. In particular, a protocol that delivers the password in unencrypted form will continue to do so. If possible, you should instead replace the client and server programs with explicitly Kerberized versions. This configuration bypasses PAM and uses Kerberos directly, giving you more Kerberos benefits. Alternatively, you can set up an encrypted tunnel to encrypt all data, including passwords. This protects your passwords and enables you to use the Kerberos database, but won't extend the single-sign-on advantages of Kerberos to non-Kerberized clients.

9.4.4.3 Kerberized account maintenance

If you've read Chapters Chapter 7 or Chapter 8, you may have noticed an omission in the preceding description of Kerberos and PAM: no mention has been made of the Name Service Switch. This Linux component provides account information, such as UID-to-username mapping, to programs that need it. Unfortunately, no Kerberos NSS modules are available, which means that you can't rely on Kerberos to maintain the sort of information NSS normally handles. The practical upshot of this limitation is that you must either maintain local accounts (in /etc/passwd) for your Kerberos-authenticated users, or you must rely on another tool (such as LDAP) to handle this job.

This limitation can be a serious one for many potential uses of Kerberos; if you want to maintain full user account information in a central database, so that you needn't modify desktop systems' configurations when adding or deleting users on your network, Kerberos by itself isn't a complete solution, at least not when you're using Linux desktop systems. Some possible solutions to this problem include:

• You can maintain a central Kerberos database and deal with conventional Linux /etc/passwd files manually. This approach may be acceptable if users seldom or never use anything but their own desktop systems; you need to update only a user's own desktop system and the Kerberized servers when adding or deleting network users. For instance, when adding the user bbode, you don't need to modify fluffy's desktop system.

• You can abandon Kerberos entirely, at least as a login tool, and switch to another protocol, or relegate Kerberos to secondary duty (say, for use by just a few users). You can still use Kerberos as a tool for managing server accesses subsequent to desktop logins, but the servers will still need local accounts to match the Kerberos principals.

• You can use another protocol, such as LDAP, as a supplement to Kerberos. You'd use Kerberos for authentication via PAM but configure NSS to use the other protocol. This approach can be an effective one and can be a useful way to take advantage of Kerberos's single-sign-on capabilities while minimizing account maintenance. Unfortunately, configuring both systems is likely to be tedious in the short term, and this approach also seems to require that you maintain two account databases, at least at first glanceone for Kerberos and one for the secondary system. In practice, you can link LDAP and Kerberos more tightly (much as AD under Windows does), but this topic is well beyond the scope of this chapter.

If your network hosts a Windows 200x AD controller, you can use it as the KDC and configure Linux systems as Kerberos application servers. If you also configure Winbind's NSS features and use the AD controller as a domain controller, as described in Chapter 7, the Linux system will maintain Linux user accounts automatically.

Ultimately, you'll have to decide for yourself just how to balance your priorities: Kerberos's unique features, such as single-sign-on, versus simplified local account information. If the former isn't very important but the latter is, LDAP or NT domains will probably be a better solution than Kerberos; if the former is very important, Kerberos is the better tool in addition to or instead of another one.