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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
