[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Linux PAM fixes

I think this message never made it to the list because of the long recipients
list.  Resending.


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?

Steve Langasek
postmodern programmer

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []