Unix as a Kerberos Client

4.6 Client and Application Server Installation

Before a client machine or Kerberized application server can use Kerberos authentication, it must have the proper libraries, configuration files, and in some cases, service and host principals added to a local keytab file. We will limit the discussion for now to using the same Kerberos implementation both on the KDC and the clients. Most of the setup information below can be used to interface with a different vendors KDC, but we will take a closer look at interoperability later in Chapter 8 .

4.6.1 Unix as a Kerberos Client

There are three major steps to setting up a Unix-based Kerberos client or Kerberized application server: compiling the distribution, installing configuration files, and creating host and service principals if necessary. The first step, compiling the distribution, has already been discussed in the Building the distribution sections under the appropriate heading for your chosen Kerberos implementation; follow the directions to build and install the client libraries. Next, well create configuration files on each of the clients. Both MIT and Heimdal use a configuration file located in etckrb5.conf. This configuration file contains the name and addresses of all KDCs that the client can communicate with. Alternatively, this information can be placed in DNS, as discussed in Section 4.5 . Since most Kerberos installations are still using configuration files, well discuss them. We saw a simple krb5.conf file earlier, when we set up the MIT KDC above. That template still applies for clients, and in fact, the etckrb5.conf configuration file can be copied straight from the KDC to all of the clients. If you want to tweak the configuration file anyway, there are three stanzas that are important for client configuration: libdefaults, realms, and domain_realm. Lets start with a sample configuration file. It should look familiar; it is the same one presented in the KDC installation section Section 4.4 : [libdefaults] default_realm = WEDGIE.ORG [realms] WEDGIE.ORG = { kdc = freebsd.wedgie.org:88 admin_server = freebsd.wedgie.org:749 default_domain = wedgie.org } [domain_realm] wedgie.org = WEDGIE.ORG .wedgie.org = WEDGIE.ORG The libdefaults stanza contains parameters that apply to all applications using the Kerberos libraries. The only option that you may have to tweak in this stanza is the default_realm option. This option specifies the default realm that the Kerberos libraries will use when trying to find a service principal for a given service. Normally, the Kerberos realm and DNS domain name are the same, but they can be different. If your Kerberos realm differs from the DNS domain that this machine resides in, then you should set this parameter to your Kerberos realm. [ Team LiB ] [ Team LiB ]

Chapter 5. Troubleshooting

Working with Kerberos can seem like an exercise in futility. The combination of complex software, interoperation between Kerberos implementations and diverse operating systems, and terse at best error messages tend to bring premature balding to the administrators responsible for the smooth operation of their systems. However, working with Kerberos does not have to be this frustrating. To provide a systematic approach to solving problems in Kerberos, this chapter begins with a discussion of the various debugging tools and techniques, including a sample decision tree to follow when facing a new problem. Becoming familiar with these tools and techniques before disaster strikes will be helpful when the inevitable problem occurs. The second section will use those tools and techniques to diagnose some typical problems that occur in a Kerberos system. It will describe the symptoms of these common problems and then show possible solutions to solve them. [ Team LiB ] [ Team LiB ]