7.7 Kerberos-Enabled Server Packages

While PAM is a great solution for local login on the system console, the real advantages to using Kerberos are only realized if client/server applications that users interact with are configured for native Kerberos support.

Our users now have Kerberos tickets upon login. The next step is to start adding Kerberos support to the application servers that users access. We want users to enjoy the benefits of a fully-Kerberized environment as much as possible, so I'll focus on enabling native Kerberos support in as many packages that support it, but fall back to the single-login capability provided by other packages that do not have built-in Kerberos support.

We already saw an example of a network protocol with native Kerberos support back in Chapter 4, when we configured the Kerberos telnet server to test our new Kerberos implementation. We're going to take that a step further in this section and examine how to add Kerberos support to other popular network protocols.

7.7.1 Electronic Mail (Cyrus IMAP)

Cyrus IMAP is a part of Project Cyrus, a project developed at Carnegie Mellon University to provide a reliable, scalable electronic mail system for the campus. The Cyrus mail server had, in its original design goals from 1994, many of the same goals of administrators today: the mail service had to scale to thousands of simultaneous readers, it had to support many different clients on different hardware and operating-system platforms, and it had to integrate with the campus-wide authentication system, which happens to be based on Kerberos. Today, Cyrus supports the two major mail access protocols: the Internet Mail Access Protocol (IMAP) and Post Office Protocol (POP). A separate program, a Mail Transfer Agent, handles the task of transferring mail from system to system through the Simple Mail Transfer Protocol (SMTP). Newer mail clients support SMTP authentication, and we'll discuss Kerberos support for MTAs in the next section.

Cyrus IMAP is available from Carnegie Mellon at http://asg.web.cmu.edu/cyrus/imapd, and the latest stable version available at the time of this writing is 2.1.12. Cyrus IMAP uses the Cyrus SASL library to handle authentication and session encryption tasks. Therefore, before building Cyrus IMAP, you'll need a working installation of Cyrus SASL.

7.7.1.1 Building and configuring the distribution

Cyrus IMAP is a complex package and most of the build and configuration options relate to how it handles mail, and not its authentication mechanism. Therefore, we're going to focus on the particular options necessary to enable GSSAPI support in Cyrus IMAP.

After acquiring the source distribution, untar it and the following configure line will configure Cyrus IMAP for GSSAPI and SASL support:

% ./configure --enable-gssapi=/usr/local --with-sasl=/usr/local

Once the configure step completes, Cyrus IMAP is ready to compile and install:

# make && make install

Once Cyrus has been installed, it can be configured to work with SASL to provide GSSAPI authentication to clients. The necessary SASL configuration information can be embedded into the imapd.conf file; insert sasl_ before every SASL-related configuration directive in imapd.conf. For example:

sasl_pwcheck_method: saslauthd
sasl_mech_list: gssapi plain pam

You'll also need to create a keytab entry for the Cyrus IMAP server, in the form of imap/hostname@REALM and securely copy it into the IMAP server's filesystem. The keytab should be readable by only the username that Cyrus IMAP runs as (a special user should be created for this purpose, as part of the installation process).

Once the configuration is in place, the Cyrus IMAP daemons can be started with the following command, assuming that the distribution has been installed into the default directory of /usr/cyrus:

# /usr/cyrus/bin/master &

At least with the currently available Cyrus IMAP and SASL distribution, specifying the keytab SASL parameter in the /etc/imapd.conf file does not successfully set the keytab for Cyrus IMAP. If you are using a keytab other than the system keytab (which is highly recommended, as the system keytab is readable only by root and Cyrus IMAP runs as a special non-root user), then set the KRB5_KTNAME environment variable to the full path of Cyrus IMAP's keytab before starting Cyrus IMAP. For example (assuming a Bourne shell): # KRB5_KTNAME=/etc/cyrus.keytab # /usr/cyrus/bin/master &

Obviously, details on configuring the mail-handling parameters in Cyrus IMAP is beyond the scope of this book. For further information on configuring Cyrus IMAP, see the documentation included with the distribution.

7.7.1.2 Testing the authentication

Cyrus IMAP also has a testing program that can be used to ensure the proper operation of the SASL libraries for authentication once the mail system is up and running. The imtest program, which is installed as part of the distribution, logs in to the IMAP server and attempts to authenticate using any of the supported SASL mechanisms.

