MIT Kerberos for Windows failing with Windows 10 update 1803?

[Greg Hudson]

On 06/18/2018 12:25 PM, Ruurd Beerstra wrote:
> I probably should have mentioned I tried setting the ccache type to
> "FILE", and that didn't work either.

Just "FILE"?  You need to set it to "FILE:pathname" for some pathname.

I don't have a hypothesis to explain why "API:" wouldn't work.  I 
updated a Windows 10 VM to 1803 and installed the kfw 4.1 MSI.  With the 
API: ccache type I was able to acquire tickets, renew tickets, acquire 
service tickets using kvno, and see the acquired service ticket with klist.

With the MSLSA: ccache type it does seem like I can't access the TGT 
session key.  I can acquire a TGT and can view it in the graphical 
ticket manager (but not with klist; not sure why).  Renewing the TGT 
doesn't appear to work, although I only see an error message if I run 
"kinit -R" from the command line (same error as you saw, "Matching 
credential not found"); with the graphical ticket manager it seems to 
silently fail.  I can obtain a service ticket and view that with klist, 
but from tracing output it is clear that that is happening through the 
LSA (which is probably able to find the realm I'm testing against using 
SRV records in DNS).

> A quick search on Credential Guard says: The Windows Defender Credential
> Guard prevents these attacks by protecting NTLM password hashes,
> Kerberos Ticket Granting Tickets, and credentials stored by applications
> as domain credentials.

To be clear, my uncomfirmed hypothesis is that update 1803 made the 
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos AllowTGTSessionKey 
registry variable inoperable, with or without Credential Guard.  An 
additional restriction on access to service ticket session keys does not 
seem to match the errors you're seeing.