Групповые политики Windows Server 2008 R2 и Windows 7

Вверсии Windows Server 2008 были реализованы предпочтения групповых политик — набор из более чем 20 расширений групповых политик, которые увеличивают диапазон настраиваемых параметров объекта групповой политики Group Policy object (GPO). После выхода в свет этой версии, полностью изменившей наши представления о работе с групповыми политиками, логично было предположить, что разработчики Windows Server 2008 R2 и Windows 7 включат в свои системы аналогичные новые функции групповых политик. К сожалению, практически все нововведения, которые вы увидите и о которых я буду рассказывать в статье, представляют собой инкрементные усовершенствования, а не революционные изменения.

Правда, надо сказать, что специалисты Microsoft все-таки внесли в Windows Server 2008 и Windows 7 одно принципиальное нововведение, сделав несколько пробных шагов в направлении автоматизации управления групповыми политиками с помощью PowerShell. А все остальные новшества в последней редакции Windows, по сути дела, сводятся к обновлениям существующих областей политик, к нескольким дополнительным компонентам Windows, связанным с управлением групповыми политиками, и к ряду усовершенствований, касающихся предпочтений групповых политик. Рассмотрим эти изменения более подробно.

Изменения в административных шаблонах

В системе Windows Vista появились важные изменения, касающиеся административных шаблонов, или политики реестра. В этой версии разработчики Microsoft реализовали новый формат ADMX и центральное хранилище Central Store. Формат ADMX обеспечил более качественную многоязыковую поддержку, а центральное хранилище позволило перенести старые файлы ADM из компонента SYSVOL каждого объекта GPO. В системах Server 2008 R2 и Windows 7 наиболее значительным изменением в данной области стало появление еще одной группы дополнительных настроек административных шаблонов (более 300). Эти настройки затрагивают целый ряд новых возможностей Server 2008 R2 и Windows 7 (таких, как политики, управляющие новыми элементами пользовательского интерфейса, специфичными для каждой платформы, см. экран 1). С полным списком параметров административных шаблонов и настроек политики безо­пасности в формате Excel можно ознакомиться в документе Microsoft Group Policy Settings Reference for Windows and Windows Server (www.microsoft.com/downloads/details.aspx? displaylang=en&FamilyID=18c90c80-8b0a-4906‑a4f5‑ff24cc2030 fb).

К более тонким модификациям административных шаблонов относится измененная схема ADMX, которая теперь поддерживает два новых типа значений реестра: REG_MULTI_SZ и REG_QWORD. Ранее изменять эти два типа значений с помощью административных шаблонов было невозможно. Администратору приходилось выбирать: предоставлять значения через сценарии реестра или переносить эти типы значений на клиентские системы с помощью расширений реестра в предпочтениях групповых политик. Теперь же эти типы поддерживаются с использованием синтаксиса ADMX, и администратор может создавать специальные шаблоны ADMX, совместимые с новыми типами.

Еще одно тонкое изменение в административных шаблонах — это усовершенствования в области пользовательского интерфейса. В системах Server 2008 и Vista специалисты Microsoft впервые применили концепцию «комментарии к настройкам административных шаблонов». При желании можно добавлять комментарии к каждой настройке политики. Эти комментарии, а также усовершенствованное диалоговое окно «Объяснение», предоставляющее справочные данные по каждой настройке, отображаются в виде трех отдельных вкладок в пользовательском интерфейсе редактора групповых политик Group Policy Editor (GPE). В процессе работы с ними необходимо переходить с одной вкладки на другую. В системах Server 2008 R2 и Windows 7 все три элемента представлены на одной панели, которая хорошо видна и легко редактируется, как показано на экране 2.

Поддержка PowerShell

