Хотя групповая политика появилась более 10 лет назад, многие центры обработки данных, построенные на платформе Windows, до сих пор используют ее для настройки, изоляции и обеспечения безопасности своих серверов и компьютеров. Можно предположить, что групповая политика, которая играет такую важную роль, должна развиваться в том же темпе, что и операционные системы Windows, но это не так. .

Несовместимость реплик групповой политики

Проблема. Параметры объекта групповой политики (GPO) разделены между контейнером групповой политики (GPC) в базе Active Directory (AD) и шаблоном групповой политики (GPT) в хранилище SYSVOL. Когда вы вносите изменения в объект GPO, редактор групповой политики (GPE) записывает изменения в одно из этих хранилищ или в оба, в зависимости от характера изменений. Большинство параметров записываются только в шаблон GPT, но есть и исключения. Например, редактор GPE записывает параметры проводных и беспроводных сетей только в контейнер GPC, а параметры установки приложений и в контейнер GPC, и в шаблон GPT.

При изменении объекта GPO измененная политика должна быть скопирована на все контроллеры домена в окружении, прежде чем все клиенты смогут успешно обработать его. Но копирование происходит с помощью двух различных механизмов — один для хранилища SYSVOL и один для AD. До выхода системы Server 2008 механизм копирования SYSVOL использовал службу репликации файлов (FRS), которая работала с ошибками, что приводило к несогласованности между двумя частями объекта GPO. Только с выходом системы Server 2008, в которой появилась поддержка репликации DFS (DFSR) для хранилища SYSVOL, ситуация значительно улучшилась. Однако многие центры обработки данных до сих пор не перешли на использование DFSR для репликации хранилища SYSVOL. Несогласованность репликации означает отсутствие гарантий, что клиент работает с последней версией объекта GPO, когда обрабатывает групповую политику с локального контроллера домена. Это приводит к тому, что на одних клиентах будет применена групповая политика, а на других нет, что нежелательно в случаях, когда вы используете групповую политику для обеспечения безопасности или настройки параметров изоляции компьютера.

Решение. Если ваша инфраструктура AD использует серверы с системой Server 2008 R2 или Server 2008, стоит рассмотреть вариант с использованием механизма DFSR для репликации хранилища SYSVOL. Хотя, для того чтобы получить преимущества от использования DFSR при репликации SYSVOL, потребуется установить режим работы домена Windows Server 2008, и надежность репликации объекта GPO при этом сильно возрастет.

Тем, для кого не очевидны преимущества механизма DFSR, я рекомендую иметь под рукой инструменты для наблюдения за репликацией объекта GPO. Программа командной строки GPOTool.exe (которая входит в состав пакета Microsoft Windows Server 2003 Resource Kit) может сообщать о несогласованности реплик объекта GPO, но, откровенно говоря, она весьма ограничена в возможностях, а порой и не работает вовсе. В своем окружении я создал команду на Windows PowerShell, которую использую для быстрой проверки заданного объекта GPO по всем контроллерам домена. Как показано на экране 1, команда Get-SDMGPOVersion проверяет только номера версий объекта GPO в AD и в SYSVOL — она не просматривает данные файлов по всем репликам SYSVOL. Однако несоответствие номеров версий может служить сигналом, что не все идет как нужно. Вы можете загрузить бесплатную версию команды SDMGPOVersion, зайдя на сайт www.gpoguy.com/Free-GPOGuy-Tools.aspx и щелкнув мышью по ссылке GPO Version PowerShell Cmdlets.

 

Проверка соответствия версий объектов GPO с помощью команды Get-SDMGPOVersion
Экран 1. Проверка соответствия версий объектов GPO с помощью команды Get-SDMGPOVersion

Кроме того, имеет смысл осуществлять мониторинг процессов репликации FRS, позволяющий обнаружить сбои в работе инфраструктуры FRS. У компании Microsoft есть бесплатный инструмент под названием Ultrasound (bit.ly/gPYCzT), который отлично подходит для этой цели.

Отсутствие обработки при применении политики на клиенте

Проблема. Если вы знакомы с обработкой групповой политики, то знаете, что клиентские системы (серверы или рабочие станции) отвечают за сбор параметров политики с контроллеров домена на регулярной основе, при загрузке или при регистрации в системе. Чтобы процесс прошел успешно, должны быть выполнены два условия:

  1. Клиентские системы должны успешно выполнить запрос к базе AD, чтобы определить, какие объекты GPO применяются к конкретному компьютеру и/или пользователю.
  2. Каждое клиентское расширение или зона действия политики должны успешно выполнить алгоритм обработки параметров политики.

