Существует ли путь в Java или командной строке util для получения билета Kerberos для сервиса с помощью собственного API SSPI?

Я хочу реализовать Единую точку входа с Kerberos в Java и успешно сумел создать тикет для Сервиса с помощью билета от входа в систему Windows. К сожалению, я могу только создать тот тикет, когда Ключ реестра "allowtgtsessionkey" включен. Я получаю исключение с сообщением "Идентификатор, не соответствует математическому ожиданию (906)", как только я отключаю его. Ключ реестра документируется на http://java.sun.com/j2se/1.5.0/docs/guide/security/jgss/tutorials/Troubleshooting.html и http://support.microsoft.com/kb/308339.

К сожалению, у меня нет доступа к реестру на компьютерах, где мое приложение будет использоваться, таким образом, я буду искать способ сделать это, не имея необходимость изменять его. Когда я делаю Единую точку входа по SPNEGO в Internet Explorer или Mozilla Firefox, они создают Сервисный тикет в моем кэше билета, таким образом, определенно должен быть способ сделать это, не устанавливая ключ реестра. У кого-либо есть идея, как сделать это в Java?

Спасибо за Вашу справку, memminger

Обновление: Я разочаровываюсь в этой проблеме. Ключ реестра Windows предотвращает доступ к Билету (более точно: Предмет) в кэше Билета. Java в Windows использует свою собственную реализацию GSSAPI, и я предполагаю что доступ потребностей к Билету создавать Сервисный Тикет. Windows API SSPI, хотя имеет полный доступ к кэшу Билета и может таким образом создать Сервисные тикеты. Этот API используется веб-браузерами, но он не используется Java (согласно http://java.sun.com/developer/technicalArticles/J2SE/security/#3). Когда я отключаю SSPI в Firefox, получив доступ к веб-странице однажды (таким образом, сервисный тикет был создан), я могу все еще получить доступ к странице, поэтому возможно, командная строка util была бы достаточна, который создает сервисный тикет с помощью API SPPI.

Для нас это означает теперь, когда мы можем или отказаться от Единой точки входа (который недопустим для нас), или что мы делаем аутентификацию на стороне клиента нашего приложения (потому что мы можем только считать имя пользователя, но не проверить билет на сервере), который является главной угрозой безопасности. Другой пример того, как более сильные ограничения безопасности приводят к большим дырам в системе безопасности, потому что они становятся слишком сложными для использования.