I think this message never made it to the list because of the long recipients list. Resending. Nico, I'm still trying to digest much of this flood of information, but I did want to comment on the pam_krb5 password aging issue that you brought up. > The pam_krb5 pam_sm_close_session() method can do some useful things: > - warn the user about upcoming password expiration (e.g., "Your > password will expire in 3 days") It would be great if pam_krb5 could do this. (pam_sm_open_session() rather than _close_, though, yes?) One of the biggest problems I'm having right now with deploying Kerberos 5 is that the RedHat pam_krb5 module doesn't have any hooks for password expiration, etc. I'm overjoyed to hear that someone else has a module out there that has figured out a way to do this, and I will be tracking down Frank Cusak's module ASAP. > I think the solution is for pam_krb5:pam_sm_authenticate() to work > through changing a user's old password when it's expired, without > setting the PAM_*AUTHTOK items, leaving that to > pam_krb5:pam_sm_chauthtok() and using pam_set_data() to keep state. > Alternatively, pam_krb5:pam_sm_authenticate() could provisionally return > PAM_SUCCESS in password expired cases, then pam_krb5:pam_sm_acct_mgmt() > can return PAM_NEW_AUTHTOK_REQD, and then pam_krb5:pam_sm_chauthtok() > return PAM_SUCCESS/PAM_PERM_DENIED/PAM_AUTH_ERR and so on. Applications > MUST treat pam_chauthtok() as if it were pam_authenticate() in such > cases and deny access unless pam_chauthtok() returns PAM_SUCCESS. > The latter solution is harder to implement in pam_krb5 than the former, > needing several calls to krb5_get_init_creds_with_password() instead of > just one call. The second solution is harder to implement, but it's the Right Thing To Do: using the first method as you describe would break stackability, which is a key feature of PAM. Currently, I have pam_krb5 stacked with pam_smbpass (and eventually pam_ntdom, if I can get my hands on it anymore), and I need both passwords to be kept in sync. If pam_krb5 is going to change expired passwords on me in the pam_authenticate() phase without ever communicating to libpam, then I have no way of even knowing the NTLM password needs to be changed, let alone of keeping the two passwords in sync. Aside from added complexity within the pam_krb5 code, are there any other reasons not to handle password expiry this way? Regards, Steve Langasek postmodern programmer
