7.8 Kerberos-Enabled Client Packages

To truly use Kerberos as a cross-platform single-sign-on system, Kerberized client software has to be installed as well. A complimentary pair of client and server Kerberized applications must be matched to perform native Kerberos authentication. Applications that use server-side Kerberos password verification will work with unmodified clients, but their use is discouraged as it negates the single-sign-on benefits provided through native Kerberos authentication. This section describes some of the software packages available that provide client-side native Kerberos functionality.

7.8.1 Kerberized Secure Shell Clients

In a previous section, we built OpenSSH with GSSAPI support. This OpenSSH with GSSAPI patches works on many platforms, including all of the common Unix variants, and Mac OS X. However, OpenSSH operates only on the command line, and compiling OpenSSH on Windows can be difficult. A popular, free, and graphical Secure Shell client for Windows is PuTTY, and a company named Certified Security Solutions has developed patches to PuTTY to incorporate GSSAPI authentication support, and provides binaries that are free for noncommercial and internal commercial use.

The modified PuTTY client is available at http://www.certifiedsecuritysolutions.com/downloads.html. Separate distributions are available for Windows 2000 and older Windows operating systems. The distribution for Windows 2000/XP/2003 includes support for the Windows SSPI that can communicate with the GSSAPI-enabled OpenSSH without requiring Kerberos for Windows to be installed on the Windows host.

7.8.2 Reflection X

Reflection X is an X11 server package published by WRQ, Inc. Reflection X allows users on Windows platforms to access X11 applications on Unix hosts. While there are many such packages available, Reflection X has decent Kerberos functionality provided as part of the Security Components. By using the Reflection Security Components, you can set up a cross-platform single-sign-on infrastructure between Windows clients, Windows servers, and Unix servers.

The latest version is WRQ Reflection X 10, and includes support for the latest industry standard X11R6.6 protocol as well as traditional, character-based terminal emulation protocols. For more information on the X server support and terminal emulation features provided by the Reflection X package, visit the WRQ home page at http://www.wrq.com/.

To start X11 applications on a Unix server, the X server software running on the Windows host must have a remote login client built in to log into the Unix host, redirect the X11 display to the Windows machine's IP, and then start the X11 application. A diagram of this process is shown in Figure 7-2.

Figure 7-2. Logging into Unix host, redirecting display, and starting application

Most X11 servers for Windows use telnet or rlogin for this process. The downside of using telnet or rlogin to start these X11 applications, of course, is that plain text passwords are sent over the network to log the user into the Unix host. In addition, for convenience, X11 servers will offer to cache the Unix password, so that users do not have to type it in on a regular basis.

Reflection X addresses these security concerns through the Reflection Security Components, which are available for Reflection X customers as a free download from WRQ's web site. The Reflection Security Components include an OpenSSH implementation to launch X11 applications through a Secure Shell connection. More pertinent to our discussion at hand, though, is its support for Kerberized telnet connections to Unix hosts. This support provides for secure authentication, avoiding the problem of sending the user's password over the network in the clear to the telnet server on the Unix host, but it still sends the user's X11 session over the network in the clear. The OpenSSH implementation included in the Security Components uses Secure Shell's X11 tunneling support to provide session encryption for the X11 connections as well, but unfortunately, Reflection's current implementation of Secure Shell only supports password and public key authentication, and does not support GSSAPI authentication.

The Reflection Security Components uses its own custom Kerberos implementation, and does not require MIT's Kerberos for Windows to be installed.

Before starting Reflection X with the security components for the first time, you'll want to set up the Kerberos settings. This procedure will have to be performed for each Windows user who uses Reflection Kerberos to connect to Unix hosts. The application that manages the Reflection Kerberos configuration is named "Kerberos Manager" and can be found in the Utilities subfolder of the WRQ Reflection folder in the Start Menu's Programs folder. When you start the Kerberos Manager for the first time, you'll be greeted with the following initial configuration dialog (Figure 7-3).

Figure 7-3. Reflection Kerberos initial configuration dialog

The default principal will default to your Windows username; if these differ, change the value to your principal in the Kerberos realm. The default realm should be set to your Kerberos realm, and the kadmin server should be set to your master KDC, or a Windows domain controller, if you're using a Windows machine as your KDC. The credentials file can be left as the default, unless you wish to change where the Reflection applications keep the credential cache.

Once the initial configuration is out of the way, there are a few other configuration parameters that might need adjusting, depending on your realm's set up. The realm configuration parameters can be accessed through the Kerberos Manager program's Configuration/Configure Realms menu option. That menu option displays the dialog box on the left, as shown in Figure 7-4.

Figure 7-4. Reflection Security Components Kerberos realm configuration

The properties dialog box (displayed on the right) is accessed through the Properties button. Properties such as desired ticket lifetimes and requested ticket flags can be set in this dialog box. A particularly important property that can be changed here is the pre-authentication method, which must be set to Encrypted timestamp if your realm uses pre-authentication. The Reflection Kerberos libraries do not properly respond to the pre-authentication required Kerberos error message, and authentication will fail if the KDC requires pre-authentication.

Once the initial configuration steps are out of the way, a test can be performed by creating a Kerberized telnet connection profile in the terminal emulator. Open the Host Unix and Digital application under the WRQ Reflection application group. Create a new connection profile by selecting Connection Setup under the Connection menu. Fill in the hostname of the target host running a Kerberized telnet server in the text box. Click the Network radio button in the Connect using group, and the Security button becomes active. Clicking the Security button brings up the security dialog box; inside this dialog box is a Kerberos tab. Ensure the Use Reflection Kerberos is checked, the User ID field is set to your username on the Unix host, and the default principal is correct.