На каждом шаге надежность механизмов групповой политики весьма ограничена. Например, если клиенту попадется контроллер домена с несогласованностью реплики в хранилище SYSVOL или если контроллер домена не сможет предоставить информацию, связанную с объектом GPO, клиентский механизм просто перестанет обрабатывать групповую политику. После неудачи механизм не дает другому контроллеру домена возможности попробовать выполнить требуемые задачи, хотя в инфраструктуру AD и встроена функция резервирования.

К тому же если во время цикла обработки отдельное расширение на стороне клиента получит исключение, которое не сможет обработать (например, испорченные параметры в заданном объекте GPO), то обычно происходит прерывание цикла, и это означает, что остальные расширения не смогут запуститься. Таким образом, ошибка в одном из расширений приводит к полной остановке цикла обработки групповой политики. Из-за низкой надежности трудно рассчитывать на групповую политику как на механизм настройки параметров безопасности.

Решение. Надо сказать, что строго определенного решения данной проблемы не существует. Но, к счастью, она и возникает не часто. Лучший подход — предотвращать возникновение сбоев, способных повлиять на работу вашего окружения, с помощью хорошей системы мониторинга, установленной на клиентских компьютерах, которая будет выявлять ошибки в обработке групповой политики. На системах Windows XP или Windows Server 2003 мониторинг подразумевает поиск событий, содержащих ошибки, с типом источника Userenv в журнале событий приложений. На системах Windows 7, Server 2008 R2 или Server 2008 необходимо отслеживать сбойные события в операционном журнале групповой политики, как показано на экране 2. Отслеживая события с ошибками на клиентских системах, вы не решите проблему, но зато сможете заранее обнаружить ее и скорректировать работу политики.

 

Поиск событий с ошибкой в операционном журнале групповой политики
Экран 2. Поиск событий с ошибкой в операционном журнале групповой политики

Поддерживаются не все параметры

Проблема. Учитывая, что групповая политика — это механизм для настройки операционных систем Windows, вы рассчитываете, что сможете использовать его для настройки различных процессов, связанных с Windows. К сожалению, это не так. Когда специалисты Microsoft выпускают новую операционную систему, они проделывают огромную работу по добавлению новых параметров политики, чтобы обеспечить возможность управления новыми функциями, особенно теми, которые относятся к шаблонам администратора. Но утверждать, что каждая функция в Windows может быть настроена через групповую политику, никак нельзя. Многие задачи по настройке, которые хотелось бы выполнить с помощью групповой политики, на данный момент не поддерживаются. Например, нельзя использовать групповую политику для:

  • настройки параметров безопасности механизмов. NET Framework;
  • настройки стека сетевых протоколов (за исключением межсетевых экранов и протокола IPsec, которые поддерживаются);
  • добавления и удаления ролей и функций Windows (отсутствие возможности добавления и удаления ролей особенно раздражает, так как это идеальная задача для групповой политики).

Решение. Если конкретный элемент конфигурации не имеет собственного параметра групповой политики, можно задействовать возможности сценариев на основе групповой политики, чтобы произвести изменения элемента. В узле Computer Configuration\Policies\Windows Settings\Scripts есть возможность задать сценарии для включения и выключения компьютера. Подобным образом можно задавать сценарии для регистрации и завершения сеанса работы пользователя в системе в узле User Configuration\Policies\Windows Settings\Scripts. Итак, если к элементу можно получить доступ через сценарий, то его значения можно изменять через сценарии на основе групповой политики. Например, программа командной строки Netsh.exe позволяет производить изменения в стеке сетевых протоколов. Вы можете создать сценарий, исполняемый при запуске компьютера, который использует Netsh.exe для изменения настройки стека сетевых протоколов, а затем добавить этот сценарий в объект GPO. Еще, например, можно создать сценарий, который при запуске компьютера использует программу командной строки Ocsetup.exe для настройки параметров Windows, а затем добавить этот сценарий в объект GPO.

Когда вы используете сценарии на основе групповой политики, необходимо помнить, в каком контексте безопасности запускается каждый тип сценариев. Сценарии включения и выключения компьютера запускаются в контексте учетной записи LocalSystem, которая обладает правами почти на любую операцию на сервере или рабочей станции. Напротив, сценарии регистрации и завершения сеанса работы в системе запускаются в контексте пользователя, который, возможно, не обладает нужными правами на данном компьютере.

