Configuring a Kerberos Client

The first step to using Kerberos as a user is to create a Kerberos principal for that user. This process was described earlier, in the section "Creating Principals." User principals usually take the form username @ REALM. NAME , and they're created using the kadmin or kadmin.local utilities. Once you've created a user principal, the user may access Kerberos servers using matched Kerberos-enabled clients. This means you must install these clients and make them accessible to users. You can install clients by installing the entire Kerberos package, or sometimes just by installing a Kerberos base or library package along with a Kerberos workstation or clients package. Users may also need to use some Kerberos housekeeping utilities to obtain and manage TGTs. If you want to use Kerberos to control user logins to individual workstations, you need to modify the usual login authentication tools on the workstations.

Accessing Kerberos Servers

In broad strokes, users may access Kerberos application servers by running an appropriate client program. Unfortunately, the reality is a bit more complex than this simple explanation implies. For one thing, there are several user-level utilities that come into play ”users must have some way to obtain a TGT, and must be able to perform routine maintenance such as changing their Kerberos passwords. Second, the Kerberized clients themselves sometimes pose unique challenges. For instance, many require options to enable critical Kerberos features; without these options, the Kerberized clients may behave like ordinary non-Kerberized clients.

Using Kerberos Network Utilities

The Kerberos package includes a number of utilities that manage Kerberos passwords and tickets, including the all-important ticket-granting ticket (TGT). The most important of these tools are the following:

• kinit ” This program obtains a TGT. You can think of it as a program that "logs you into" a Kerberos realm; before running kinit (or using equivalent functionality, as described in the upcoming section, "Using Kerberos for User Logins"), you can't use any Kerberos client. When you run kinit , the program contacts the KDC to obtain a TGT. Thereafter, Kerberized applications use the TGT to obtain authorization to use Kerberos application servers, as described earlier in this chapter. When you run kinit , you'll be asked for a password. By default, kinit uses your username as the primary of the principal, in the default realm. You can override this behavior by appending the principal name to the command, as in kinit [e-mail] . The program also accepts several other options that modify its behavior. Consult the kinit man page for details.

• klist ” This program lists the tickets (including the TGT) that you currently have, including some information such as their expiration dates. Before running kinit , klist will show no tickets.

• kpasswd ” This program doesn't help manage a single Kerberos session; instead, it's used to change the password for a principal in the Kerberos database. It's the Kerberos equivalent of passwd , and works in much the same way. You must have a TGT to use kpasswd .

• kdestroy ” This program destroys all the tickets in a given user's ticket cache. You'd normally run this program just prior to logging off the computer, or when you know you won't be using Kerberized servers in the near future. Although Kerberos tickets expire if unused for a while, it's best to destroy them after they've served their purpose, since this reduces the risk that they might be abused in the event of a security breach.

TIP

You might want to add a call to kdestroy to all users' .logout files, to the ends of their .xinitrc files, or to other standard files such that the program will run when the user logs out. If you use a Kerberos PAM module, as described later in this chapter, this functionality may be handled automatically.

How do these tools work, in practice? Most sessions will use just the kinit and kdestroy programs at the beginning and end of the session, respectively. You can use the klist utility to see what happens with tickets, though. For instance, consider the following exchange:

 $  kinit  Password for [e-mail]: $  klist  Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [e-mail] Valid starting     Expires            Service principal 10/09/02 14:38:57  10/10/02 00:38:57  krbtgt/THREEROOMCO.COM@\                                              THREEROOMCO.COM 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. $  kdestroy  $  klist  klist: No credentials cache file found (ticket cache FILE:/tmp/krb5cc_500) Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached 

The initial kinit command retrieved the TGT, which appears as the krbtgt service in the subsequent call to klist . As you can see from the start and expiration times, this ticket is good for ten hours (a figure that can be adjusted on a system-by-system basis). If a Kerberized client were used and klist run again, another ticket would appear for that service. Changing a password with kpasswd requires entering the original password as a precaution, then entering the new password twice. As with the password entry with kinit , none of the passwords echo to the screen. After running kdestroy , all the tickets are cleared.

