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

Jered Floyd via RT rt-comment at krbdev.mit.edu
Sun Jan 19 22:35:14 EST 2003


> 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.

Principal: jered at CONVIVIAN.COM
Expiration date: [never]
Last password change: Thu Mar 28 00:37:12 EST 2002
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Mar 28 00:37:12 EST 2002 (kadmind at CONVIVIAN.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 5, DES cbc mode with CRC-32, no salt
Key: vno 5, DES cbc mode with RSA-MD5, Version 4
Key: vno 5, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 5, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 5, DES cbc mode with RSA-MD5, AFS version 3
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

Both successful and unsuccessful exchanges are attached. They are
in libpcap format as dumped by ethereal on Linux.

> What release are you running on the KDC?

Whoops; somewhat out of date: 1.2.4 as found in the Debian package
krb5-kdc-1.2.4-5woody3.  I've updated to 1.2.7-2; no change.

> What release is kinit from?

1.2.4 as found in the Debian package krb5-user-1.2.4-5woody3.  Now
updated to 1.2.7-2 as well.

> What release is saslauthd linked with?

It was dynamically linked against 1.2.4 as found in Debian package
libkrb53-1.2.4-5woody3.  It is now dynamically linked against 1.2.7 as
well.  (It was originally built, I believe, against 1.2.3.) No change.

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

Yes, to the first question.  I believe so on the second; is there a
likely way this might not be the case?

> 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




More information about the krb5-bugs mailing list