Я изучаю единый вход Kerberos (SSO) для замены NTLM для веб-приложения, размещенного внутри домена Windows.
После создания имен участников службы (SPN) для тестовой службы (setspn -s) я ясно вижу - с помощью Fiddler или WireShark - что проверка подлинности переключилась с NTLM на Kerberos.
Имея осторожную команду разработчиков инфраструктуры, я хотел бы доказать, что от изменений можно быстро и легко отказаться. Я не хочу принудительно использовать NTLM через конфигурацию веб-сервера. Соответственно, SPN удаляются (setspn -d), и их удаление подтверждается (setspn -q).
Я запускаю следующую команду, чтобы удалить все сервисные билеты на клиенте:
C:\>klist purge
Current LogonId is 0:0x521ac
Deleting all tickets:
Ticket(s) purged!
C:\>
Когда происходит дальнейшее взаимодействие с веб-приложением, создается еще один билет службы, и Kerberos продолжает оставаться механизмом проверки подлинности единого входа. Это справедливо для пользователей, которые ранее не использовали эту услугу. Это происходит даже на следующий день после того, как все взаимодействие было простаиванием в течение ночи (12-14 часов).
Хотя я неоднократно пытался найти объяснение наблюдаемой настойчивости, я пришел с пустыми руками. Однако я думаю, что нашел ключ к разгадке в статье; Функция LsaLookupSids может возвращать старое имя пользователя вместо нового имени пользователя, если имя пользователя изменилось.:
Локальный орган безопасности (LSA) кэширует сопоставление между идентификатором безопасности и именем пользователя в локальном кэше на компьютере-члене домена. Кэшированное имя пользователя не синхронизируется с контроллерами домена. LSA на компьютере-члене домена сначала запрашивает локальный кэш SID. Если существующее сопоставление уже находится в локальном кэше SID, LSA возвращает кэшированную информацию об имени пользователя вместо запроса контроллеров домена. Такое поведение предназначено для повышения производительности.
Записи кэша истекают по тайм-ауту, однако есть вероятность, что повторяющиеся запросы приложений сохранят существующую запись кэша в действии в течение максимального времени жизни записи кэша.
Может ли кто-нибудь подтвердить, что Центр распространения ключей (KDC) кэширует записи SPN аналогичным образом (или предоставить альтернативное объяснение)? Если да, то каковы максимальные сроки жизни записи в кэше?
Я обнаружил проблему. Запись DNS для службы была не записью «A», а фактически записью «CNAME». Это означает, что браузер создавал ключ для учетной записи службы. Это связано с настройкой «useAppPoolCredentials» на сайте / сервере, которая была установлена в «False» (по умолчанию). SPN, в которые я вносил изменения, не принимали участие в аутентификации Kerberos, которая имела место.