Using Kerberized Clients

Kerberos client programs work much like their conventional equivalents. In most cases, you type the program name followed by the name of the server to which you want to connect. Unfortunately, many require additional parameters to take full advantage of the features of Kerberos. For instance, the telnet client requires extra parameters to obviate the need to enter a username and password when you log in. Examples of Kerberized clients, and some of their quirks , include the following:

• telnet ” The telnet program included with Kerberos works much like the standard telnet program if run without extra options. Thus, if you just type telnet remote.host , you'll have to type your username and password again. To get the benefit of Kerberos's one-login system, you must include the -a (automatic logon) and -f (forward tickets) options.

• rlogin ” The standard rlogin program is often used in a relatively insecure way, as described in Chapter 13. You can use the -f option to the Kerberized version of the program to add Kerberos authentication. The result is very similar to using the Kerberized telnet with -a and -f .

• ftp ” Used without any extra parameters, this program uses Kerberos authentication, although you must still verify your username (the program presents a default, to which you can probably press the Enter key).

TIP

The Kerberos ftp package presents somewhat more verbose information during the initial connection phase than do some Kerberos clients. If you're having problems with a Kerberos configuration, this additional information may be useful in debugging the problems.

• rsh ” This program is used to run a text-mode program on another computer without logging into it with telnet , rlogin , or the like. As with other Kerberized tools included with Kerberos, this version includes extra options, such as -f .

• rcp ” The standard rcp program is a simple file-transfer program, to which the Kerberized version adds the usual Kerberos authentication features.

• Other programs ” The preceding list covers only those network tools that ship with a standard Kerberos V5 package. Many other tools come standard with Kerberos support, provide Kerberos support as a compile-time option, or are available in Kerberized variants. Of course, you need both Kerberized clients and servers to use such tools.

The man pages for the Kerberized client programs provide additional details, including information on more options to set the login realm, principal, and other features of use. If you use a Kerberized tool that doesn't ship with the standard Kerberos distribution, be sure to check its options. Some provide only minimal Kerberos functionality (for instance, authentication but not encryption), but others are more full featured. One feature that's particularly noteworthy and is supported by all the standard Kerberos clients is data encryption. If you add the -x option to any of these tools' command lines, they'll encrypt all data they transfer. This feature can be extremely useful, particularly if you're connecting over the Internet or are transferring data that's potentially sensitive even for internal purposes. For instance, if you intend to log on to a computer with telnet and then use su to administer it, you may want to use encryption to protect the root password. (The ksu command, described in the upcoming section "Changing Your Account After Logging In," can also help in this respect, but only if you configure the root account to accept password-less access from your regular account.)

