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

To check:

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?

William Shallum

Quick Links

Notice

Notes on Kerberos experiments