Групповые политики Group Policy остаются основным способом централизованного управления конфигурацией Windows-компьютеров в корпоративных доменах Active Directory. Администратор один раз описывает требуемые настройки в объекте групповой политики, связывает его с нужным контейнером каталога, и десять тысяч рабочих станций, серверов и ноутбуков применяют эти настройки автоматически, без отдельной работы с каждой машиной. Механизм работает уже много лет, хорошо изучен, предсказуем и встроен в саму операционную систему, поэтому даже организации, которые переносят управление устройствами в облачные службы, продолжают поддерживать инфраструктуру GPO для своих стационарных парков.
Архитектура хранения объектов политики
Объект групповой политики физически не существует в одном месте. Он распределён между двумя компонентами, которые синхронизируются независимо. Первый компонент называется Group Policy Container, это запись в каталоге Active Directory, размещаемая в контейнере System внутри доменного раздела. В нём хранятся атрибуты объекта: имя, уникальный идентификатор GUID, версия, состояние и список расширений, которые использует данный объект. Репликация этой части выполняется стандартным механизмом репликации каталога между контроллерами домена. Второй компонент называется Group Policy Template, это набор файлов и папок в общем сетевом каталоге SYSVOL на контроллере домена. Файлы располагаются по пути с GUID политики, внутри размещены сценарии, установочные данные для программ, файлы с параметрами административных шаблонов и другие материалы. SYSVOL реплицируется между контроллерами службой DFS Replication или унаследованной службой FRS в старых доменах.
Из-за такого разделения возникает практический момент: каталог и файловая система реплицируются по разным расписаниям, поэтому версия GPO по данным каталога может кратковременно отличаться от версии по данным SYSVOL. Клиент сравнивает обе версии и дожидается совпадения, прежде чем считать политику актуальной. Администратор, который обновил политику и не видит эффекта на удалённой площадке, часто наблюдает именно задержку репликации, а не ошибку в самой политике.
Цикл применения на клиенте
Клиентская часть сервиса Group Policy запускается при каждом старте компьютера и при каждом входе пользователя. Кроме начального применения существует фоновое обновление: служба сама пересматривает применимые настройки примерно каждые девяносто минут со случайным смещением до тридцати минут. Случайное смещение существует специально, чтобы тысячи машин не обращались к контроллерам домена одновременно. На контроллерах домена интервал короче и составляет около пяти минут.
Важное различие внутри цикла называется foreground и background обработка. Foreground-обработка происходит синхронно при старте машины или входе пользователя, и пользователь наблюдает задержку с системным сообщением. Background-обработка идёт незаметно в фоне. Некоторые расширения политики вообще не выполняются в фоновом режиме: установка программ, настройка папок перенаправления и ряд других сценариев требуют именно foreground-прохода. Именно поэтому администратор иногда вынужден просить пользователей перезагрузиться: часть настроек не применится иначе ни через какое время ожидания. Команда gpupdate с параметром /force заставляет клиента заново применить все политики, не дожидаясь интервала, но и она по умолчанию делает это в фоновом режиме. Те же ограничения действуют: параметры, требующие синхронной обработки, команда предложит применить через завершение сеанса или перезапуск, выводя соответствующий вопрос после выполнения. Дополнительные параметры /logoff и /boot форсируют выход и перезагрузку принудительно.
Порядок LSDOU и наследование
К объекту пользователя и компьютера применимо множество объектов политики, поэтому система выстраивает строгий порядок. Сначала применяется локальная политика самой машины, затем политики сайта, затем политики домена, затем политики подразделений от верхнего уровня к нижнему. Мнемоника LSDOU означает Local, Site, Domain, OU. Внутри одного контейнера несколько связанных GPO обрабатываются по порядку связи, начиная с наибольшего порядкового номера и заканчивая первым. Общее правило звучит так: настройка, применённая позже, перезаписывает настройку, применённую раньше. Практический вывод состоит в том, что объект, связанный с самым глубоким подразделением, обычно побеждает в конфликтах с доменными и сайтовыми политиками.
Из этого следует естественная модель наследования: дочернее подразделение получает все политики предков и добавляет свои. Для нестандартных случаев предусмотрены инструменты управления потоком. Блокировка наследования на уровне подразделения отсекает все политики вышестоящих уровней, кроме тех, что принудительно включены. Признак Enforced на связи GPO делает политику непобедимой: она перебивает блокировки и конфликтующие установки нижних уровней. Если нужно, чтобы политика применялась не ко всем объектам подразделения, а только к выборочным, используются два механизма фильтрации. Security filtering выбирает применение по членству в группах безопасности: у объекта должно быть право чтения и применения политики. WMI-фильтры выполняют запрос на языке WQL прямо на клиенте и решают, подходит ли машина под условие. Типовой пример выбирает только ноутбуки, только системы определённой версии или только машины с достаточным объёмом памяти. WMI-фильтр вычисляется при каждом обновлении, что добавляет небольшую стоимость к обработке.
Client Side Extensions и административные шаблоны
Движок групповой политики модульный. Каждый тип настроек обрабатывает отдельное клиентское расширение Client Side Extension, это библиотека на машине, которая понимает свой формат данных. Существуют расширения для реестра, прав безопасности, сценариев, сопоставления дисков, принтеров, переменных среды, ярлыков, служб, беспроводных сетей и многих других областей. При обработке служба перебирает применимые объекты и передаёт каждому расширению его порцию данных. В порядке приоритетов расширения сортируются, и при желании порядок можно менять в сценариях сопровождения. Группа расширений, объединённая названием Group Policy Preferences, отличается тем, что умеет не только навязывать настройку, но и предлагать её однократно, позволяя пользователю менять значение, а также поддерживает гранулярный таргетинг по множеству условий без WMI-запросов.
Административные шаблоны заслуживают отдельного пояснения, потому что вокруг них сложилось ошибочное представление. Файлы ADMX вместе с локализованными ADML определяют лишь внешний вид настройки в редакторе управления групповыми политиками: название, описание, допустимые значения. Итоговое действие сводится к записи значений в известные ветки реестра, расположенные под ключами Policies. Операционная система и фирменные приложения считывают эти ветки и изменяют поведение. Механизм по сути является централизованным редактором реестра с графическим интерфейсом. Центральное хранилище шаблонов в SYSVOL гарантирует, что все администраторы видят одинаковый набор настроек независимо от рабочей станции, с которой ведётся редактирование. Параметр, выставленный через ADMX и потом отключённый, удаляет соответствующее значение из реестра, в отличие от прямой записи в реестр, которая сохраняется бессрочно.
Конфликты, gpresult и режим Loopback
Диагностика начинается с результирующего набора политик. Команда gpresult с параметром /r показывает, к каким сайтам, доменам и подразделениям принадлежит объект, какие GPO применились, какие отфильтровались и по какой причине. Параметр /h формирует детальный HTML-отчёт с разбором по расширениям, включая победивший объект для каждой настройки. Ещё более детальный просмотр даёт оснастка rsop.msc, которая показывает итоговый конфиг в виде, похожем на редактор. Решение конфликтов всегда проверяется через итоговый набор, а не через умозрительный разбор списков связей, потому что фильтры, блокировки и явные отказы в правах заметно усложняют реальную картину.
Режим Loopback Processing решает отдельную задачу. В обычной схеме пользовательские настройки следуют за учётной записью пользователя, независимо от того, на какой машине тот работает. Для терминальных серверов, учебных классов и киосков такое поведение неподходящее: там требуется, чтобы настройки зависели от компьютера, а человек получал ограниченный набор, независимо от своей роли. В режиме merge пользовательские политики, привязанные к объекту компьютера, добавляются к обычным и побеждают при конфликте. В режиме replace применяются только политики, привязанные к компьютеру, обычный набор пользователя игнорируется. Это позволяет выдать на киоске минимальный интерфейс с фиксированными элементами управления.
Типовые сценарии применения
Практические пакеты настроек, которые встречаются почти в каждом домене, укладываются в несколько устойчивых шаблонов:
- Запрет съёмных USB-накопителей реализуется политикой Removable Storage Access, где чтение и запись отключаются для класса устройств. Отдельные исключения выделяются фильтрами по группам, чтобы служба поддержки сохранила возможность работать с носителями.
- Сопоставление сетевых дисков отдела настраивается через Preferences с таргетингом по группам безопасности. Бухгалтерия получает букву с общим ресурсом учёта, разработчики получают свою букву с репозиторными каталогами, и никакие входные сценарии не нужны.
- Требования к паролям, срок действия, сложность и блокировки задаются доменной политикой по умолчанию или гранулярными объектами PSO для отдельных групп, где требуются более строгие правила.
- Отключение устаревшего протокола SMB1 выполняется через параметры реестра и настройку сервиса, заданную административным шаблоном или предпочтением на всех серверах и станциях.
- Корпоративный фон рабочего стола раздаётся политикой с указанием сетевого пути к изображению, при необходимости с запретом на смену изображения пользователем.
Медленные каналы и делегирование управления
Обработка политики учитывает качество сетевого канала. Клиент замеряет скорость отклика контроллера домена и при показателе ниже порогового значения обычно в пятьсот килобит в секунду считает канал медленным. В таком режиме часть расширений по умолчанию пропускается: сценарии, сопоставление дисков и установка программ не выполняются, тогда как параметры реестра и безопасности применяются всегда. Порог и поведение каждого расширения настраиваются отдельными политиками, что важно для филиалов с ограниченной связностью.
Крупные домены редко обслуживает один специалист, поэтому модель предусматривает делегирование. Права на создание объектов, редактирование отдельных GPO и связывание их с подразделениями раздаются независимо через делегирование в консоли управления. Помощник офиса в регионе может получать право править только политики своего подразделения, не затрагивая корпоративные объекты. Резервные копии объектов создаются штатными средствами консоли, и восстановление отдельного объекта после ошибочной правки занимает минуты.
Отличия от управления через MDM
Облачные платформы управления устройствами, такие как служба Microsoft Intune, используют протокол MDM и конфигурационные профили, близкие по смыслу к мобильному управлению. Они не требуют домена Active Directory, работают через интернет без туннельного подключения к офисной сети и хорошо подходят для удалённых сотрудников. Однако покрытие настроек у MDM исторически уже, часть тонких сценариев классических настольных приложений и сложная логика наследования реализуются там с ограничениями. Групповые политики сохраняют превосходство по глубине настройки, по зрелости механизмов таргетинга и по количеству накопленных шаблонов. Поэтому наблюдаемая картина не является сменой одного инструмента другим: организации совмещают оба подхода, оставляя GPO для доменной инфраструктуры и добавляя MDM для автономных устройств. Долгое время обе системы будут сосуществовать, и навыки администрирования групповых политик остаются обязательной частью квалификации специалиста по инфраструктуре Windows.