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, [EMAIL PROTECTED] wrote:
------------------------------------------------------------------------ ----Date: Fri, 04 Jun 2004 00:01:32 -0400 From: Tom Yu <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: MIT vs. Heimdal/Sun: "Decrypt integrity check failed" Message-ID: <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> (Karsten Petersen's message of "Thu, 3 Jun 2004 13:38:25 +0000 (UTC)") References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Precedence: list Message: 8
"kapet" == Karsten Petersen <[EMAIL PROTECTED]> writes:
kapet> Karsten Petersen wrote:kapet> Because we want to migrate our AFS to Heimdal Kerberos5, we have thewe have a KDC (Heimdal 0.6.2) running for a test. kinit works, it successfully provides users with krb4 and krb5 TGTs.
kapet> AFS-salt (and the v4-salt) activated on the kdc.
kapet> And this principal got by default not only v5-salted keys, but also v4-0. A service principal was created on the KDC.
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
kapet> Yeah, because it took the des3-cbc-hmac key. If forced to some other1. GSS client- and server-app on the GSS test machine both use MIT Kerberos5 1.3.1. This works like a charm.
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.
kapet> It seems to me that MIT Kerberos5 1.3.1 is not able to handle keytabSo where is the problem?
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.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
