MIT Kerberos for Windows failing with Windows 10 update 1803?

[Benjamin Kaduk]

On Mon, Jun 18, 2018 at 05:31:33PM -0400, Greg Hudson wrote:
> 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 

I think the magic there is at
https://github.com/krb5/krb5/blob/master/src/windows/leash/KrbListTickets.cpp#L201

> 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).

My recollection was that you needed something in the registry (at
the path I mentioned in my previous mail) even to get the LSA to
look for SRV records.  (Do I know what realm you're testing with?)
IIRC the KfW installer does prepopulate KDC entries for a couple of
realms, as an example if nothing else.)

-Ben

> > 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 at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos