Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
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@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
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
Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
Hi, Thanks for the quick reply. The first screenshot showed a popup from MIT Kerberos (Title "Kerberos Five") saying: Matching credential not found. Kerberos error -1765328243. krb5_get_renewed_creds() failed. The 2nd was the ticket manager showing just my TGT and nothing else. I probably should have mentioned I tried setting the ccache type to "FILE", and that didn't work either. I tried "API" just now (didn't know that one), the ticket manager shows "API: Initial default ccache" in its "Credential cache" column. But no joy: IVT and Putty both fail to use GSSAPI, and IVT also fails on Kerberized telnet. Tried reboot of my workstation: No change. Both IVT and Putty cause the ticket-manager to pop up to obtain new credentials, because they do not see my TGT (and so allow me to obtain one). The AllowTGTSessionKey is set in the registry, value 1. 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. And that sounds like exactly my problem. I can't find any way to turn that protection off. I don't understand why a FILE: or API: based ccache would be affected by this Credential Guard, but I can't get any GSSAPI or Kerberized telnet session to work anymore. And up until recently (I have automated regression tests fror IVT) that was not a problem. Bedtime here now, maybe more tomorrow, Thanks again, Ruurd Op 17-6-2018 om 22:35 schreef Greg Hudson: > On 06/17/2018 02:02 PM, Ruurd Beerstra wrote: >> The symptoms are that I can obtain a TGT from my KDC (which ends up in >> de LSA of Windows), but every attempt to use that TGT to obtain a >> service ticket yields an error: >> Matching credential not found. > > Unfortunately, our mailing list server doesn't pass through > attachments, so while I briefly saw your screenshots before moderating > through your message, they didn't make it to the list (and I didn't > keep a copy.) > > I believe the correct short answer is to use the "API:" ccache instead > of the "MSLSA:" ccache for this setup. > > For some time Windows has restricted access to TGT session keys in the > LSA, which means our libkrb5 code can't use a TGT from the LSA to get > service tickets. Instead, our MSLSA ccache type requests service > tickets via Windows, but that only works if the realm is set up in the > LSA configuration. Since you are using an MIT krb5 KDC, I am guessing > that it is not set up in the LSA configuration, so we fall back to > trying to get service tickets using the TGT. > > The TGT session key restriction can be overridden by the registry > value HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos > AllowTGTSessionKey, which I believe our installer sets. I would not > be surprised if update 1803 disables this registry value so that the > restriction is always in effect. > > I have also heard that Microsoft plans to disable access to service > ticket session keys from userspace, effectively preventing KfW from > using the LSA ccache. I don't know if that restriction is present in > update 1803, and I believe it only applies if Credential Guard is > enabled. (I don't know what determines whether Credential Guard is > enabled.) We could conceivably work around this restriction in the > GSSAPI library by getting context establishment tokens via SSPI > instead of via our krb5 code, but I can't make any promises as to when > that might be implemented. I don't believe this is the restriction at > issue in your test setup anyway. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