Важное изменение в данном выпуске Windows, которое упоминалось ранее, это добавленная поддержка PowerShell внутри «вселенной» групповых политик. Разработчики Microsoft добавили средства поддержки выполнения сценариев PowerShell внутри политики сценариев, построенных на базе систем или на базе пользователей, и включили в комплект поставки набор из 25 составных команд PowerShell для версии PowerShell 2.0, обеспечивающих выполнение многих операций, которые можно производить внутри консоли GPMC (Group Policy Management Console). Начнем с описания средств поддержки политики новых сценариев.

Работая в редакторе GPE над созданием сценария запуска или сценария входа в систему, пользователь видит на экране новую вкладку. Как показано на экране 3, теперь можно в свою политику сценариев добавлять сценарии PowerShell и определять, должны ли эти сценарии выполняться до или после сценариев, не имеющих отношения к PowerShell. Но имейте в виду, что эти новые политики сценариев на базе PowerShell будут выполняться только на клиентах групповых политик Server 2008 R2 и Windows 7. Более ранние версии Windows не подходят.

Возможно, самое любопытное усовершенствование в области PowerShell — это набор составных команд внутри нового модуля групповых политик PowerShell 2.0. В этих командах инкапсулируются многие функции из демонстрационных сценариев GPMC, которые некогда поставлялись с этим инструментом. С помощью команд PowerShell можно выполнять связанные с групповыми политиками административные задачи, такие как создание новых объектов GPO или удаление существующих, связывание GPO с организационными единицами или доменами, а также переназначение прав GPO. На экране 4 представлен полный список составных команд, реализованных в новом модуле GroupPolicy, который входит в комплект поставки набора инструментов систем Server 2008 R2 и Windows 7.

Отметим, что использование модуля GroupPolicy возможно лишь в том случае, если вы работаете с версией PowerShell 2.0 на системе Server 2008 R2 или Windows 7. Чтобы дать пользователям возможность применять такого рода функции GPMC PowerShell на системах под управлением более ранних версий Windows, я создал набор команд GPMC для PowerShell 1.0. Их можно бесплатно загрузить на моем сайте по адресу www.sdmsoftware.com/freeware.

Рассмотрим пример, демонстрирующий возможности этих новых команд. Допустим, вы хотите создать объект GPO, наделить его правами доступа и осуществить привязку данного объекта внутри сценария PowerShell. Все эти задачи выполняет следующая однострочная команда, в которой используются три из числа новых составных команд, а также конвейер PowerShell:

new-gpo «Marketing IT GPO» |

Set-GPPermissions -TargetName

«Marketing Users» -TargetType Group

-PermissionLevel GPOEdit | new-gplink

-order 1‑Target "OU=Marketing,

DC=cpandl, DC=com"

В приведенном примере я использую три составные команды — New-GPO, Set-GPPermissions и New-GPLink. С их помощью я создаю объект групповой политики Marketing IT GPO. Я делаю это для модификации разрешений GPO, чтобы предоставить группе безопасности Marketing Users Active Directory (AD) права на редактирование данного GPO и осуществить привязку GPO к организационной единице Marketing OU в моем AD-домене cpandl.com. Все эти задачи выполняются в рамках одной команды с помощью функции конвейерной обработки, обеспечивающей передачу выходных данных предыдущей команды в последующую. PowerShell и модуль Group-Policy позволяют без труда выполнять сложные задачи управления групповыми политиками.

Модификация политики реестра с помощью PowerShell

Разработчики Microsoft заложили в модуль Group-Policy не только функции GPMC. Еще одно изменение — дополнительные базовые средства поддержки модификации небольшого подмножества параметров внутри объекта GPO. Но перед тем как приступить к описанию изменений, внесенных Microsoft, хочу дать небольшую справку. В настоящее время групповая политика дает возможность извлекать значения параметров реестра двумя способами. Основной способ управления параметрами реестра в групповой политике, которым мы располагали всегда, состоит в использовании политики административных шаблонов. С помощью файлов шаблонов ADM или ADMX административные шаблоны создают в редакторе GPE пользовательский интерфейс, который описывает, какими значениями реестра можно управлять посредством групповой политики; кроме того, они обеспечивают справочный текст, описывающий действие параметра политики. Когда вы определяете политики административных шаблонов в редакторе GPE, заданные параметры политики сохраняются в разделе SYSVOL GPO в файле registry.pol. В этом файле содержатся инструкции для значений реестра, которые предстоит развернуть в данном GPO.

