Centralized Authentication with Kerberos 5, Part I

If you already have a working Windows Active Directory (AD) KDC installation, you can use it as the master KDC for your Linux/UNIX machines. In this case, you can skip the entire server installation and do only the above described setup of your clients. Your /etc/krb5.conf file needs to define the Windows KDC instead of a UNIX KDC. For more information on how to create and copy a keytab file and this scenario in general, see Resources.

If you have a number of Windows machines in your group, you can use your UNIX KDC for them as well. This works, however, only if your Windows clients don't belong to a Windows AD domain with Kerberos already and the account names are the same in Kerberos and Windows. See Resources for details.

Using Mac OS X clients in your Kerberos 5 realm is as easy as configuring the names of your UNIX KDCs on your Macs. Again, account names have to match.

Now that you have a working Kerberos 5 realm and your clients configured, you have to convert all your user accounts. So far, the passwords for your accounts are stored either in the machine's local /etc/shadow files or in a NIS/LDAP password map. These passwords are encrypted with a one-way hash function that makes it impossible, or at least impractical for people without a supercomputer, to crack them or to convert everything into Kerberos 5 format. A good way to migrate from your current situation to Kerberos is to use pam_krb5_migrate (see Resources). This stackable PAM module can be installed on a few computers; every time someone logs on, it creates a new principal for this account in your Kerberos 5 KDC reusing the account's current password.

After everybody has logged on to these special machines, all your users have a corresponding Kerberos 5 principal. You then can replace the passwords in your local files or your NIS/LDAP password map with a placeholder, such as krb5. The Kerberos PAM module authenticates your users from now on. At this point, you also can remove pam_krb5_migrate from the migration systems.

Now that you have Kerberos up and running, you can use services that make use of it. You could install Kerberized telnet and FTP, but you really should use SSH. You could Kerberize your Apache Web server and your Mozilla Web browser. Before Kerberos, you would have to type your password when using these services. With Kerberos, all these applications are using your stored Kerberos credentials and use them internally to authenticate you for the respective service. This is what many mean by single-sign-on.

Resources for this article: www.linuxjournal.com/article/7706.