Once all of the settings are in place, click Connect so Reflection will connect to the Unix telnet server, and login via Kerberos. If the authentication is successful, there will be a small yellow key icon on the status bar indicating that the session was authenticated via Kerberos. In addition, if "Encrypt data stream" was checked in the Kerberos options dialog box, a small padlock will also appear in the status bar, indicating that the session contents are also encrypted.

You can check that Reflection successfully acquired an initial TGT and ticket for the host principal by opening the Kerberos Manager application. There should be ticket entries for both the krbtgt principal as well as the host principal. Figure 7-5 shows a successful login to a Unix host and the resulting tickets in the Reflection Kerberos Manager.

Figure 7-5. Reflection Kerberos ticket manager

When the connection works with the terminal emulator, using the same settings for the X window session options works, too. X client sessions can be created manually through the X Client Manager or the X Client Wizard. Click the Advanced button of a X session property page to find the Kerberos-related settings for X client sessions.

7.8.2.1 Using existing credential caches with Reflection X

Since the Reflection Security Components includes its own Kerberos implementation, Reflection keeps its credential cache separate from the Windows cache and the MIT credential cache, if MIT Kerberos for Windows is installed. This creates quite a mess of Kerberos credentials, and requires users to login with their username and password multiple times. Thankfully, the Kerberos libraries included with the Reflection Security Components have the ability to import tickets from credential caches created by both the MIT Kerberos libraries as well as the Windows internal credential cache.

The configuration options to toggle this support on and off are found in the Kerberos Manager application. Select the Configure Realms menu item from the Configuration menu, and that will bring up a dialog box listing the names of all the realms Reflection knows about. Select your realm, and click Properties. Under the KDC tab of the Properties dialog box, the two checkboxes at the bottom control whether Reflection will try and copy the TGTs from the Windows and/or MIT credential cache on startup. If the "Use Windows logon credentials" box is disabled, then the currently logged in user was authenticated locally instead of as part of a domain or Kerberos realm. The "Use leash32 cache" checkbox refers to the MIT Kerberos credential cache, and will only be enabled if the Kerberos DLL's included with the MIT Kerberos for Windows distribution are installed in a system-wide location (such as \WINNT\System32).

When either checkbox is enabled, Reflection will copy the TGT from the selected cache into its own credential cache when any of the Reflection applications are started. Note that Reflection will only copy the credentials from the source cache upon startup; if the source cache changes (for example, Windows will automatically refresh the TGT before it expires), Reflection will not notice and require the user to re-authenticate directly to Reflection Kerberos.

7.8.3 Electronic Mail

Email is an application users depend on every day. There are several Mail User Agents that include Kerberos support. We'll examine two of these in this section: Qualcomm's Eudora and Apple's Mail.app. Both are modern mail readers that support all of the major electronic mail standards, including POP, IMAP, authenticated SMTP, SSL/TLS encryption, and most importantly, for our discussion, Kerberos support. Microsoft's popular Exchange server and Outlook client will support Kerberos authentication as of Exchange and Outlook 2003.

7.8.3.1 Qualcomm Eudora

Eudora is a popular email client available for both Windows and Mac OS. It is developed by Qualcomm, and is available at http://www.eudora.com. This section discusses how to set up Eudora for Windows to use GSSAPI authentication, and setting up the Macintosh version is very similar.

Before starting, ensure that the MIT Kerberos for Windows distribution has been installed, the Kerberos DLLs are present in the Windows system directory, and a valid krb5.ini containing information for your Kerberos realm is also located in the Windows system directory. If either of these are missing or only partially installed, Eudora may fail with no error message when attempting to authenticate to the IMAP server.

When first starting Eudora, you will be presented with a wizard to guide you through the steps of setting up a mail account. Since the wizard has no provisions for enabling Kerberos support, the best option at this point is to choose the "Skip directly to advanced account setup" option. This option drops you into the first tab of the account setup dialog box, as shown in Figure 7-6.

Figure 7-6. Eudora's options dialog

Once the appropriate information regarding the mail servers and usernames have been filled in, go to the Incoming Mail category, and ensure that the authentication style radio button is set to Kerberos (see Figure 7-7). That's the only configuration required to use GSSAPI authentication with IMAP mail servers.

Figure 7-7. Kerberos setting in Eudora's options dialog

7.8.3.2 Apple Mail.app

Mail.app integrates directly with the Kerberos infrastructure present in Mac OS X and supports Kerberos authentication for POP, IMAP, and SMTP servers, supporting single-sign-on for all electronic mail-related protocols.

Mail.app is rather easy to set up, and the account information can be accessed through the Accounts pane of the Mail.app Preferences window. When adding or editing an existing account, the sheet shown in Figure 7-8 appears. The Advanced tab is where special authentication options can be chosen for the account, including GSSAPI authentication. To enable Kerberos 5 authentication with a POP or IMAP server is as simple as selecting GSSAPI in the Authentication drop-down box. This has been tested and works at least with the Cyrus IMAP server listed above, but should also interoperate with any server implementation that includes GSSAPI authentication support.

Figure 7-8. GSSAPI option located in Mail.app's Advanced options dialog