[krbdev.mit.edu #1324] client failures upgrading from 1.2.3 to 1.2.7

[Tom Yu via RT]

>>>>> "jered" == Jered Floyd via RT <rt-comment at krbdev.mit.edu> writes:

jered> Somewhere between krb5-1.2.3 and krb5-1.2.7, Cyrus saslauthd using
jered> Kerberos 5 for password verification (yes, I know the reasons that I
jered> shouldn't do this; it's a fallback for SSL users).  The kdc logs
jered> the following:

jered> Jan 16 00:25:38 noisybox krb5kdc[16932]: AS_REQ (3 etypes {16 1 3}) 140.239.226.142(88): NEEDED_PREAUTH: jered at CONVIVIAN.COM for krbtgt/CONVIVIAN.COM at CONVIVIAN.COM, Additional pre-authentication required
jered> Jan 16 00:25:38 noisybox krb5kdc[16932]: preauth (timestamp) verify failure: No matching key in entry
jered> Jan 16 00:25:38 noisybox krb5kdc[16932]: AS_REQ (3 etypes {16 1 3}) 140.239.226.142(88): PREAUTH_FAILED: jered at CONVIVIAN.COM for krbtgt/CONVIVIAN.COM at CONVIVIAN.COM, Preauthentication failed

Could you please send the output of "getprinc" from kadmin for the
client principal?  Also, a packet capture of the KRB_ERROR message
corresponding to the "additional pre-authentication required" error
might be useful too, as would a packet capture of the AS_REQ following
the KRB_ERROR.

What release are you running on the KDC?  What release is kinit from?
What release is saslauthd linked with?

jered> This appears to be identical to newly-occuring problems for Windows client
jered> users (currently unresolved?) as documented at:
jered>   http://mailman.mit.edu/pipermail/kerberos/2002-April/000617.html
jered>   http://www.mail-archive.com/kerberos@mit.edu/msg02724.html
jered>   http://www.mail-archive.com/kerberos@mit.edu/msg02783.html

jered> kinit functions normally.  kinit and saslauthd use nearly identical
jered> calls to krb5_get_init_creds_password:

    kinit:
            code = krb5_get_init_creds_password(k5->ctx, &my_creds, k5->me,
                                                0, kinit_prompter, 0,
                                                opts->starttime,
                                                opts->service_name,
                                                &options);

    saslauthd:
        if (krb5_get_init_creds_password(context, &creds,
                                         auth_user, password, NULL, NULL,
                                         0, NULL, &opts)) {

[...]

Is saslauthd linked against the same krb5 library as kinit?  Are they
using the same config files?

jered> I see a potential culprit.  Between 1.2.3 and 1.2.7, there is a
jered> single change to kdc_preauth.c:

    --- krb5-1.2.3/src/kdc/kdc_preauth.c	Wed Jan  9 17:27:28 2002
    +++ krb5-1.2.7/src/kdc/kdc_preauth.c	Mon Aug 12 18:50:02 2002
    @@ -533,7 +533,7 @@
         while (1) {
            retval = krb5_dbe_search_enctype(context, client, &start, -1,
                                             -1, 0, &client_key);
    -	if (retval == ENOENT)
    +	if (retval == KRB5_KDB_NO_MATCHING_KEY)
                break;
            if (retval)
                goto cleanup;

[...]

I don't think this is relevant; you quoted a change in the
get_etype_info() function.  The correct place to look would be in the
verify_enc_timestamp() function, I think.

jered> HOWEVER, between the two releases, the only change in kdb_xdr.c is:

    --- krb5-1.2.3/src/lib/kdb/kdb_xdr.c	Wed Jan  9 17:27:49 2002
    +++ krb5-1.2.7/src/lib/kdb/kdb_xdr.c	Mon Aug 12 18:48:35 2002
    @@ -726,6 +726,7 @@
         krb5_key_data	*datap;
         krb5_error_code	ret;

    +    ret = 0;
         if (kvno == -1 && stype == -1 && ktype == -1)
            kvno = 0;

jered> 2002-08-12  Sam Hartman  <hartmans at mit.edu>

jered> 	* kdb_xdr.c (krb5_dbe_search_enctype): Initialize ret to 0; thanks
jered> 	to  Lubos Kejzlar <kejzlar at civ.zcu.cz>
jered> 	[pullup from trunk]

jered> This patch does not seem to correspond to the change in
jered> kdc_preauth.c.  I am unable to usefully debug this further.
jered> What was the purpose of the above change to kdc_preauth?

It doesn't correspond.  The patch to kdb_xdr.c was to fix a different
bug having to do with preauth.  The change to kdc_preauth.c was to fix
a bug due to its being out of synch with an earlier, different change
to kdb_xdr.c -- that of no longer returning ENOENT on failure to find
a key.

A likely source of your trouble would be your client sending an
encrypted timestamp preauth encrypted using an enctype that the client
principal does not have a key for.  I'm not quite sure why this would
happen with saslauthd and not with kinit.

---Tom