Также необходимо учитывать, что сценарии при загрузке системы и регистрации в системе выполняются только «на переднем плане». Это означает, что сценарии загрузки срабатывают у пользователя только после перезагрузки компьютера, а сценарии регистрации в системе — только при первой регистрации. Если вам необходимо, чтобы процесс установки запускался в «фоновом режиме», независимо от системы и пользователя, стоит задействовать механизм Scheduled Tasks, входящий в состав предпочтений групповой политики, чтобы настроить задачи, которые будут выполнять команды в определенное время суток.

Недостатки RSoP

Проблема. Как уже говорилось выше, центры обработки данных, построенные на основе Windows, используют возможность настройки параметров безопасности через групповую политику для обеспечения безопасности серверов и компьютеров. Для многих организаций, а в особенности для тех, в которых действуют определенные требования, эта возможность не просто полезна, а обязательна. Контроль выполнения данных требований подразумевает необходимость отслеживания результатов процессов доставки и установки конфигураций безопасности на целевые системы (например, реестр, файловая система, база данных SAM).

Для составления отчетов по обработке политики в состав групповой политики входит механизм Resultant Set of Policy (RSoP). RSoP позволяет проверить, получил ли сервер, рабочая станция или пользователь объекты GPO и их параметры (экран 3). Однако использование RSoP в качестве инструмента аудита и проверки согласованности имеет свои недостатки.

 

Проверка результатов RSoP
Экран 3. Проверка результатов RSoP
  • Средство RSoP сообщает, что объекты GPO и параметры доставлены клиентской системе, но не дает гарантий, что они были применены к реестру или к файловой системе клиента. Таким образом, RSoP, как инструмент проверки, возможно, не пройдет проверку в окружениях, подчиненных нормативам, в которых необходимо гарантировать надежную защиту системы.
  • Инструмент RSoP не обладает возможностями сбора данных и составления отчета по всей организации. Среди набора инструментов групповой политики нет механизма, который мог бы собрать данные RSoP со всех рабочих станций и серверов, и после подведения итогов выдать наглядный отчет, на все ли системы была доставлена политика. Из-за отсутствия обратной связи сложно рассчитывать на групповую политику как на решение ключевых задач настройки безопасности.

Решение. Для этой проблемы нет быстрого решения, но кое-что сделать можно. Если у вас развернута система Microsoft System Center Configuration Manager (SCCM), то можно воспользоваться функцией Desired Configuration Management (DCM) для подтверждения параметров безопасности всей организации. Дополнительно можно загрузить программу Security Compliance Manager (SCM) компании Microsoft по ссылке tinyurl.com/SCM-Download. Этот бесплатный инструмент разработан для того, чтобы помочь написать базовую политику безопасности, которую можно будет экспортировать в резервную копию объекта GPO или в базовый показатель DCM. Данное решение позволяет легко объединить создание базовых показателей безопасности, их доставку через групповую политику и составление отчетов с помощью SCCM и DCM.

Если вы пользуетесь SCCM, то существует пара инструментов, которые помогут вам получить дополнительную информацию. Я создал бесплатную команду, названную Group Policy Health, которую можно загрузить с сайта www.sdmsoftware.com/freeware. Эта команда позволяет запрашивать удаленные системы по имени системы, подразделения (OU) или домена. Она возвращает информацию о том, какие объекты GPO прошли обработку и были ли при этом ошибки. Команда не возвращает информацию о том, были ли параметры политики доставлены на систему. Как показано на экране 4, строка OverallStatus позволяет быстро узнать, был ли объект GPO обработан успешно (green) или нет (red). Команда также предоставляет подробную информацию об обработке объекта GPO на каждой выбранной системе.

 

Команда Group Policy Health проверяет результаты обработки объектов GPO
Экран 4. Команда Group Policy Health проверяет результаты обработки объектов GPO

Другим инструментом, которым вы можете воспользоваться, является бесплатная программа GPInventory.exe компании Microsoft, которую можно загрузить по ссылке bit.ly/h5uOi7. Хотя этот инструмент был разработан для систем Windows XP и Windows 2003, он собирает основную информацию о групповой политике, включая некоторые данные RSoP, с различных систем в вашем окружении.

Отсутствие функций для серверов

