Centralized Authentication with Kerberos 5, Part I

New accounts still need to be added to your shadow file or password map. However, instead of putting the encrypted password into these places, you have to create a new Kerberos principal and store the password in the KDC.

Using the kadmin tool:

% /usr/local/sbin/kadmin

add a principal for a regular users with:

kadmin:  addprinc john
NOTICE: no policy specified for john@EXAMPLE.COM; assigning "default"
Enter password for principal "john@EXAMPLE.COM":
Re-enter password for principal "john@EXAMPLE.COM":
Principal "john@EXAMPLE.COM" created.

The password you have entered during this principal creation process is the one john needs to enter in order to obtain a Kerberos TGT or to log in to a computer configured to use your Kerberos 5 realm.

You now either can create principals for all your accounts by hand or use the technique described in the migration section below.

If you plan to use Kerberos in production at your site, you should plan on using additional slave KDCs to make your installation more fault tolerant. For this, the master KDC needs to have an additional propagation service installed that sends updated versions of the KDC database to all slave servers. The slave servers need to have a receiving end for the propagation service installed. See the MIT documentation for how to set this up.

The easiest way to enable a computer for Kerberos authentication is to use a pluggable authentication module (PAM). Because it uses Kerberos API calls, it needs a working /etc/krb5.conf file. So, the first step is to copy the /etc/krb5.conf file from your KDC (see above) to each client machine.

Kerberos is used not only to authenticate users, it also is used to authenticate computers, to prevent you from logging in to a machine with a hijacked IP address. For this to work, each computer needs its own Kerberos principal with the key (the password) stored in a file (a keytab file). Principals for computers have the special form:

host/<hostname>.example.com@EXAMPLE.COM.

The first step is to create a new principal for each of your client machines. The following commands use the computer name client1 as an example. Replace the string client1 with the hostname of the client computer. Log in to every one of your client computers and execute:

% sudo /usr/local/sbin/kadmin
kadmin: addprinc -randkey host/
↪client1.example.com@EXAMPLE.COM

which assigns a random password to the new principal. Then, extract the key into a keytab file with:

kadmin: ktadd host/client1.example.com@EXAMPLE.COM

which creates the file /etc/krb5.keytab. To have write permissions to the /etc/ directory, you need to run the kadmin command with sudo. Simply creating a new principal would not have required these special privileges. Watch out for the ownership and file permissions of /etc/krb5.keytab, however; it has to be readable only by root. Otherwise, the security of this machine is compromised.

Several PAM modules for Kerberos 5 are available and all are called pam_krb5. Most of these do not work any more due to some API changes in MIT Kerberos 5 version 1.3. Your best choice right now is to use the PAM module that comes with your Linux distribution. See the section above on how to build a PAM module for Kerberos 5 from source.

Now, add the new PAM module to your system's authentication stack by editing the file /etc/pam.d/system-auth (on Red Hat systems). The entries should look similar to these Red Hat 9 entries:

auth  required    /lib/security/$ISA/pam_env.so
auth  sufficient  /lib/security/$ISA/pam_unix.so likeauth nullok
auth  sufficient  /lib/security/$ISA/pam_krb5.so use_first_pass
auth  required    /lib/security/$ISA/pam_deny.so

account   required      /lib/security/$ISA/pam_unix.so
account   [default=bad success=ok user_unknown=ignore
↪service_err=ignore system_err=ignore]
↪/lib/security/$ISA/pam_krb5.so

password  required    /lib/security/$ISA/pam_cracklib.so
↪retry=3 type=
password  sufficient  /lib/security/$ISA/pam_unix.so
↪nullok use_authtok md5 shadow
password  sufficient  /lib/security/$ISA/pam_krb5.so
↪use_authtok
password  required    /lib/security/$ISA/pam_deny.so

session   required    /lib/security/$ISA/pam_limits.so
session   required    /lib/security/$ISA/pam_unix.so
session   optional    /lib/security/$ISA/pam_krb5.so

These changes make every program with the system-auth PAM stack in its PAM configuration file (see the other files in /etc/pam.d/) use Kerberos for its authentication.