The only argument that imtest requires is the name of the mail server to contact. If the GSSAPI mechanism has been compiled, and enabled in the server-side imapd.conf file, then it should succeed, and a subsequent klist will show that the client has successfully acquired a service ticket. If the authentication fails, check the syslog messages on the server. The most common errors encountered at this stage are related to keytab problems; Cyrus may be looking in the wrong location for the service key, or the permissions may be incorrect on the keytab.

7.7.2 Directory Services (OpenLDAP)

OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol, and is available at its home page at http://www.openldap.org. A directory contains information about an organization's resources, typically personnel, but can also contain information about other resources, such as computers, and printers as well. LDAP is extensible through its support for attributes that can hold arbitrary data, such as names, phone numbers, addresses, and photos. Those who are interested in learning more about LDAP and OpenLDAP can refer to LDAP System Administration by Gerald Carter (O'Reilly).

To restrict access to this information and to control who can modify the directory, LDAP servers require authentication. OpenLDAP uses the Cyrus SASL library to provide this authentication service. Therefore, before installing OpenLDAP, you will need a working Cyrus SASL installation.

7.7.2.1 Building, configuring, and testing the distribution

OpenLDAP is a complex package and most of the configuration options are beyond the scope of this book, as they relate to the LDAP functionality rather than the supported authentication methods. The options required to configure OpenLDAP with Kerberos and SASL support are:

./configure --with-spasswd --with-cyrus-sasl --with-kerberos

More configuration options will probably be required to define the backend database to be used for the LDAP data.

The OpenLDAP server needs a ldap service principal (ldap/hostname.domainname@REALM) created in the Kerberos database. This principal should be created and placed in a keytab that can be read by the OpenLDAP server, slurpd.

The ldapsearch command can be used to test the Kerberos authentication. When run, it should output the name of the Kerberos principal that you are authenticated as:

% ldapsearch
SASL/GSSAPI authentication started
SASL username: jgarman@WEDGIE.ORG
SASL SSF: 56
SASL installing layers

7.7.3 Remote Login (OpenSSH)

OpenSSH is a popular choice for secure, remote access to Unix hosts. The Secure Shell protocol provides secure authentication and session encryption services for remote login. These are the same services that a Kerberized telnet or rlogin provides, but Secure Shell doesn't require a centralized infrastructure, like Kerberos; it only requires users to use one program (the Secure Shell client) to access a SSH server, and finally only communicates on one network port (as opposed to Kerberos, which requires a client to have direct access to both the Kerberos KDC and application server). Therefore, Secure Shell is a popular option for remote access to servers due to its simplicity in operation and small network footprint; its popularity has spawned many interoperable implementations of the protocol for most platforms available today.

OpenSSH is one of these implementations, an open source implementation developed by the OpenBSD group based upon the last unencumbered source code release of the original Secure Shell code.

