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.
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.
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:
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 fluffy@EXAMPLE.COM: $ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: fluffy@EXAMPLE.COM Valid starting Expires Service principal 06/23/04 19:24:42 06/24/04 19:24:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt500 klist: You have no tickets cached $ kpasswd Password for fluffy@EXAMPLE.COM: 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 ``fluffy@EXAMPLE.COM'' ] 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: fluffy@EXAMPLE.COM Valid starting Expires Service principal 06/23/04 19:24:42 06/24/04 19:24:39 krbtgt/EXAMPLE.COM@EXAMPLE.COM 06/23/04 19:26:16 06/24/04 19:24:39 host/mandragora.example.com@EXAMPLE.COM 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/EXAMPLE.COM@EXAMPLE.COM, 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/mandragora.example.com@EXAMPLE.COM, 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.
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.
188.8.131.52 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
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.
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.
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.
184.108.40.206 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.
220.127.116.11 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:
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.