Windows 10 21H1: раскатываем через WSUS и смотрим на Credential Guard
Windows 10 21H1 вышла с улучшениями WFH-функций и новыми GPO. Раскатываем через WSUS в тестовой группе и разбираем изменения в Credential Guard для Kerberos-инфраструктур.
Выход Windows 10 21H1 с улучшениями WFH-функций, групповыми политиками и изменениями в Windows Defender Credential Guard
Microsoft выпустила Windows 10 21H1 - обновление вышло тихо, без больших анонсов. По меркам фичевых релизов скромно: список изменений короче, чем в прошлогодних версиях. Но в enterprise-контексте «скромно» не означает «не трогать» - особенно когда речь идёт о Credential Guard и новых групповых политиках. Раскатываем через WSUS на тестовой группе и смотрим, что реально изменилось.
Что вошло в 21H1
Основные изменения в этом релизе три.
Windows Hello for Business. Multi-camera support - наконец-то несколько камер в системе не вызывают конфликта при биометрии. Специфичная история, но в корпоративных ноутбуках с dokстанцией и внешней веб-камерой раньше возникали неприятные ситуации. Теперь можно явно указать камеру для Windows Hello в политиках.
Windows Defender Application Guard. Ускоренная инициализация изолированного контейнера - Microsoft называет это «performance improvements for Application Guard». На практике это означает, что изолированный Edge поднимается быстрее. Для тех кто реально использует WDAG для работы с недоверенными ссылками - заметный сдвиг.
WMI Group Policy. Новые политики для управления настройками через ADMX. В этом релизе добавили несколько политик, связанных с удалённой работой: управление фоновым размытием в Teams и Zoom на уровне системы (через реестр, который теперь покрыт GPO), настройки камеры для видеоконференций на уровне политик.
WFH-история в 21H1 - это скорее «закрытие долгов», накопившихся за год удалёнки. Не революция, но приятно что Microsoft это наконец оформила в политики, а не в ручные рекомендации по реестру.
Credential Guard: что изменилось и почему нас это волнует
Это самая важная часть для наших конфигураций. В 21H1 Microsoft изменила условия включения Windows Defender Credential Guard на совместимых устройствах.
Если коротко: на устройствах с Windows 10 Enterprise и Education, которые соответствуют аппаратным требованиям (UEFI, TPM 2.0, VBS), Credential Guard теперь включается по умолчанию - без явного действия администратора. Это касается новых установок и апгрейдов на 21H1 при наличии подходящего железа.
Для большинства сред это хорошая новость - LSASS в изолированном VBS-процессе, дамп хэшей стандартными средствами заблокирован аппаратно. Мы об этом писали применительно к Windows Server 2022 Preview - там та же механика.
Но у нас есть несколько клиентских конфигураций с Kerberos, где Credential Guard создаёт специфическую проблему.
Kerberos DES и RC4. Credential Guard блокирует использование DES и RC4 шифрования для Kerberos-билетов. Это правильно с точки зрения безопасности - оба алгоритма устарели. Но если в инфраструктуре есть старые сервисы или appliance-устройства, которые умеют только в RC4, - после апгрейда они перестают нормально аутентифицироваться. Kerberos с этими устройствами ломается.
Kerberos constrained delegation (KCD) с определёнными конфигурациями. Если используется классический KCD (не RBKCD), и в цепочке есть сервисы, которые не поддерживают Kerberos Armoring (FAST), - возможны проблемы. Протокол остаётся рабочим, но нужно проверять.
NTLMv1. Credential Guard принудительно блокирует NTLMv1. Если где-то в инфраструктуре ещё живёт NTLMv1 (старые файловые шары, принтеры, legacy-сервисы) - это вскроется после апгрейда.
На наших тестовых машинах (небольшая группа из пилотного кольца WSUS) мы увидели это прямо: один сервисный аккаунт, который использовался для подключения к legacy-системе через NTLM, перестал работать. Потребовалось перейти на NTLMv2 на той стороне - благо там это поддерживалось, просто не было включено.
Как мы организуем раскатку через WSUS
Схема стандартная, но расскажем как устроено у нас для клиентов на managed-сопровождении.
WSUS-кольца по группам компьютеров:
- Пилот - несколько машин из IT-команды клиента, обновляются сразу после выхода релиза. Задержка около недели от выхода обновления.
- Ранний прод - 10-15% парка, преимущественно «продвинутые пользователи» и те кто согласился. Задержка 2-3 недели от пилота.
- Основной прод - всё остальное. Раскатка начинается после того как ранний прод отработал без критичных проблем.
- Критичные системы - машины на специфичных задачах, аудиторы, юристы со специфичным ПО. Максимальная задержка, ручное тестирование совместимости.
Для 21H1 мы дополнительно добавили проверку Credential Guard перед апгрейдом каждой группы. На пилоте собрали список сервисных аккаунтов и сервисов, которые используют NTLM или Kerberos с нестандартными настройками. На тестовых машинах проверили, не сломается ли что-то. Потом уже раскатываем остальное.
Статус на сейчас
Пилотная группа отработала нормально. В одной конфигурации нашли Kerberos RC4 на принтерных очередях - там потребовалась настройка на стороне print server. В остальном - чисто.
Ранний прод начинаем на следующей неделе. До основного прода - скорее всего ещё пара недель. По итогам раскатки основного прода обновим этот пост или напишем отдельно, если вылезет что-то неожиданное.
Кто смотрит на 21H1 и использует Credential Guard - проверьте NTLM и Kerberos в своей инфраструктуре до апгрейда, а не после.