Are there any plans to reimplement JAAS GSS on the windows platform to account for this issue:
Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an "empty" session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4) and Windows XP SP2.
Solution 2: You need to update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added--and set correctly--to allow session keys to be sent in the Kerberos Ticket-Granting Ticket.
Do you have any suggestion?
This MS "feature" does not allow a complete (and useful) Kerberos 5 credentials to be acquired from the LSA cache. Either you change the registry value, or you use a pure Java approach, this means calling kinit to get a non-LSA based cache, or providing username/password to Krb5LoginModule directly.
We've tried experiments to call Windows APIs to acquire service ticket (instead of TGT) from LSA. The service ticket does come with a non-zero session key so that GSS communications with the service can be performed. However, if you want to do credentials delegation you still have to get a FORWARDED TGT, and this time the session key is zero again. Delegation plays a very important part in Kerberos and GSS, to provide the same user experience on all supported platforms, we cannot go this way.
This is an old thread, but one of my clients has run into the same problem. Hopefully someone is still monitoring....
The answer is that the implementation should not be trying to do anything directly with keys. Delegation works just fine if it has been configured correctly in AD. Simply impersonate the context on the server side and then call the appropriate API to get a new service ticket and it will use the forwarded TGT. Credential delegation solved.
MS was correct to "fix" the session key interface since it allowed user code to attain a "password equivalent". The JAAS implementation should be fixed to use the Windows authentication interfaces correctly.
Feel free to contact me offline for more information or pointers at firstname.lastname@example.org (remove the no-spams).
I'm curious whether there is any alternative to changing the registry?
We have a java web start application that we want to use integrated windows authentication, then use kerberos to authenticate against the database.
From reading up on the subject for a couple of hours it seems that it should be possible - although it requires this registry change - or purchasing a commercial product.
If I've missed something - please let me know!
Thanks - Bryan