NT hashes in krb5

[Zaid Arafeh]

Thanks Greg,
If I have the K/M key (which is in the database) and I have the password for the master key, would that make extracting hashes from the database easier?
I looked at the keytab file (thnx) , unfortunately keytab files usually don't store the krbtgt key (which is what I am looking for )


> Date: Mon, 19 Jan 2015 01:02:59 -0500
> From: ghudson at mit.edu
> To: zarafeh at live.com; kerberos at mit.edu
> Subject: Re: NT hashes in krb5
> 
> I'm removing kfwdev from the CC list as there is nothing specific to
> Kerberos for Windows about the question.
> 
> On 01/18/2015 08:10 PM, Zaid Arafeh wrote:
> > Here's the scenario. I am trying to get krb5 to use an NT hash. NT hash is merely the MD4 computation of the UTC-16LE of the password string (creates an RC4 key). I went ahead and configured the krb5.conf  and kdc.conf file to do so. here's the relevant part of the output of getprinc for a sample user called user01
> > 
> > Key: vno 7, aes256-cts-hmac-sha1-96, no salt
> > Key: vno 7, aes128-cts-hmac-sha1-96, no salt
> > Key: vno 7, des3-cbc-sha1, no salt
> > Key: vno 7, arcfour-hmac, no salt
> > Key: vno 7, camellia256-cts-cmac, no salt
> > Key: vno 7, camellia128-cts-cmac, no salt
> > Key: vno 7, des-hmac-sha1, no salt
> > Key: vno 7, des-cbc-md5, no salt
> > Key: vno 7, arcfour-hmac, Version 4
> > MKey: vno 1
> 
> That's a lot of enctypes.  The RC4 enctype ignores the salt, so you
> don't need to list it twice.  des-hmac-sha1 isn't even a standard
> enctype and shouldn't be used.
> 
> > Yet when I look at the database dump for this user, the output does not have any RC4 hashes. I am having a hard time understanding how the database is structure and how to extract the RC4 hash out of the database. Here's the dump (it's OK no secrets :) ). What's going on ?
> > 
> > kdb5_util load_dump version 7
> > princ    38    13    4    9    0    user01 at TR.LAB    0    86400    0    0    0    0    0    0    3    24    12345c010000000000000000000000000000000200000000    2    22    6e52bc547a6169642f61646d696e4054522e4c414200    8    2    0100    1    4    9d51bc54    1    7    18    62    200040ca06f69ec3eba54fd201d6708ff545149d16c717d819135fb0c2f1c6effab5b4eaa6db55587e6c3ab1aedb5a751b5b7d7e43af4b515d662ec15f09    1    7    17    46    1000ad590e445fc7b963f9ccab7406cb17605c47da2c39b5d7f9ba8fccea3530e9d27abcc64d7134a8af31bf849c    1    7    16    54    1800f3ca96a9e0bfb52a40f41da1197dd6fb543ce769ba205220a4c654cece5a5018b7178feeacd7eaa8610f1bf3d91e1e8dc753052a    1    7    23    46    10005073cf4396c6b9bc26c33dd28a928fb88569ad76699aaa5dfcd28d00aae268441389477e130e26e3fc86aa83    1    7    26    62    2000a259382f778327fc81a6cac1e26b7151c900fd6e5e0c5b9f0a15ad4aaf32d397cd328430de83706ec3c7d6caa90e06c5d1b8fd412f7b2757bf5484c5    1    7    25    46    1000cf332724dbd326348cf8bd4f640d14ca39!
> >  2fbb898eb4529cb5338b42f710b7a42e3ddee68d5459f4abb5cbda    1    7    8    38    08002f561ad30e78fffe79319aafa6f87ef2beb93545c7e9c476e7e5150f1da7ed059471a81a    1    7    3    38    0800d602ff8c2fc404838a2edce7580501116cf8f0e705a577a4a322f5bf80fc97342df86725    2    7    23    46    1000e006190a5eaf6279e30ad541279be4ab3f02332ad84e356487acc44b24131f28a0576d224eab74e5b5803320    1    0    -1    -1;
> 
> The key data are represented as triplets: enctype, length, and the
> hex-encoded data itself.  For instance, 18 62 2000.... is the AES2562
> key.  (The mapping of enctypes to numbers can be found at
> http://www.iana.org/assignments/kerberos-parameters/kerberos-parameters.xhtml#kerberos-parameters-1
> .)
> 
> However, this won't easily help you.  Kerberos key data in a dump file
> (and in the database itself) is encrypted in a master key which isn't
> part of the dump.
> 
> You are probably better off extracting a keytab (with ktadd -norandkey
> in kadmin.local) and then examining a hex dump of the keytab.  The
> keytab format is described here:
> 
> http://www.gnu.org/software/shishi/manual/html_node/The-Keytab-Binary-File-Format.html