Kerboros кэшированный билет удален после использования экрана блокировки Windows

Question

Есть ли способ остановить кеширование кеш-кера Kerboros после того, как Windows войдет в экран блокировки.

При первом входе в Windows, klist.exe показывает 2 кэшированных билета. Однако после того, как есть событие блокировки Windows, klist.exe показывает, что 0 кэшированных билетов.

Заранее спасибо.

Answer 1

Это по дизайну. Невозможно предотвратить, чтобы билет (ы) службы Kerberos не был очищен после блокировки экрана. Как только вы снова получите доступ к новому ресурсу, защищенному Kerberos, появится новая процедура проверки подлинности и появятся новые билеты. Важно понимать различие между билетами Kerberos - есть два типа: билет на выдачу билетов (TGT) и билет на обслуживание (ST). Вы можете убедиться, что Kerberos TGT остается в кеше клиента и не очищается после блокировки экрана , если ваш компьютер участвует в домене Active Directory и, вы делаете так называемое изменение групповой политики, чтобы изменить поведение (см. примечание ниже). Если вы не являетесь администратором Active Directory, вам нужно будет связаться с ними, чтобы они сделали это за вас. Чтобы сохранить TGT после блокировки экрана, откройте редактор консоли управления групповыми политиками, найдите объект групповой политики, который связан с машиной, и установите политику, чтобы не требовать контакта с контроллером домена, чтобы разблокировать машину. Это обеспечит сохранение кэшированной Kerberos TGT для повторной аутентификации. Даже если вы настроите групповую политику таким образом, билет службы Kerberos, выпущенный для вашего веб-сервера, не будет сохранен. Опять же, в этом сценарии только TGT остается в кеше Kerberos машины после разблокировки рабочей станции, никакие служебные билеты (например, выпущенные для сетевых ресурсов) не останутся. Но для вас это может позволить запросить ST более легко, так как TGT не требуется повторно запрашивать. Хотя вы можете попробовать столько, сколько хотите на стороне сервера приложений, чтобы программировать вокруг этого, на самом деле нет способа контролировать общее поведение безопасности Kerberos на стороне клиента со стороны приложения.

Все ниже этой части ответа и является EDIT, сделанным в ответ на последующий комментарий. Пожалуйста, не делайте никаких изменений в политике контроллеров доменов по умолчанию, поскольку политика будет применяться только к контроллерам домена. В качестве примечания, всякий раз, когда я лично делаю новое изменение групповой политики в домене Active Directory, если я не очень хорошо знаком с конкретным параметром, мне нравится создавать новый объект групповой политики, назовите его в соответствии с изменением настройки. а затем привязать его к OU, где находятся компьютер или пользовательский объект (ы). Кроме того, вы также можете связать объект групповой политики на уровне домена, если считаете, что изменение считается «безопасным» и не будет продавать и негативно влиять на всех.

1. Для этого откройте редактор консоли управления групповыми политиками и создайте новый объект групповой политики.
2. Назовите его Cached Logons Allowed.
3. Редактировать Cached Logons Allowed GPO.
4. Перейдите к Конфигурация компьютера> Политики> Параметры Windows> Параметры безопасности> Локальные политики> Параметры безопасности> и настроить обе следующие:

Интерактивный вход в систему: Количество предыдущих подключений к кэшу (в контроллер домена случай не доступен): 1 вход в систему

Интерактивный вход в систему: Требовать проверку подлинности на контроллере домена для отмены блокировки компьютера: DISABLED

Затем перезагрузите клиентскую рабочую станцию ​​2-3 раза. Технически вы можете выполнить команду gpupdate/force, но я обнаружил, что для некоторых параметров, особенно этого, клиентской рабочей станции требуется не только перезагрузка, но иногда 2, может быть, даже 3 перезагрузки из-за еще одного Настройка GPO под названием Оптимизация быстрого входа в систему. Во всяком случае, эта история для другого потока.