You want your existing MIT Kerberos-5 realm to be used pervasively in system authentication.
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.
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.
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]
authconfig(8), pam(8), and the documentation in the files /usr/share/doc/pam_krb5*/*.