MIT vs. Heimdal/Sun: "Decrypt integrity check failed"
Karsten Petersen
kapet at hrz.tu-chemnitz.de
Thu Jun 3 09:38:25 EDT 2004
Hi,
after some more testing and playing around with krb5.conf directives I
believe that I have found the problem:
Karsten Petersen wrote:
> we have a KDC (Heimdal 0.6.2) running for a test. kinit works, it
> successfully provides users with krb4 and krb5 TGTs.
Because we want to migrate our AFS to Heimdal Kerberos5, we have the
AFS-salt (and the v4-salt) activated on the kdc.
> 0. A service principal was created on the KDC.
And this principal got by default not only v5-salted keys, but also v4-
and AFS-salted.
> A krb5 keytab on the GSS test machine was created by calling Heimdal's
> kadmin with "ext_keytab *hostname*".
This exported all keys to the keytab, which therefore ended up with
several keys per encryption type.
> The keytab contains 10 different encryptions of the service key.
3 x des-cbc-crc
3 x des-cbc-md4
3 x des-cbc-md5
1 x des3-cbc-hmac
> 1. GSS client- and server-app on the GSS test machine both use MIT
> Kerberos5 1.3.1. This works like a charm.
Yeah, because it took the des3-cbc-hmac key. If forced to some other
encryption type, it did not work too.
After deleting the principal on the server, recreating it only with
v5-salted keys and exporting it again - everything worked.
> So where is the problem?
It seems to me that MIT Kerberos5 1.3.1 is not able to handle keytab
files with several keys of the same encryption type (but different
salts).
Or is there some magical krb5.conf option I did not find yet?
Best wishes,
Karsten Petersen
--
Dipl. Inf. Karsten Petersen, Universitaetsrechenzentrum, TU Chemnitz
E-Mail: kapet at hrz.tu-chemnitz.de
Telefon: (0371) - 531 - 1725
Arbeitsplatz: Strasse der Nationen 62 // Raum 1/B301.A
More information about the Kerberos
mailing list