directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wu, James C." <James.C...@disney.com>
Subject RE: kinit failed on - Integrity check on decrypted field failed
Date Tue, 09 Apr 2013 22:55:10 GMT
Hi Emmanuel,

If you can test the full kinit sequence tomorrow, that would be great! Please keep me updated.


James


-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Tuesday, April 09, 2013 3:52 PM
To: Apache Directory Developers List
Subject: Re: kinit failed on - Integrity check on decrypted field failed

Le 4/9/13 11:13 PM, Wu, James C. a écrit :
> Hi,
>
> I came across this page which describes how Kerberos key are derived from the passwords
of an entry. 
> http://directory.apache.org/apacheds/kerberos-ug/1.1.3-keys.html
>
> It mentioned that the Kerberos keys are basically a hashed value of the passwords with
the salt be the realm name. I am wondering how does the kinit program know the salt for the
Kerberos key? Is it passed from apacheds? I did not see something like that mentioned in the
log output.
Kinit will not create the hashed values of the password. It's coputed on the fly when the
password is added, on the server. The salt is not used by kinit.
>
> I guess the kinit has to know both the encryption type and the salt in order to reproduce
the Kerberos encryption key so that it can decrypt message from apacheds. Am I right?
No, it's not what happens. The encryption key is negociated by the server and the client during
the very first steps of the kerberos exchange. In your case, the AES 256 algorithm is being
selected.

I'm sorry, I'm in the middle of a release atm, but I'll try to test the full kinit sequence
asap (ie, probably tomorrow my time)

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

Mime
View raw message