> On Oct 13, 2016, at 3:38 AM, Venkat Iyer (veniyer) <veni...@cisco.com> wrote: > > Do you know if the problem of obtaining TGT session key on Windows from LSA > credential cache is resolved (see snippet below)?
I am not sure. Sometimes you just cannot get the session key. One way to check this is to run Microsoft's own klist.exe tool. If "klist tgt" shows a non-zero session key, then Java can also get it. Otherwise, we don't have a good solution now. Hope this helps. --Weijun > Microsoft has not been able to provide any guidance on steps to make it work. > These steps below haven’t helped: > • Turn off UAC > • Remove Service Account for application from local administrators group > • Set the registry key “allowtgtsessionkey” to true > We need delegation support through the application to underlying Kerberized > systems. > > This reference was very useful to troubleshoot the issues. > http://cr.openjdk.java.net/~weijun/special/krb5winguide-2/raw_files/new/kwin > Known Issues > > If an AD account is also added into local administrator group on the > client PC, Microsoft restricts such client from getting the session key > for tickets (even if you set the allowtgtsessionkey registry key to 1). > The workaround is: Just forget you're a logged in user, call kinit.exe. > Do not depends on LSA credential cache. > > In a recent hotfix ([35]http://support.microsoft.com/kb/942219/en-us, > should be included in Vista SP1), this restriction is lifted for normal > service tickets. However, it still applies to TGT. Since Java uses TGT > to acquire tickets for other services (the standard Kerberos process), > this update provides no benefit to JGSS programming on Windows. > Furthermore, even if the implementation of Java is changed to read > service tickets from the LSA cache, it still cannot perform delegation, > since a TGT is always needed in that case. > > > Appreciate any help. > Thanks > Venkat
