6

I recently asked a question about some problems I was having getting MIT Kerberos to work nicely with Microsoft's LSA credentials cache.

I was told that setting the registry key AllowTGTSessionKey should fix the problem.

However, I'm still having problems, and now I dug a bit deeper.

Running klist tgt (using the klist provided by Microsoft in \windows\system32), it shows, among all the other output, this:

Session Key        : KeyType 0x17 - RSADSI RC4-HMAC(NT)
                   : KeyLength 16 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

So, the session key is still blanked out, even though that was the problem the registry key mentioned above was supposed to solve.

So which other conditions might lead to the session key being blanked out?

I've tried with all sorts of user accounts now (domain admins, domain users, with and without UAC enabled), and nothing seems to make a difference.

So, does anyone know what the problem might be? Or know of a solution (and/or ugly hacky workaround)

jalf
  • 243,077
  • 51
  • 345
  • 550
  • Did you already try the `kerbtray` tool from the Resource Kit? They use SSPI and access the key in memory. YMMV with GSS-API shim. – Michael-O Jan 18 '12 at 13:53
  • @Michael-O It works just like the `klist` supplied by the Resource Kit, afaik, and that shows all zeros. That makes sense, I suppose, in that the entire point in keeping the key secret is to keep it, well, secret. If it could be retrieved via SSPI, MIT Kerberos or other third parties could just do the same. – jalf Jan 18 '12 at 14:12

1 Answers1

1

Ok, looks like I have the (rather embarassingly silly) answer.

The registry key in question (AllowTGTSessionKey) is only read by Windows at startup.

So after setting it.... you have to reboot!

And then you get a valid session key.

jalf
  • 243,077
  • 51
  • 345
  • 550