Random Notes‎ > ‎

Notes on Kerberos experiments

posted May 17, 2011, 12:38 PM by William Shallum   [ updated May 12, 2013, 7:15 PM ]
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?

See also:
Comments