Discussion of krb5_get_init_creds_password() behavior was Re:problem with the kinit_prompter in kfw 2.5

John Hascall john at iastate.edu
Thu Feb 19 14:26:40 EST 2004

> The kerberos at mit.edu mailing list is an inappropriate place for this 
> discussion.
> Please hold this discussion on krbdev at mit.edu OR open a bug report in the
> Request Tracker by sending e-mail to krb5-bugs at mit.edu.

OK.  It's here.  And I still don't think the logic of
krb5_get_init_creds_password() is correct...

> John Hascall wrote:
> >>Beata A. Pruski wrote:
> >>>I must say I don't understand why within krb5_get_init_creds_password,
> >>>after the first call to krb5_get_init_creds (with use_master being 0)
> >>>returns KRB5KDC_ERR_KEY_EXP, there is still another call made to the
> >>>same function with use_master set to 1. Shouldn't there be some sort
> >>>of "goto" statement:
> >>>	if (ret == KRB5KDC_ERR_KEY_EXP) ...

> >>Consider the situation in which the user has just changed their password
> >>but there are multiple secondary KDCs and the password change has not 
> >>yet been propagated from the primary KDC.  The secondary KDCs will think 
> >>the password is still expired when in fact it has been changed. 
> >>Therefore, if the password fails we must attempt to contact the Primary 
> >>KDC in order to ensure that current password is indeed contacted.

> >I still think the logic in krb5_get_init_creds_password()
> >where it double calls krb5_get_init_creds() is seriously wrong.

> >One problem I previously mentioned was (after the core-dump issue
> >I raised is resolved) it will double prompt for password, if the user
> >enters an empty password.

> >% ./some-program-that-calls-krb5_get_init_creds_password
> >Password ...:            <Oh, I didn't mean to do that, I'll just return>
> >Password ...:            <huh?>

> >Another problem is that almost for sure you get 2 strikes against
> >the "5 strikes and you are out" code for every wrong attempt
> >(since the attempt with use_master = 0 contacted the master).

> >Ugly as it is, I think the only way to make this really work
> >properly is for krb5_get_init_creds() to return an indication
> >as to whether or not the reply it is returning came from the
> >master kdc and if so, skip the 2nd call (with use_master = 1).

OK, actually, the right fix would be for the KDCs to use
a proper replicated DB so you always get the same answer
no matter which KDC responds.  But, I'm not holding my breath.


More information about the krbdev mailing list