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: ghud...@mit.edu > To: zara...@live.com; kerberos@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 use...@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 1000cf332724dbd326348cf8bd4f640d14! ca39! > > 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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
