MIT Kerberos for Windows failing with Windows 10 update 1803?

[Ruurd Beerstra]

OK, I'm confused now....
2 days ago I tried FILE: by editing krb5.ini and setting default_cc_name 
to FILE:c:/tmp/krb5cc_${uid}
I saw it uses the SID for my user as part of the filename in c:/tmp.
I SAW the file being made, and it STILL refused to work the way it 
should. The ticket manager showed "FILE:.." in the "Credential cache" 
column.
I tried your API suggestion last night, saw "API: Initial default cache: 
in the ticket manager and it still did not work.

Then I tried again tonight, by using "kvno" to acquire a ticket. And all 
of  sudden, the host service ticket appears in the ticket manager!
Fire up IVT: It uses the ticket and logs in with Kerberized telnet and 
GSSAPI-over-SSH like it should.
Destroy the TGT and other tickets, restart IVT: It pops up the ticket 
manager, I type the proper password, tickets are acquired: Everything works.
No clue as to why it started working all of a sudden, but I'm happy!

So I wanted to go through the proper steps again so I could document it 
in IVT in case a user runs into this issue.
I change the krb5.ini file back to the default empty:
  Directory of C:\ProgramData\MIT\Kerberos5

19-06-2018  21:03    <DIR>          .
19-06-2018  21:03    <DIR>          ..
19-06-2018  21:04                 0 krb5.ini
                1 File(s)              0 bytes

Start the "MIT kerberos.exe", get a TGT: The Credential cache" still 
shows "API: Initial default ccache". Huh? Why does it not go back to MSLSA?
Reboot. No difference. API.
Search Registry for things called MIT and/od ccache: Found nothing relevant.
Search file system for things called krb5.ini: Nothing relevant.

So now it keeps working despite everything I try to break it. 
Admittedly, progress is made, but I want to understand what happens here!

Can someone here point me in the right direction?
Where am I supposed to configure MSLSA if I want to force the problem again?
Where does it store the current API setting?
What did I do wrong the time I tried the FILE: setting?

     Help very much appreciated,
     Ruurd



Op 18-6-2018 om 23:31 schreef 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.
>