Ok, so, things are complicated. The PAM standard insists on password aging being done after account authorization, which comes after user authentication. Kerberos can't authenticate users whose passwords are expired. So PAM_KRB5 implementations tend to return PAM_SUCCESS from pam_krb5:pam_sm_authenticate() and arrange for pam_krb5:pam_sm_acct_mgmt() to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user can't be said to be authenticated at that point. The problem with this is that by the time pam_acct_mgmt() is called in OpenSSH userauth has been completed, so kbd-interactive is not used for the password changing and instead the work is relegated till the TTY session is setup. By then the login process has begun and the user even has a UTMP entry. To make matters worse, OpenSSH calls pam_setcred() before pam_chauthtok(). Clearly that is wrong. Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it to do the password aging prompting in pam_krb5:pam_sm_authenticate(). Using this option with the "sshd" PAM service causes password aging to be performed over the kbd-interactive protocol. Good? Bad? I say "good." Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Yow..that is a problem isn't it. Hmm..It's a hard call, but I'd have to vote good there too. On Tue, 2002-03-26 at 15:34, Nicolas Williams wrote:> Ok, so, things are complicated. > > The PAM standard insists on password aging being done after account > authorization, which comes after user authentication. Kerberos can't > authenticate users whose passwords are expired. > > So PAM_KRB5 implementations tend to return PAM_SUCCESS from > pam_krb5:pam_sm_authenticate() and arrange for > pam_krb5:pam_sm_acct_mgmt() > to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user > can't be said to be authenticated at that point. > > The problem with this is that by the time pam_acct_mgmt() is called in > OpenSSH userauth has been completed, so kbd-interactive is not used for > the password changing and instead the work is relegated till the TTY > session is setup. By then the login process has begun and the user even > has a UTMP entry. > > To make matters worse, OpenSSH calls pam_setcred() before > pam_chauthtok(). Clearly that is wrong. > > Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it > to do the password aging prompting in pam_krb5:pam_sm_authenticate(). > Using this option with the "sshd" PAM service causes password aging to > be performed over the kbd-interactive protocol. Good? Bad? I say "good." > > Nico > -- > -DISCLAIMER: an automatically appended disclaimer may follow. By > posting- > -to a public e-mail mailing list I hereby grant permission to > distribute- > -and copy this message.- > > Visit our website at http://www.ubswarburg.com > > This message contains confidential information and is intended only > for the individual named. If you are not the named addressee you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately by e-mail if you have received this > e-mail by mistake and delete this e-mail from your system. > > E-mail transmission cannot be guaranteed to be secure or error-free > as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. The sender therefore > does not accept liability for any errors or omissions in the contents > of this message which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. This > message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > _______________________________________________ > openssh-unix-dev at mindrot.org mailing list > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev-- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin at coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb
On Tue, Mar 26, 2002 at 04:34:18PM -0500, Nicolas Williams wrote:> Ok, so, things are complicated. > > The PAM standard insists on password aging being done after account > authorization, which comes after user authentication. Kerberos can't > authenticate users whose passwords are expired. > > So PAM_KRB5 implementations tend to return PAM_SUCCESS from > pam_krb5:pam_sm_authenticate() and arrange for pam_krb5:pam_sm_acct_mgmt() > to return PAM_NEW_AUTHTOK_REQD, as required by PAM even though the user > can't be said to be authenticated at that point. > > The problem with this is that by the time pam_acct_mgmt() is called in > OpenSSH userauth has been completed, so kbd-interactive is not used for > the password changing and instead the work is relegated till the TTY > session is setup. By then the login process has begun and the user even > has a UTMP entry. > > To make matters worse, OpenSSH calls pam_setcred() before > pam_chauthtok(). Clearly that is wrong. > > Our PAM_KRB5 module has a module option "pw_exp_in_auth" which causes it > to do the password aging prompting in pam_krb5:pam_sm_authenticate(). > Using this option with the "sshd" PAM service causes password aging to > be performed over the kbd-interactive protocol. Good? Bad? I say "good."Qualified good. Wouldn't it be better to do pam_acct_mgmt() before kbdint et al complete? Your solution requires a rewrite of all PAM modules. /fc