Introduction

This document was created out of the frustration that I underwent while playing with Kerberos. I found Kerberos very well documented in as much as there are plenty of documents explaining how to setup a Kerberos server but next to nothing explaining what to do once you are there.

Belive it or not, with the right setup, it really is possible to get close to that utopia of single sign on and I really do mean the same account across all service and only having to enter your password ONCE and I mean once! However, getting there is a hell of a journey. You need to configure all of you network services and all of your client software to work with Kerberos. Mostly I've found that documentation to be extreemly lacking and differences between different versions of software to cause major headachs. This document is meant to record my experience of kerberising different services. It documents the configuration options, the state of play and the various hacks that may have to be employed to work around various limitations.

Some words of advise

In my experience there are three things that will cause you pain when trying to get a Kerberised infrastructure to work:

Documentation

To get it working you need to have a properly configured service and a properly configured client. That's two potential areas where a problem may lie. Furthermore I have found Kerberos to be extreemly poorly documented and also support generally comes in later versions of the software. You generally need to do a lot of research into both your service and your client in order to get things working.

Principles

By far, the greatest number of problems that I have encountered while trying to get services to work with Kerberos is the service principles. In order to work with Kerberos each service has to have its own principle. As I'm sure you've read while setting up your Kerberos server, a principe is a user account. Each service has one, along with a password/key. The key is stored on the machine that the service runs on in a file called the keytab (Key Table). A keytab is just a file that contains the principle/key pairs for the different services. They actual name of the principle is hard coded into the application. Sometimes the keytab file is hard coded too. Usually it is /etc/krb5.keytab. Sometimes the keytab file can be specified in the service's config file. You must read the documentation for your service to work out the name of the service principle you need to create. To create a service principle and export it to a keytab, use the following commands at the kadmin prompt:

addprinc -randkey host/dragon.example.com@EXAMPLE.COM
ktadd -k /root/krb5.keytab host/dragon.example.com

In the above example, we created a service principle for the SSH service on a server called dragon in the example.com domain and the Kerberos realm EXAMPLE.COM. We then exported it to a keytab file in /root. This file can then be copied to dragon.example.com and placed in /etc.

DNS

Kerberos is very particular about DNS. It has to be exaclt right. Make sure your DNS entries are correct and that you have correct PTR (reverse) records. Another things Kerberos hates with a passion is hosts that resolve to 127.0.0.1. DON'T DO IT!