Второй метод управления значениями реестра — с помощью расширений реестра в предпочтениях групповых политик. Этот метод отличается большей гибкостью, нежели политика административных шаблонов, и обеспечивает более тонкие средства выбора параметров, связанные с предпочтениями групповых политик. Оба метода позволяют управлять изменениями в реестре централизованно, причем каждый из них имеет свои сильные стороны.

В том, что касается совместимости со средой PowerShell, изменения, внесенные разработчиками Microsoft в системы Server 2008 R2 и Windows 7, сводятся к реализации возможности модифицировать настройки GPO для обоих методов манипулирования реестром. В первом случае для выполнения операций по считыванию и модификации соответствующего файла registry.pol, который используется политикой административных шаблонов с целью хранения своих настроек, вы можете применять команды Get-GPRegistryValue, Set-GPRegistryValue и Remove-GPRegistryValue. Преимущество использования этих команд с целью редактирования политики административных шаблонов состоит в том, что администратору не приходится создавать специальный файл ADM для ввода того или иного значения реестра. Для успешного выполнения этих команд файлы ADM и ADMX не нужны; вместо того, чтобы использовать их, вы получаете возможность принудительно отправлять значения реестра в базовый файл хранения. Таким образом можно быстро передать новое значение реестра объекту GPO.

Недостаток же рассматриваемого метода состоит в следующем. Коль скоро вы не применяете файлы ADM или ADMX для определения того, какие значения реестра используются в данный момент, вы должны знать соответствующий базовый раздел реестра и значение, которое собираетесь развернуть. Кроме того, если вы просматриваете GPO, использующий данный метод для настройки политики параметра реестра, и при этом файлы ADM или ADMX, представляющие данный параметр, отсутствуют, то в отчете о параметрах GPMC он будет показан как Extra Registry Settings. А если вы запустите редактор GPE, то не увидите значение реестра, которое принудительно передали в этот файл registry.pol. Разумеется, если вы будете невнимательно использовать данный метод, это легко может привести к путанице. Я не рекомендую применять данный подход при выполнении всех операций по внесению изменений в административный шаблон, но он может пригодиться в трудную минуту.

Второй метод работы с политикой реестра с использованием PowerShell обеспечивает возможность считывать и модифицировать настройки в расширении реестра Group Policy preferences. Для этих целей Microsoft разработала команды Set-GPPrefRegistryValue, Get-GPPrefRegistryValue и Remove-GPPrefRegistryValue. Эти три команды позволяют управлять настройками реестра новых Group Policy preferences (отметим, кстати, что упомянутые команды нельзя использовать для изменения существующей политики реестра Group Policy preferences). В качестве примера давайте рассмотрим, как можно с помощью этих команд добавить новое значение реестра к параметру реестра Group Policy preferences. Следующая команда примера вводит значение mouse beep в объект групповой политики Test:

Set-GPPrefRegistryValue -Name Test

-Context User -Action Create -Key

"HKEY_CURRENT_USERControl Panel

Mouse" -Valuename «Beep» -Value «Yes»

-Type «String»

Обратите внимание: чтобы успешно ввести параметр Group Policy preferences, в этом примере приходится указывать раздел реестра, valuename, значение и вводить их с клавиатуры. Однако эти команды не обеспечивают доступ к некоторым более развитым функциям внутри Group Policy preferences, например к элементам, которые отображаются на вкладке Common, а также к функции выбора на уровне элемента (средство детального нацеливания на параметры предпочтения). Однако составные команды представляют собой хорошую стартовую точку на пути к автоматизации групповых политик.

