☰

Невозможно отключить единый вход Kerberos (SSO)

tag-icon • tag-icon active-directory iis-7.5 kerberos single-sign-on
Невозможно отключить единый вход Kerberos (SSO)

Я изучал возможность использования протокола единого входа (SSO) Kerberos для замены 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 продолжает быть механизмом аутентификации SSO. Это справедливо для пользователей, которые ранее не пользовались сервисом. Это происходит даже на следующий день после того, как все взаимодействие простаивало всю ночь (12-14 часов).

Хотя я и делал повторные поиски, чтобы найти объяснение наблюдаемой настойчивости, я остался с пустыми руками. Однако я думаю, что нашел подсказку в статье;Функция LsaLookupSids может возвращать старое имя пользователя вместо нового имени пользователя, если имя пользователя изменилось.:

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

Записи кэша имеют тайм-аут, однако есть вероятность, что повторяющиеся запросы приложений сохранят существующую запись кэша активной в течение максимального срока ее действия.

Может ли кто-нибудь подтвердить, что Key Distribution Center (KDC) кэширует записи SPN подобным образом (или предоставить альтернативное объяснение)? Если да, то каков максимальный срок жизни записи кэша?

решение1

Я обнаружил проблему. DNS-запись для сервиса не была записью "A", а на самом деле записью "CNAME". Это означает, что браузер создавал ключ для учетной записи сервиса. Это связано с настройкой "useAppPoolCredentials" на сайте/сервере, которая была установлена ​​на "False" (по умолчанию). SPN, в которые я вносил изменения, не принимали участия в аутентификации Kerberos, которая происходила.

Связанный контент