>>>>> "kapet" == Karsten Petersen <[EMAIL PROTECTED]> 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 ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