Стартовые объекты групповой политики — для чего они?

В системах Server 2008 и Vista корпорация Microsoft впервые реализовала идею стартовых объектов групповой политики — шаблонов GPO, на основе которых можно создавать реальные объекты групповой политики. Идея здравая, но механизм ее реализации проработан не был. Проблема стартовых GPO состоит в том, что они поддерживают только параметры политик административных шаблонов; возможности создаваемых пользователями шаблонов при этом жестко ограничиваются. Изменения, внесенные специалистами Microsoft в версии Server 2008 R2 и Windows 7, — лишь незначительное усовершенствование продуктов, выпускавшихся ранее. В сущности, теперь мы получаем возможность предварительно заполнять стартовые объекты групповой политики директивными настройками безопасности Windows Server 2008, Vista и Windows XP SP2, которые ранее задавались в инструментах, именуемых GPO Accelerators.

Разумеется, поскольку стартовые объекты групповой политики поддерживают только параметры административных шаблонов, а не параметры безопасности (главный фокус директивных параметров безопасности), от этих предварительно заполненных стартовых GPO мало проку. Но если вам нужно создавать шаблоны параметров административных шаблонов, которые вы впоследствии сможете повторно использовать для формирования реальных GPO, тогда стартовые GPO пригодятся.

Новые функции, способные взаимодействовать с политиками

Последняя группа изменений, о которых пойдет речь в этой статье, — это новые политики, предназначенные для поддержки новых функций, представленных в системах Server 2008 R2 и Windows 7. Почти все новые политики связаны с параметрами безопасности, однако наряду с этим несколько непринципиальных обновлений было сделано и в области Group Policy preferences. С них-то мы и начнем.

• Поддержка новых средств Power Plans для управления электропитанием, которые были реализованы в системе Vista. Сейчас они используются как дополнение к средствам Power Options и Power Schemes. Для функционирования средств Power Plans необходимо, чтобы получающий их клиент работал под управлением версии Windows не старше Vista.
• Обновленное средство Updated Scheduled Tasks preferences теперь совместимо с новейшей версией планировщика Task Scheduler, который входит в комплект поставки версии Server 2008 и более поздних, а также Windows Vista. Этот новый планировщик имеет намного больше настроек, чем Task Scheduler систем Windows 2003 и Windows XP. Кроме того, разработчики Microsoft добавили модуль Immediate Tasks для систем начиная с Vista, позволяющий формировать одноразовые плановые задания, которые выполняются по мере осуществления политики.
• Добавление в Internet Settings preferences программы Internet Explorer (IE) 8, что дает возможность настраивать параметры, специфичные для IE 8.

Новые политики безопасности

Важнейшее дополнение в области политик безопасности, базирующихся на групповых политиках, — это политики управления приложениями, или AppLocker. Данные политики хранятся в папке Computer ConfigurationWindows SettingsSecurity SettingsApplication Control Policies. По сути дела, это важное обновление старых политик ограниченного использования программ Software Restriction Policies (SRP), по сей день поддерживаемых в Server 2008 R2 и Windows 7, которые позволяют определять, какие приложения могут выполняться на системах Windows. AppLocker дает возможность формировать белые и черные списки приложений, чтобы в соответствии с рядом указанных критериев явным образом включать или исключать то или иное приложение либо набор приложений из числа выполняемых.

Важное различие между AppLocker и SRP состоит в том, что теперь в распоряжении администратора имеются более гибкие правила для определения приложений. Например, как показано на экране 5, вы можете создавать правила с использованием имени издателя программного продукта, названия приложения и данных о версии, содержащихся внутри файла.

