Re: Kerberos for Windows MSLSA Cache
On Fri, 6 Mar 2015, Christopher Penney wrote: On Fri, Mar 6, 2015 at 12:44 PM, Benjamin Kaduk ka...@mit.edu wrote: I believe I have fixed these bugs in the krb5 development branch, but they have not made it into a new KfW release yet. If you are interested in building KfW from the latest sources, I would be interested to hear if that resolves your problems. That's good to know, thanks. I might try that though I'm not much of a developer. Is there any ETA (even if rough) for when this would make it to a released version? It seems that some demand from this is appearing from other places as well, so it will make its way higher on my priority list. There is another feature wanted for the next KfW release (better screen reader support), so the ETA is still measured in months; I would ballpark 2 months until a beta release, but that is a very rough estimate and could change a lot. I'm also experiencing a problem where (using either MSLSA: or a file for the CC) I can renew tickets just fine from a cmd window using 'kinit -R, but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I get the following in event viewer: I am less sure about this issue. It is possible that it is related to the UAC permissions mentioned above, but it may be a different issue. I should have noted this in the original note, but it seemed like it used to work (we've been using KfW for about 6 months), but recently broken. The user sample size is really small here though so it's hard to tell. Is there anything I can do to help pin it down (e.g. debugging flags I'm not aware of)? Most of the debugging flags are set at compile time. The KRB5_TRACE environment variable does work (as on Unix krb5), but I don't expect it to provide any useful output for this situation. Debugging runtime crashes is usually easiest with the help of a debugger, but the release versions do not include debugging symbols. If you want have visual studio around and want to try, I can see about sending the debug symbols to you. -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for Windows MSLSA Cache
Hi Chris, On Fri, 6 Mar 2015, Christopher Penney wrote: I run a Linux environment that's setup in an MIT Kerberos Realm. That realm has a one way trust setup that allows tickets for Active Directory principals (from Windows 7 clients) to be accepted as authentication (for SSH and ODBC for Hadoop/Hive). I'm having two problems. The first problem I'm having is that Windows 7 users using Kerberos for Windows 4.01 do not seem to be able to use their AD ticket in the MSLSA cache. If I set KRB5CCNAME to a file and obtain an AD ticket independently of MSLSA everything works fine. With KRB5CCNAME set to MSLSA: it does not work. I did find a note about setting AllowTGTSessionKey to 1, but that's already been done (and rebooted). Is there a way to use the AD tickets stored in MSLSA using MIT KfW? I assumed it was possible looking at the release notes where it says Integration with the Windows LSA credentials cache, but maybe that's not the case. There are several bugs in KfW 4.0.1 (previous versions) with the MSLSA handling; several operations on the cache (lcc_resolve() and lcc_get_principal(), at least) were attempting to retrieve the full TGT in order to get the client principal's name in the cache. However, the full TGT is not actually necessary to obtain the client's name. When UAC is enabled, attempting to retrieve the TGT from the LSA fails, so the cache is essentially unusable. Disabling UAC is a (not very appealing) workaround. I believe I have fixed these bugs in the krb5 development branch, but they have not made it into a new KfW release yet. If you are interested in building KfW from the latest sources, I would be interested to hear if that resolves your problems. I'm also experiencing a problem where (using either MSLSA: or a file for the CC) I can renew tickets just fine from a cmd window using 'kinit -R, but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I get the following in event viewer: Faulting application name: MIT Kerberos.exe, version: 4.0.1.2, time stamp: 0x50c22fb6 Faulting module name: MSVCR100.dll, version: 10.0.40219.325, time stamp: 0x4df2bcac Exception code: 0xc005 Fault offset: 0x0003c560 Faulting process id: 0x1828 Faulting application start time: 0x01d05782975e269d Faulting application path: C:\Program Files\MIT\Kerberos\bin\MIT Kerberos.exe Faulting module path: C:\Windows\system32\MSVCR100.dll Report Id: 631e69e6-c3c7-11e4-92c0-180373cb2112 The exception code points to some kind of access issue, but I can't seem to see what it is. Watching it with Process Monitor wasn't very interesting, but I'm not an expert. If I run MIT Kerberos.exe -renew it gives the message There was an error renewing tickets!. I am less sure about this issue. It is possible that it is related to the UAC permissions mentioned above, but it may be a different issue. -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos for Windows MSLSA Cache
On Fri, Mar 6, 2015 at 12:44 PM, Benjamin Kaduk ka...@mit.edu wrote: I believe I have fixed these bugs in the krb5 development branch, but they have not made it into a new KfW release yet. If you are interested in building KfW from the latest sources, I would be interested to hear if that resolves your problems. That's good to know, thanks. I might try that though I'm not much of a developer. Is there any ETA (even if rough) for when this would make it to a released version? I'm also experiencing a problem where (using either MSLSA: or a file for the CC) I can renew tickets just fine from a cmd window using 'kinit -R, but the MIT Kerberos.exe sys tray tool crashes when it tries to renew. I get the following in event viewer: I am less sure about this issue. It is possible that it is related to the UAC permissions mentioned above, but it may be a different issue. I should have noted this in the original note, but it seemed like it used to work (we've been using KfW for about 6 months), but recently broken. The user sample size is really small here though so it's hard to tell. Is there anything I can do to help pin it down (e.g. debugging flags I'm not aware of)? Chris Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos