[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