Вы также можете создавать правила для управления выполнением сценария; в более ранних версиях Windows эта функция явным образом не поддерживалась. Кроме того, применительно к каждому созданному правилу можно принудительно обеспечивать выполнение правила или работать в режиме аудита. В этом режиме всякий раз, когда правило вступает в соприкосновение с тем или иным приложением, результат регистрируется на клиенте; такие действия, как блокировка или санкционирование выполнения, не предпринимаются. Подобным образом администратор может испытать правило в тестовом режиме перед тем, как применить его в производственной сети; это делается для того, чтобы исключить возможность «грубого обхождения» с ничего не подозревающим приложением. Единственный недостаток AppLocker в том, что эта программа функционирует только на клиентах Server 2008 R2 и Windows 7, так что использование ее под управлением более ранних версий Windows невозможно.

Усовершенствованная политика аудита

Еще одно связанное с безопасностью средство систем Server 2008 R2 и Windows 7 — гораздо более детально проработанная инфраструктура аудита. Если вы заглянете в папку Computer ConfigurationWindows SettingsSecurity Settings

Advanced Audit Policy Configuration, то увидите 10 различных категорий аудита, которые администратор может подстраивать и тем самым определять, какие именно типы событий будут генерировать аудит безопасности в системах Server 2008 R2 или Windows 7. Разумеется, такой новый уровень детализации реализуется только в упомянутых новейших версиях операционной системы, но то обстоятельство, что управлять им можно с помощью групповых политик, — это хороший знак.

Политики списков сетей

Последняя из новых политик безо­пасности, о которой я расскажу в этой статье, позволяет контролировать списки сетей. По умолчанию, когда системы Server 2008 R2, Windows 7 или Vista находят новые сети, будь то общедоступные беспроводные или корпоративные локальные сети, пользователю предлагается указать, к какому типу относится сеть (например, общедоступная, доменная, домашняя). Теперь с помощью политик списков сетей в разделе групповых политик можно предварительно задавать режим работы тех или иных сетей в определенных ситуациях, а также указывать, в какие зоны их следует переводить в случае обнаружения этих сетей пользователем.

Кроме того, вы можете управлять значками и именами сетей, предъявляемых пользователю. Единственный недостаток применения этой области политики для предварительной настройки беспроводных узлов доступа состоит в том, что требуется заранее знать имя такого узла, чтобы указать все разнообразные параметры. Тем не менее эта область политики все еще представляет собой удачное дополнение, позволяющее контролировать действия пользователей, которые часто переходят от одной сети к другой.

Политика разрешения имен

Эта последняя новая область политики, хотя, строго говоря, она не относится к категории политик безопасности (в редакторе GPE она размещается в папке Computer ConfigurationWindows SettingsName Resolution Policy), позволяет управлять расширениями безопасности DNS Security Extensions (DNSSEC) и настройками Microsoft Direct­Access DNS на основе имен доменов DNS. Так, вы можете указать, какие функции DNSSEC используются, когда данный клиент взаимодействует со своим сервером DNS, или какой сервер DNS либо сервер-посредник будет использовать клиент при подключении к вашей сети через Direct-Access. Эта функция используется не на всех предприятиях, но ее удобно иметь в групповых политиках в случае, когда вы развертываете систему Direct-Access для своих мобильных клиентов.

Не революция, а эволюция

Вне всякого сомнения, реализованные в системах Server 2008 R2 и Windows 7 усовершенствования в области групповых политик носят не революционный, а эволюционный характер. Возможно, следует сделать исключение для некоторых добавленных средств автоматизации управления средой PowerShell, но в остальном мы можем с полным основанием утверждать, что для сторонников групповых политик это весьма заурядная версия. Если мы хотим увидеть крупные архитектурные или функциональные усовершенствования, которых ждут — не дождутся пользователи этой появившейся более 10 лет назад технологии, нам придется запастись терпением.

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

Даррен Мар-Элиа (darren@sdmsoftware.com) — внештатный редактор Windows IT Pro, главный инженер и основатель компании SDM Software. Ведет сайт, посвященный проблемам групповых политик (www.gpoguy.com) и является соавтором книги Microsoft Windows Group Policy Guide