Проблема. Первоначально групповая политика была разработана как решение для управления конфигурацией персонального компьютера. Применение групповой политики в серверных окружениях — обычное дело, но при этом групповой политике не хватает некоторых ключевых функций, которые бы сделали ее полезным решением для задач управления серверами. Главным недостатком является отсутствие детерминированного механизма доставки политик, специализированного под настройку сервера. Во многих ли компаниях можно спокойно заявить руководству, что настройки безопасности серверного окружения, которые вы хотели установить сегодня вечером, будут применены «в любой момент в течение ближайших двух часов или после перезагрузки сервера»? Большинство серверных изменений проводится под жестким контролем и должно происходить точно в заданное время для предотвращения сбоев. Так как обработка групповой политики — это механизм, срабатывающий «по требованию» (обработка происходит каждые 90 минут в «фоновом режиме», а также при перезагрузке системы или при регистрации пользователя), он не обладает точностью, которая обычно бывает необходима для выполнения изменений в настройках сервера.

Еще один недостаток при использовании групповой политики для изменения конфигурации серверов заключается в том, что обычно настройки, которые вы хотите изменить (за исключением настроек безопасности), не поддерживаются по умолчанию (например, отсутствие возможности добавлять и удалять серверные роли и функции). Поэтому приходится рассчитывать только на создание сценариев.

И наконец, функция наследования (то есть заданный пользователь или компьютер может находиться в подчинении у множества различных объектов GPO, связанных с их иерархией в каталоге AD), полезная при управлении рабочими станциями, приводит к возникновению сложностей при работе с серверами. Когда вы управляете конфигурациями серверов, вам необходимо заранее знать, какие параметры будут применены на том или ином сервере после внесения изменений в групповую политику. Функция моделирования в RSoP может предоставить такую информацию, но в наборе инструментов групповой политики нет механизмов для анализа конфликтов, которые сообщали бы, какие параметры будут затронуты при внедрении нового параметра.

Решение. Каждая из описанных выше проблем требует отдельного решения. Чтобы решить проблему отсутствия детерминированного механизма доставки, можно воспользоваться различными инструментами, обеспечивающими применение изменений групповой политики в строго определенный момент. Бесплатный инструмент компании Specops Software (www.specopssoft.com/products/specops-gpupdate) называется Specops Gpupdate. Этот продукт с графическим интерфейсом позволяет применять команду GPUpdate для группы удаленных систем, тем самым заставляя их обновлять свою политику в момент запуска команды. Вы можете использовать данное средство после изменения политики, чтобы быть уверенными в том, что ваши серверы обновились своевременно.

Если изменения в конфигурации укладываются в возможности механизма Windows Scheduled Tasks, то для управления временем вступления изменений конфигурации в силу можно воспользоваться функцией Scheduled Tasks, входящей в состав предпочтений групповой политики. Также можно воспользоваться еще одной функцией из предпочтений групповой политики, Item-Level Targeting, чтобы задать временной интервал, в течение которого политика может быть применена к целевой системе. Однако ваше временное окно должно быть достаточно широким, чтобы вместить в себя обычный 90-минутный интервал обновления групповой политики, иначе вы можете его пропустить.

Чтобы решить проблему с неподдерживаемыми серверными настройками, можно воспользоваться сценариями на основе групповой политики, аналогичными тем, что были описаны в разделе «Поддерживаются не все параметры операционной системы». Данное решение реализуемо в тех случаях, когда заданный параметр конфигурации доступен через язык сценариев.

Лучший совет, который я могу дать для решения проблем с наследованием, это попробовать ограничить число объектов GPO, которые вы применяете к серверным системам, и отделить их друг от друга в соответствии с назначением. В идеале нужно настроить один объект GPO для изменений безопасности, один — для изменений реестра, и т. д. Возможно, в вашем окружении не будет возможности построить аналогичную архитектуру объектов GPO, но чем ближе вы подойдете к идеальной модели, тем меньше проблем, связанных с наследованием, встанет на вашем пути.

Творческий подход, терпение и обходные пути

Я рассмотрел несколько проблем групповой политики, которые компания Microsoft вряд ли будет устранять в ближайшее время. Существуют и другие препятствия. Но при прочих равных условиях групповая политика и на данный момент остается довольно неплохим решением для управления конфигурациями окружений, построенных на основе Windows.

Даррен Мар-Элиа (darren@sdmsoftware.com) — внештатный редактор Windows IT Pro, главный инженер и основатель компании SDM Software