لطفا منتظر باشید ...
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.
|
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*/*.
