Оглавление
Столкнулись с интересным багом, на некоторых компьютерах в офисе перестали обновляться групповые политики. Дело оказалось в корпоративном антивирусе DrWeb.
Windows 10. DrWeb Enterprise 13.
Решение
В панели управления антивирусом:
Откройте Антивирусная сеть – станция или группа – слева в разделе Конфигурация – Превентивная защита – Поведенческий анализ – Исключения – Пути к приложениям – карандаш – укажите путь до файла C:\Windows\System32\svchost.exe – установите галочку в колонке “Разрешать” для строки “Низкоуровневый доступ к диску” – Сохранить – Сохранить.
После этого служба gpsvc сможет обновить файл C:\ProgramData\ntuser.pol и политики обновляются при перезагрузке ПК.
Диагностика
В процессе разбора:
Включаем отладочный журнал обработки GPO на клиентах:
https://winitpro.ru/index.php/2016/10/11/otladochnyj-zhurnal-obrabotki-gpo-na-klientax-gpsvc-log/ – Отладочный журнал обработки GPO на клиентах — gpsvc.log
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x00030002 /fПосле перезагрузки получаем лог обработки групповой политики:
%WINDIR%\debug\usermode\gpsvc.log
Его удобнее просматривать утилитой policy_reporter4_2, которую сейчас фиг найдешь на просторах Интернета, но и простой Notepad++ тоже сработает.
В файле gpsvc.log видим что новая политика отрабатывает корректно, но в какой то момент после нее в дело вступает файл tempntuser.pol, который перезатирает новые параметры внесенные политикой на старые.
Понадобилось время чтобы найти что это за tempntuser.pol такой:
https://decoder.cloud/2020/10/24/when-ntuser-pol-leads-you-to-system/ – When ntuser.pol leads you to SYSTEM
А вот объясняется как вообще должны взаимодействовать новые групповые политики с кэшем:
https://sdmsoftware.com/security-related/understanding-the-registry-policy-archive-file/ – Understanding the Registry Policy Archive File
То есть, каждый раз при применении групповых политик на компьютере служба gpsvc удаляет данные которые находятся в четырех ветках реестра указанных в статье, а затем наполняет файл ntuser.pol новыми параметрами из групповых политик, которые применяются через файл tempntuser.pol который в конце удаляется.
В нашем же случае файл не изменялся в конце этого действа, дата изменения файла не менялась и если внутрь его залезть утилитой Registry.Pol Viewer 1.5 Utility с того же сайта:
https://sdmsoftware.com/389932-gpo-freeware-downloads/ – Group Policy Freeware Utilities
то старый адрес сервера был виден невооруженным взглядом.
То есть, все работало как и должно за исключением изменения файла C:\ProgramData\ntuser.pol. Почему?
В процессе раскопок нашлась вот такая интересная статья:
https://borncity.com/win/2020/01/10/windows-10-v1909-and-a-possible-gpo-issue-part-2/ – Windows 10 V1909 and a possible GPO Issue – Part 2
Интересная она тем, что ошибка 0x80004005 также встречалась и в наших логах:
ProcessGPOs(Machine): Extension Реестр ProcessGroupPolicy failed, status 0x80004005.
Причем, в статье она рассосалась сама, но человек дал наводку о том, что он обновлял сигнатуры встроенного антивируса Windows Defender, но точно не знает помогло ли именно это.
В нашем случае установлен DrWeb, который забирает на себя антивирусную роль и блокирует работу штатного антивируса, что и натолкнуло на мысль о том, что именно Зеленый Паук блокирует обновление так нужного нам файла.
И это сработало, после удаления антивируса на 2х станциях и перезагрузки ПК файл C:\ProgramData\ntuser.pol успешно обновился а новая групповая политика перезаписала параметры WSUS.
Осталось разобраться с поддержкой DrWeb что это было и как сделать, чтобы групповые политики обновлялись корректно на всех компьютерах компании без удаления антивируса.
Поддержка DrWeb дала решение из начала статьи.