The standard Kerberos source code package places Kerberos user programs in /usr/local/bin by default (administrative tools go in /usr/local/sbin ). Some binary Kerberos packages may use other locations; for instance, Red Hat's Kerberos builds place user programs in /usr/kerberos/bin . Chances are you want to use the Kerberized tools instead of the standard tools. To do so, you should ensure that the Kerberized tools directory appears before the standard tools directory in users' paths (set in the PATH environment variable, usually in /etc/profile or users' .bashrc files, at least for Bash users).

Using Kerberos for User Logins

The preceding discussion of managing a Kerberos session assumes that users have already logged into the computer. Doing so, however, reduces the appeal of Kerberos, because it means users must essentially log in twice: Once to gain access to the workstation, and again (using kinit ) to use Kerberized servers. The solution is to use a tool that takes over both tasks . There are various tools that accomplish this goal. Kerberos ships with two, login.krb5 and ksu , that can help with certain text-mode tasks. Another approach is to modify Linux's underlying authentication library to rely upon Kerberos. This approach is more difficult to set up, but is also much more flexible.

WARNING

Before trying to use login.krb5 , I recommend that you first test the kinit program for important accounts, including your root account. If kinit doesn't work, it's very likely that login.krb5 won't either, which means you won't be able to log into the console in text mode. You should also keep a root shell open in one virtual terminal, so that you can change your configuration if you encounter a problem with login.krb5 . Similar cautions apply to changing other login tools.

Performing Text-Mode Kerberos Login Authentication

The normal text-mode login procedure for a Linux system involves the use of a program that's known generically as a getty . There are several getty programs, ranging from the original getty to variants such as mingetty , mgetty , and vgetty . These programs are run from /etc/inittab , and they take control of a console, serial port, or the like, and pass control to another program, /bin/login . Some network login protocols, such as Telnet, also call /bin/login . As you might guess by the name, login.krb5 is intended as a replacement for /bin/login . To use the Kerberized tool, you should replace /bin/login with the new tool. I recommend first backing up the original program. For instance, you might issue the following commands:

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

This action ensures that you'll be able to recover the original /bin/login program if something goes wrong. After you've replaced this program, subsequent logins will use Kerberos for the initial login. This includes obtaining a TGT, so there's no need to run kinit after such a login. Indeed, once so configured, a computer will use only the Kerberos authentication for logins mediated by /bin/login , although the user must still have an entry in the local /etc/passwd file, a home directory, and any other required local resources to successfully use the computer. In addition, there are other methods of logging in that you may need to adjust, such as GUI logins or logins through servers that don't rely upon /bin/login , such as SSH.

Changing Your Account After Logging In

One additional authentication tool, which is not quite the usual type of logging in, is using su to acquire another user's identity. Kerberos includes an alternative package, ksu , to permit changes in the current user account. This program has certain prerequisites:

• The computer on which you run ksu must have a host key (typically stored in /etc/krb5.keytab , and described earlier in this chapter).

• The ksu binary must be installed SUID root if anybody but root is to use the program. Most Kerberos packages do not install ksu SUID root , so you must do this yourself (say, by typing chmod a+s /usr/ kerberos/bin/ksu ).

• For best security, the user whose identity you wish to acquire must have a configuration file authorizing others to gain the specified access. The .k5login or .k5users file provides this authorization, as described shortly.

To provide authorization to an account, the target user may create an authorization file. Without this file, another user may still access the account, but ksu asks for a password, which may be passed in cleartext over the network if the user is logged in using an insecure protocol such as Telnet. The .k5login file grants another user full login privileges, and is simplest to use. This file consists of a series of lines, each of which is a Kerberos principal. The .k5users file grants users limited access to the account by specifying a list of programs that the user may run; each line begins with a Kerberos principal, and is followed by specific program names separated by spaces. An asterisk ( * ) is a wildcard for any command. For instance, the following entry grants [e-mail] the right to run the /bin/ls and /usr/bin/zip programs:

 [e-mail] /bin/ls /usr/bin/zip 

Once configured, the ksu program works much like su ”you type the program name followed by the name of the user whose privileges you want to acquire. If you haven't configured a .k5login or .k5users file, you must then enter the password for that principal. If you've created an appropriate authorization file, though, you won't need to enter any password. This approach is also more secure if you're using any unencrypted connection.

If you want to directly run a single program, you may do so by specifying the -e progname parameter, where progname is the name of the program. For instance, ksu fluffy -e /bin/ls runs /bin/ls as fluffy .

Using PAM with Kerberos

The replacement login and su programs included with Kerberos can be very useful, but they don't go far enough for many situations. Of particular interest is the need for a way to control GUI logins for workstations that should be authenticated through Kerberos. There are numerous other local authentication tools you may want to link to Kerberos as well, such as vlock or xscreensaver (which lock text-mode and GUI sessions, respectively, until a user enters a password). There is a general-purpose way to add Kerberos support to many such programs, but the necessary tools aren't as widely available as are the tools that ship with Kerberos. This method relies on Linux's support for the Pluggable Authentication Module (PAM) tools.

PAM is intended as an intermediary between programs that require authentication (such as FTP servers, login , and X-based login tools) and the underlying user and password databases (which reside in /etc/passwd , /etc/shadow , and similar files in a standard Linux installation). The idea behind PAM is that by abstracting authentication procedures into a library, the underlying authentication files can be easily changed without altering the numerous programs that rely upon them; only PAM must be modified to understand the new file formats. In this respect, implementing Kerberos support in PAM is the ideal way to provide Kerberos support for numerous applications ”if you make these changes, the programs that use PAM need no changes to support Kerberos.

NOTE

The Kerberos support provided through PAM is limited in certain ways. In particular, if a program is hard-coded to request a username and password, these prompts will not change if you alter PAM to use Kerberos. The program will send the username and password to PAM for authentication, and PAM will try to authenticate them against the Kerberos database. Thus, if your FTP server, for instance, uses PAM, Kerberizing PAM won't eliminate the need to enter a username and password. It might allow you to keep your FTP passwords up to date with your Kerberos realm, though. This isn't a drawback when it comes to a Kerberized login program, which should always request a username and password.

Unfortunately, although PAM is a common authentication tool among Linux distributions and many non-Linux systems, Kerberized versions of PAM aren't as common as is the main Kerberos distribution. A few possible sources include the following:

• Derrik Brashier's module ” This is a module for use with Kerberos V4. It's available from ftp://ftp.dementia.org/pub/pam/ under various filenames beginning pam_krb4 ; choose the one with the most recent date (all were in 1998 when I wrote this). This package ships in source code form, so you'll have to compile it to use it.

• Frank Cusack's module ” One PAM module that supports MIT Kerberos V5 and Heimdal is available from http://www.nectar.com/zope/krb/. (The version on this page is currently being maintained by Jacques Vidrine and others.) This package is available in source code only and was originally written for Solaris, but it does compile and work under Linux.

• Curtis King's module ” Curtis King has made another Kerberos V5 PAM module available. It can be obtained from ftp.dementia.org/pub/pam/ under the filename pam_krb5-1.1.3.tar.gz . It also requires compilation, which may not go smoothly.

• Red Hat's module ” Red Hat has made a Kerberos V5 PAM module available as part of its distribution, under the package name pam_krb5 . This is probably the easiest to install on Red Hat and similar distributions, because it comes precompiled and is distributed in RPM format. I use this package as the basis for the following discussion, but Frank Cusack's module works in much the same way.

• Debian modules ” The libpam-krb5 and libpam-heimdal modules are available for Debian systems, and should be easy to install if you're using Kerberos V5 or Heimdal, respectively, on Debian or related distributions. These packages are difficult to find from a package search on Debian's site, though; look for them at http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-krb5/ and http://ftp.nl.debian.org/debian/pool/non-US/main/libp/libpam-heimdal/.

When you install the Kerberized PAM, what you're installing is a PAM module, which you can configure PAM to use in certain specific cases. The PAM module consists of one or more library files that are stored in /lib/security or /usr/lib/security . In the case of the Red Hat package, the files are called pam_krb5.so and pam_krb5afs.so . To use these libraries, you must alter your PAM configuration files, which are stored in /etc/pam.d . This directory contains several files named after the servers or other programs that require authentication support. For instance, /etc/ pam.d/login controls how the login program interacts with PAM. To use Kerberos with these programs, you must change or add lines to the PAM control files to tell PAM to use its new Kerberos module. In fact, Red Hat's package includes a large number of sample files in /usr/share/doc/ pam_krb5- version /pam.d , where version is the package's version number. To simplify configuration, you can copy the appropriate configuration files to /etc/pam.d . Files you might want to consider copying include the following:

• login ” This controls the login program. If you install Kerberized PAM support, you can forego the official Kerberos login.krb5 program.

• gdm ” The GNOME Display Manager (GDM) is one of three common GUI login tools in Linux. (Consult Chapter 14 for information on how to configure these servers.)

• xdm ” The X Display Manager is another common GUI login tool, and the KDE Display Manager uses XDM's configuration files, as well. In theory, this file should enable these tools to use Kerberos for login authentication, but I've had problems with this configuration on a Mandrake system.

• su and sudo ” The su program, described earlier, lets users change their identity once logged in. The ksu program does the same using Kerberos, but you can achieve similar results by installing the Kerberized PAM control file for su . The sudo control file provides similar Kerberization for the sudo command.

• passwd ” This file tells PAM to send password changes, as handled through the passwd program, to the KDC.

• vlock ” The vlock program locks a console without logging the user out; only after entering a password can the console be used again. As you might expect, this control file causes vlock to use the KDC for authentication.

• xlock and xscreensaver ” These programs both lock an X session, much as does vlock , but xscreensaver can do so automatically after a period of user inactivity.

Naturally, there are other programs whose PAM control files you might want to modify to add Kerberos support. The details depend on your system. Note that you don't need to modify the PAM files for services you're explicitly Kerberizing. For instance, if you install a Kerberos-enabled FTP server, you don't need to modify the /etc/pam.d/ftp file. Explicitly Kerberized applications can communicate with the KDC for authentication, bypassing PAM and the need to explicitly enter a username and password that PAM requires.

If you need to modify a PAM-using program to use Kerberos, you must add or replace certain lines in the PAM configuration file. These files specify four authentication services: auth (authenticating a user), account (checking that an account is valid), password (changing a password), and session (setting up and terminating sessions). A PAM configuration file consists of one or more lines for one or more of these services, describing what PAM modules are to be involved in the process. For instance, Listing 6.4 shows the gdm file from Red Hat's Kerberos PAM package.

NOTE

Different distributions often use substantially different PAM configurations, so yours may call different PAM modules than those shown in Listing 6.4. In most cases, adding the pam_krb5.so module, and possibly deleting a reference to another module, is all you need to do to use a Kerberized PAM.

Listing 6.4 A Sample PAM Configuration File with Kerberos Support

 #%PAM-1.0 auth       required    /lib/security/pam_nologin.so auth       sufficient  /lib/security/pam_unix.so shadow md5 \ nullok likeauth auth       required    /lib/security/pam_krb5.so use_first_pass account    required    /lib/security/pam_unix.so password   required    /lib/security/pam_cracklib.so password   required    /lib/security/pam_unix.so shadow md5 \ nullok use_authtok session    required    /lib/security/pam_unix.so session    optional    /lib/security/pam_krb5.so session    optional    /lib/security/pam_console.so 

In this case, the important lines are the final auth and the second session lines, which tell PAM to use Kerberos for login and logout, respectively. The auth line includes the use_first_pass argument, which tells the Kerberos PAM module that it's collecting the first password for a session. This causes the module to behave like kinit , acquiring and storing a TGT. Most Kerberos PAM modules can be configured in much this way, but some may need something else. For instance, the password configuration file requires the addition of a line like the following after the existing password entries:

 password   required      /lib/security/pam_krb5.so use_authtok 

This is the case because the password module is used by the passwd program, which changes passwords rather than authenticate users. Some files shouldn't have a session line, because this line causes authentication tickets to be destroyed . For instance, the xscreensaver and linuxconf modules shouldn't destroy tickets because when these programs exit, you're returned to a working login configuration in which the tickets you've previously obtained should remain valid.

In some cases, you may need to remove existing entries from the /etc/pam.d configuration files. Specifically, if you add a pam_krb5.so entry for a service for which there is also a reference to the pam_pwdb.so library, you should remove the latter line. The pam_pwdb.so library directly accesses the password database, and if both references are present, the local password database and the Kerberos database must both authenticate the password. Although this may be desirable in some very high-security situations, it limits the flexibility of Kerberos, since users must ensure they change their passwords on the KDC and on their local workstations simultaneously . If the PAM password configuration file includes a matching duplication, this is easily done with the passwd tool for a single workstation, but coordinating such changes across an entire network will be tedious at best.

After you've made changes to your PAM configuration, those changes should be immediately available; there's no PAM daemon to restart. If a configuration affects a server or program that's already running, though, you may need to restart it before it will use the new configuration. In the case of login , the new configuration should take effect after you log out of the console. For a GUI login tool like GDM, you may need to restart the server.