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