Я недавно задал вопрос о некоторых проблемах, которые возникали у меня с тем, чтобы MIT Kerberos хорошо работал с кэшем учетных данных LSA от Microsoft.
Мне сказали, что установка ключа реестра AllowTGTSessionKey должна решить эту проблему.
Однако, у меня все еще есть проблемы, и теперь я копнул немного глубже.
Запуск klist tgt (используя klist, предоставленный Microsoft в \windows\system32), он показывает, среди всехдругой вывод, такой:
Session Key : KeyType 0x17 - RSADSI RC4-HMAC(NT)
: KeyLength 16 - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Итак, ключ сеанса все еще не задан, хотя эту проблему должен был решить упомянутый выше ключ реестра.
Итак, какие другие условия могут привести к блокировке сеансового ключа?
Сейчас я пробовал использовать все виды учетных записей пользователей (администраторы домена, пользователи домена, с UAC и без UAC).включен), и, кажется, ничто не имеет значения.
Итак, кто-нибудь знает, в чем может быть проблема?Или знать решение (и / или уродливый хакерский обходной путь)