Как проверить сервисные учётные записи со SPN перед ужесточением Kerberos: инвентарь, события выдачи билетов, msDS-SupportedEncryptionTypes и безопасный canary без массового отключения RC4.
Не путайте finding и подтверждённый трафик
Сканер может отметить учётную запись со SPN из-за атрибута, возраста пароля или предполагаемой зависимости от RC4. Это повод для инвентаризации, а не доказательство, что сервис сейчас получает только RC4-билеты. Сохраните правило finding, список типов учётных записей и владельцев сервисов, но не публикуйте SPN и доменные имена. Затем сопоставьте объект с журналами KDC и реальным окном использования, иначе неактивная запись и критичный production-сервис будут выглядеть одинаково.
Проверьте четыре независимых условия
Для каждой сервисной учётной записи нужны: корректный уникальный SPN, поддержка AES операционной системой и приложением, наличие современных AES-ключей после подходящей смены пароля и допустимые encryption types в политике и атрибутах. Один msDS-SupportedEncryptionTypes не подтверждает все четыре пункта. Windows Server 2025 рекомендует управлять разрешёнными типами через Group Policy, а не старый локальный registry key. Сначала снимите read-only инвентарь, ничего не меняя.
Используйте события выдачи сервисных билетов
События Kerberos на контроллерах домена позволяют увидеть сервис, клиента, тип шифрования и результат запроса; точный набор полей зависит от версии и аудита. Наблюдайте полный бизнес-цикл, включая ночные задания, а не пять минут после входа администратора. Сгруппируйте по сервисной учётной записи и типу билета, обезличив пользователей. Если RC4 не наблюдался, это снижает риск, но не доказывает отсутствие редкого клиента; владелец приложения всё равно подтверждает совместимость.
Проведите canary без доменного переключателя
Выберите некритичный сервис с владельцем, тестовым клиентом и проверенным rollback. Обновите приложение и ключевой материал по его документации, убедитесь, что учётная запись получила AES-ключи, и ограничьте изменение только этим объектом или тестовой политикой. Проверьте выдачу билета, взаимную аутентификацию и бизнес-операцию, затем откатите при KDC errors или fallback. Не отключайте RC4 на всех контроллерах как диагностический тест: отказ затронет сразу несколько неизвестных зависимостей.
Готовность означает чистое окно наблюдения
Перед широкой политикой составьте список всех SPN-аккаунтов, владельцев, паролей или gMSA-ротаций, наблюдаемых encryption types, исключений с датой удаления и результат canary. Microsoft message center указывает на переход hardening, поэтому отсрочку нельзя превращать в постоянное разрешение слабого типа. Критерий остановки — неизвестный владелец, старое приложение без теста, RC4 в рабочем билете или отсутствие rollback. Такой объект остаётся в плане миграции, а не маскируется общей политикой.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Windows Server; SPN, домены и имена сервисов не использовались.
Источники и проверка
- Microsoft Learn — обзор Kerberos в Windows Server проверено 2026-07-29
- Microsoft Learn — Windows message center Kerberos hardening проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.