Re: MIT Kerberos for Windows failing with Windows 10 update 1803?
On Sun, Jun 17, 2018 at 04:35:50PM -0400, Greg Hudson wrote: > 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. Does this mean that you think setting the appropriate entries under SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains would resolve the issue? -Ben 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/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
MIT Kerberos for Windows failing with Windows 10 update 1803?
Hi, I'm developer of a Windows SSH/Telnet client (called IVT) that supports both GSSAPI authentication and Kerberized telnet. I've noticed that the setup I use for regression testing now finds errors for both protocols: Login fails. After a lot of digging, I'm suspecting Windows 10 privacy update (1803) that was pushed to my development workstation a short while ago. 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. When I install a copy of the software on a Windows 7 Virtual Box machine (same network, same KDC, same user/principal, same IVT version, same Kerberos for Windows version 4.1, etc) it works flawlessly. I was about to go single stepping through my code to find the problem, but when I woke the PC to start work on that, I noticed that the MIT software itself has the same problem! This popup appeared: So that is Kerberos for Windows trying to refresh my credentials and running into the very same error. Apparently it cannot access the TGT either. I found this article https://www.csoonline.com/article/3253899/windows/the-best-new-windows-10-security-features.html about all sorts of new security features in Windows 10 and that sounds like Microsoft may have changed something that breaks Kerberos? When I use a sniffer on my network I can see that there is no communication between my Telnet client and the KDC when it is supposed to request a ticket for the host I'm logging in to. So there is no error logged on the KDC either (I jusyt see an entry when I login to get my TGT). Some details about the environment: - KDC is MIT version krb5-1.16.1 - kfw-4.1-amd64.msi, freshly (re)installed - Target is a Linux box with a ktelnetd on it, but all that does is saying "DO AUTH" and then when I try to get a ticket it fails. - PC is Windows 10 Home edition, version 1803 build 17134.112 Everything worked until about two weeks ago (1803 was installed on 5th of June). I can get my TGT: but that is all I ever see, no tickets for the host I'm trying to login to. Insights very much appreciated, please reply to ruu...@wxs.nl. Regards, Ruurd Beerstra Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
