Windows LSA cache and Kerberos delegation

[Wang Weijun]

> On Oct 13, 2016, at 3:38 AM, Venkat Iyer (veniyer) <veniyer at 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