On Sun, Mar 04, 2001 at 03:11:01PM -0600, Steve Langasek wrote:
> On Sun, 4 Mar 2001, Nicolas Williams wrote:
[...]
> No, of course they don't use krb5_get_init_creds_password(). If they did, I
> would never have noticed the problem with Frank's module. :D
:)
> Actually, I'm going to be making some changes locally to pam_krb5 so that the
> changing of expired passwords is moved to the pam_chauthtok() stage where it
> belongs according to the spec (which means no longer using
> krb5_get_init_creds_password()). I have a genuine need for module stacking in
> the password-changing phase, so having pam_krb5 do this directly in the auth
> phase doesn't cut it for me.
Ah yes. I've asked Andrew Morgan privately about this. I decided to let
password aging and changing go on in pam_sm_authenticate(), but I still
want pam_sm_acct_mgmt() to return PAM_NEWAUTHTOK_REQD when passwords are
aged in pam_sm_authenticate(). The approach I'll take is easy:
if ((kret = krb5_get_init_creds_password(/* no prompter function */))
== KRB5_KDCERR_EXPKEY)
{
pam_set_data(pamh, "pam_krb5_pw_exp", ...);
if ((kret = krb5_get_init_creds_password(/* w/ prompter function */)))
{
...
}
}
Then have pam_sm_acct_mgmt() check for "pam_krb5_pw_exp" PAM module data
and then return PAM_NEWAUTHTOK_REQD. And pam_sm_chauthtok() also needs to
check to avoid changing the krb5 password again.
For apps that guarantee that they'll call pam_acct_mgmt() and
pam_chauthtok() and so on then we can leave the second call to
krb5_get_init_creds_password() to pam_sm_chauthtok().
The key here is that krb5_get_init_creds_password() returns the
appropriate error to indicate that the given principal's password is
expired IF no prompter function was provided.
The main issue here is that MIT (and Sun; and Heimdal?) KDCs you cannot
authenticate to the local host if your password is expired UNTIL you
have changed your password. This is very different from the PAM approach.
Please forgive typos in error names. I'm typing from memory here.
> > > So there may not be an /absolute/ need to send multiple prompts in one go, but
> > > it's certainly unfortunate if we have to give up this functionality in
> > > exchange for portability.
>
> > Agreed. For now I'll modify my version of this module to support an
> > option to prompt one prompt at a time.
>
> Have you talked to Frank about including your fixes in his next release?
> (I've been cc:ing him on this thread because it's relevant to making his
> module work under Linux, but I have no idea if he's reading. :) I agree with
> your assessment that Frank's pam_krb5 module is the most
> functionally-complete implementation available to date, which is a good reason
> to prevent code forking here if possible...
I fully intend to pass my patches to Frank Cusack AND the FreeBSD ports
folk.
Another change I want to make is to deny login if a ticket cannot be
verified against a local keytab. Or at least make this an option.
And if Frank or his license allows it, I'll submit a request for
extension to Sun with the whole code. And MIT/Heimdal also could use a
good PAM_KRB5 to include with their distros.
> Steve Langasek
> postmodern programmer
>
>
Nico
--
