MIT vs. Heimdal/Sun: "Decrypt integrity check failed"

Henry B. Hotz hbhotz at
Tue Jun 8 18:06:02 EDT 2004

In Heimdal the way to do this is:

1) Create the principal with kadmin add -r <princ>
(IIRC this creates a principal without the multiple key salt's because  
there is no corresponding password, and therefore no applicable key  
salt.  You get a principal with a better key and less confusion.)

2) kadmin del_enctype <...>
(Delete the enctypes that aren't supported by your target platform.  If  
you're not sure try deleting all of them except des-cbc-md5.)

3) kadmin ext -k <keytab> <princ>
And securely copy the keytab where it belongs.  Note you have to do  
this step last because step 2 changes the kvno of the key.

I think you can do this in one step with the Heimdal ktutil on the  
remote machine.  I've done the above to get keytabs for Solaris that  
work fine, and I never installed Heimdal on the Solaris client (until  
much later).

On Jun 3, 2004, at 10:53 PM, kerberos-request at MIT.EDU wrote:

> Date: Fri, 04 Jun 2004 00:01:32 -0400
> From: Tom Yu <tlyu at MIT.EDU>
> To: kerberos at MIT.EDU
> Subject: Re: MIT vs. Heimdal/Sun: "Decrypt integrity check failed"
> Message-ID: <ldvwu2oj7j7.fsf at>
> In-Reply-To: <slrncbuaeg.sbn.kapet at> (Karsten
>  Petersen's message of "Thu, 3 Jun 2004 13:38:25 +0000 (UTC)")
> References: <slrncbtqk2.sbn.kapet at>
> 	<slrncbuaeg.sbn.kapet at>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 8
>>>>>> "kapet" == Karsten Petersen <kapet at> writes:
> kapet> 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.
> kapet> Because we want to migrate our AFS to Heimdal Kerberos5, we  
> have the
> kapet> AFS-salt (and the v4-salt) activated on the kdc.
>>> 0. A service principal was created on the KDC.
> kapet> And this principal got by default not only v5-salted keys, but  
> also v4-
> kapet> and AFS-salted.
> I suspect this is at least part of your problem.
>>> The keytab contains 10 different encryptions of the service key.
> kapet> 3 x des-cbc-crc
> kapet> 3 x des-cbc-md4
> kapet> 3 x des-cbc-md5
> kapet> 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.
> kapet> Yeah, because it took the des3-cbc-hmac key.  If forced to some  
> other
> kapet> encryption type, it did not work too.
> When you set up the des3-cbc-hmac key, did you only specify one salt
> type?  It looks like that is the case.
> kapet> After deleting the principal on the server, recreating it only  
> with
> kapet> v5-salted keys and exporting it again - everything worked.
>>> So where is the problem?
> kapet> It seems to me that MIT Kerberos5 1.3.1 is not able to handle  
> keytab
> kapet> files with several keys of the same encryption type (but  
> different
> kapet> salts).
> kapet> Or is there some magical krb5.conf option I did not find yet?
> The Kerberos protocol has no inherent way to tell the application
> server which of several keys for the same encryption type to use to
> decrypt the ticket.  The ticket only indicates thet encryption
> algorithm, and not which of several keys suitable for the encryption
> algorithm.
> The code that reads the request from the client will search the keytab
> for the first key which matches the encryption type and kvno specified
> in the ticket.  If this is not the same key which the KDC used to
> encrypt the ticket, you will get an error.  The MIT KDC will pick the
> first listed key of the highest kvno in the principal entry for
> encrypting the ticket.  I'm not sure what Heimdal does in this case.
> If you intend a principal to be used as a service principal, it is
> probably safest to ensure that it only has one key per encryption
> type.
> It could be argued that the rd_req operation should attempt to use all
> keys in the keytab which match the encryption type and kvno of the
> ticket, but this is not currently done in the MIT code.
> ---Tom
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at, or hbhotz at

More information about the Kerberos mailing list