[37995] in Kerberos
Re: wrong key is generated by krb5_c_string_to_key
daemon@ATHENA.MIT.EDU (Isaac Boukris)
Mon Jun 5 12:44:03 2017
MIME-Version: 1.0
In-Reply-To: <afcde1c1-ca72-da8d-41c5-a5567068a01a@mproehl.net>
From: Isaac Boukris <iboukris@gmail.com>
Date: Mon, 5 Jun 2017 19:43:48 +0300
Message-ID: <CAC-fF8Tqxxk9vrc4XTnPejwsYTNqmZ+1=zr+zuMcS8D8rtBqTQ@mail.gmail.com>
To: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Mon, Jun 5, 2017 at 6:51 PM, Mark Pröhl <mark@mproehl.net> wrote:
> On 06/02/2017 02:29 PM, Ashi1986 wrote:
>> Hi All ,
>>
>> This is my setup .
>>
>> windows 8.1 64 bit
>> windows 2012 R2 server AD and KDC .
>> BS2000 with MIT kerberos 1.13.2
>>
>> I generate keytab for SPN using this command :
>>
>> ktpass -princ host/<Host name>@domain name -mapuser <domain name\domain user
>> pass> pass <password> -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out
>> C:\KeyTab\HMAC7U6.keytab
>>
> If I do understand you correct, the keytab with the invalid RC4 and AES
> keys is generated with ktpass.exe. If so, how should that be related to
> the krb5_c_string_to_key function from MIT Kerberos?
For AES keys I'd suspect the salt doesn't match (afaik, in AD the salt
is the LHS of the UPN attribute when the password was last set).
But the unmatched RC4 keys is strange, you could derive the key
manually since its just an md4 hash with no salt, something like:
# echo -n password | iconv -t UTF-16LE | openssl dgst -md4
And compare with the key in the keytab:
# klist -Kekt krb5.keytab
HTH
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
