Notes on Kerberos experiments
Posted May 17 2011, 19:38 by William Shallum [updated May 13 2013, 02:15]
Experimenting with kerberos + LDAP in Debian Squeeze:
The default pam_unix + pam_krb5 configuration generated in /etc/pam.d/common-account using pam-auth-update (as follows) does not allow logging in using kerberos if the user is not in the shadow file.
# here are the per-package modules (the "Primary" block) account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so # here's the fallback if no module succeeds account requisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around account required pam_permit.so # and here are more per-package modules (the "Additional" block) account required pam_krb5.so minimum_uid=1000 # end of pam-auth-update config
If it’s OK to do so, either change the whole config file or add something like this at the top:
account sufficient pam_krb5.so minimum_uid=1000
- what does an account PAM module do? “non-authentication based account management”? The pam_unix docs indicate that the account component of pam_unix does checking on password expiry in the shadow file & may be able to force a change of password. Where should this information be stored if we are using kerberos + LDAP? Should we be using pam_ldap only in the common-account part to handle this?
- Passwordless SSH login using tickets?