Secure Shell uses public key encryption methods to perform mutual authentication and negotiation of a symmetric key for session encryption. Since Secure Shell does not require use of a centralized authentication source or signed public keys, it is inherently subject to man-in-the-middle attacks (hence the warnings when connecting to a server for the first time, or when the server's key changes).

Now, with all of that said, how can we use Kerberos with Secure Shell, considering that there is some overlap of functionality between the two? The answer is that Kerberos can be used for the authentication tasks Secure Shell performs, while Secure Shell provides the session encryption functionality. Therefore, the Kerberos single-sign-on authentication framework can be used for Secure Shell connections as well. Furthermore, a Kerberized Secure Shell server can interoperate with non-Kerberized Secure Shell clients if necessary.

This latter scenario is useful in the example of a Kerberized network located behind a firewall. Remote access to the network can be granted with the same Kerberos username/password pair to remote clients, without requiring clients to install the entire Kerberos distribution on their local systems, by using the Secure Shell password authentication method.

OpenSSH is available from its home page, http://www.openssh.com. OpenSSH is available in two versions: the OpenBSD-specific version that is shipped with OpenBSD and the "portable" version that includes support for many popular operating systems. Of course, unless you are running OpenBSD, you'll want to download the latest portable distribution. OpenSSH does ship with Kerberos support included (but not enabled) by default, but it is not sufficient for our use. Simon Wilkinson has developed a set of patches that add GSSAPI support to Secure Shell, and these patches are available at http://www.sxw.org.uk/computing/patches/openssh.html. You'll also need a recent version of GNU autoconf; Version 2.52 or greater is required to rebuild the configure script after the GSSAPI patches have been applied. The GSSAPI support also requires that both the server and client be configured for SSH protocol Version 2 support, which is a good idea to require from a security standpoint anyway.

7.7.3.1 Building the distribution

Once you've retrieved both the OpenSSH distribution as well as the GSSAPI patches, the next step is to apply the patches and configure OpenSSH for GSSAPI support. Assuming that you have downloaded the latest OpenSSH (3.5p1) and GSSAPI patches (the patches are for older OpenSSH, 3.4p1) as of this writing, the OpenSSH distribution has been unpacked, and the GSSAPI patch file is located in the same directory as the OpenSSH tar file, the following command will patch OpenSSH:

% cd openssh-3.5p1
% patch -p1 -s < ../openssh-3.4p1-gssapi-20020627.diff
1 out of 1 hunks failed--saving rejects to compat.h.rej

The GSSAPI patches for 3.4p1 apply cleanly to OpenSSH 3.5p1 with one exception: the compat.h file. OpenSSH 3.5 added the SSH_BUG_PROBE flag, which causes the GSSAPI patches to reject the file. To remedy this, search for SSH_BUG_K5USER in compat.h and edit the file so that it looks like the following: #define SSH_BUG_K5USER 0x00400000 #define SSH_BUG_PROBE 0x00800000 #define SSH_OLD_GSSAPI 0x01000000

Once the patch has been applied, autoreconf must be run on the distribution to rebuild the configure script to add the GSSAPI configure option:

% autoreconf

The warnings that autoreconf may produce can be safely ignored.

Now we are ready to run the configure script. For our purposes the only option that we need to pass to the configure script is --with-kerberos5, to compile in GSSAPI support. This configure option takes one argument, the base directory of the Kerberos 5 and GSSAPI includes and library files. If your environment requires other configure options as well, ensure that those options are appended to the configure script:

% ./configure --with-kerberos5=/usr/local

If all goes well, then make and install, and you should have a Kerberized Secure Shell server and client ready for use:

% make && make install

7.7.3.2 Configuring the distribution

Once the OpenSSH distribution has been installed, the GSSAPI patches add a few options to the sshd_config configuration file to control the use of Kerberos authentication. The options in Table 7-3, added to the sshd_config file, are enabled by default.

Table 7-3. sshd_config options

Configuration flag	Description
GssapiAuthentication	Specifies whether to enable GSSAPI authentication, through a successful key exchange (in this case Kerberos ticket exchange) or through password authentication. The default is "yes".
GssapiKeyExchange	Specifies whether to enable GSSAPI authentication through key exchange.
PasswordAuthentication	Specifies whether to enable password-based authentication. If PasswordAuthentication is set to "yes", sshd will authenticate passwords against the Kerberos KDC regardless of the value of GssapiAuthentication.
Protocol	We highly recommend only allowing connections with protocol Version 2 clients. The Secure Shell protocol Version 1 had several vulnerabilities; besides, the GSSAPI patches only function on Version 2.

In addition, the host will need to have a host key in its system keytab. Ensure that a host principal has been created and the keytab for that principal exists in the system keytab. Since all of the GSSAPI-related options default to "on" in the OpenSSH configuration file, the Kerberos single-sign-on should work out of the box. Before testing, ensure that the SSH server host has a valid keytab installed, and ensure that the client has a TGT. If the client still asks for a password when connecting, then starting the SSH server in debug mode (by appending the -d parameter to the sshd command line) can help narrow down the problem.

This setup produces an OpenSSH server that can accept three forms of authentication: public key authentication, password-based authentication, and Kerberos authentication. In addition, if your TGT was acquired with the forwardable bit set, then OpenSSH will forward your Kerberos credentials to the target OpenSSH server through the GSSAPI authentication mechanism.

OpenSSH honors the same .k5login file that the Kerberized telnet daemon uses for determining authorization of Kerberos principals to Unix usernames. By default, OpenSSH authorizes Kerberos principals in the local realm of the server directly to the same username on the Unix host. To specify additional principals that should be allowed access to a particular Unix username, create a .k5login file in the user's home directory. The format of this file is a single principal per line. For example, to grant access to the tdurden user account to the fgump and tdurden principals in both the WEDGIE.ORG and W2K.WEDGIE.ORG Kerberos realms, the file will contain:

tdurden@WEDGIE.ORG
tdurden@W2K.WEDGIE.ORG
fgump@WEDGIE.ORG
fgump@W2K.WEDGIE.ORG

Note that if a .k5login file exists, the default mapping between the username in the Kerberos realm and the Unix user with the .k5login file will no longer exist. Instead, the principal must be explicitly listed in the .k5login file.