Недавно я задал вопрос о некоторых проблемах, с которыми я получал MIT Kerberos, чтобы хорошо работать с кешем учетных данных LSA от Microsoft.Что может привести к тому, что ключ сеанса Kerberos TGT в Windows будет все нули
Мне сказали, что установка раздела реестра 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), и ничто, кажется, не имеет значения.
Итак, кто-нибудь знает, в чем проблема? Или знаете решение (и/или уродливое хакерское обходное решение)
Вы уже пробовали инструмент 'kerbtray' из Resource Kit? Они используют SSPI и получают доступ к ключу в памяти. YMMV с прокладкой GSS-API. –
@ Michael-O Он работает так же, как 'klist', поставляемый Resource Kit, afaik, и это показывает все нули. Полагаю, это имеет смысл, поскольку вся суть сохранения секретности заключается в том, чтобы сохранить это, ну, секретно. Если он может быть получен через SSPI, MIT Kerberos или другие третьи стороны могут просто сделать то же самое. – jalf