Recipe 4.17 Using Kerberos with PAM for System-Wide Authentication

4.17.1 Problem

You want your existing MIT Kerberos-5 realm to be used pervasively in system authentication.

4.17.2 Solution

Run authconfig (as root) and turn on the option "Use Kerberos 5." The needed parameters for realm, KDC, and Admin server should be prefilled automatically from /etc/krb5.conf.

4.17.3 Discussion

Turning on the Kerberos option in authconfig alters various PAM configuration files in /etc/pam.d to include Kerberos. In particular, it allows Kerberos in /etc/pam.d/system-auth, which controls the authentication behavior of most servers and programs that validate passwords under Red Hat.

# grep -l system-auth /etc/pam.d/*
/etc/pam.d/authconfig
/etc/pam.d/authconfig-gtk
/etc/pam.d/chfn
...dozens more lines...

As a side effect, the general login process (e.g., via telnet, gdm/xdm, console, etc.) will automatically obtain Kerberos credentials on login, removing the need to run a separate kinit, as long as your Linux and Kerberos passwords are the same.

Avoid authconfig if you have a custom PAM configuration. authconfig overwrites PAM files unconditionally; you will lose your changes.

The configuration produced by authconfig still allows authentication via local Linux passwords as well (from /etc/passwd and /etc/shadow). By tailoring /etc/pam.d/system-auth, however, you can produce other behavior. Consider these two lines:

/etc/pam.d/system-auth:
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/pam_krb5.so use_first_pass

If you remove the second one, then local password validation will be forbidden, and Kerberos will be strictly required for authentication. Not all applications use PAM, however: in particular, Kerberized Telnet. So even if PAM ignores the local password database as shown, Kerberized Telnet will still do so if it falls back to password authentication. In this case, you could disable plain Telnet password authentication altogether. [Recipe 4.15]

As a matter of overall design, however, consider having a fallback to local authentication, at least for a subset of accounts and for root authorization. Otherwise, if the network fails, you'll be locked out of all your machines! SSH public-key authentication, for example, would be a good complement to Kerberos: sysadmin accounts could have public keys in place to allow access in exceptional cases. [Recipe 6.4]

4.17.4 See Also

authconfig(8), pam(8), and the documentation in the files /usr/share/doc/pam_krb5*/*.