Групповые политики в доменах AD

Александр Емельянов

Групповые политики в доменах AD

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

Постараемся обобщить информацию по технологии разворачивания и применения групповых политик (ГП) в службе каталогов. В частности:

• в чем выгода для администратора при использовании ГП;
• сущность объектов ГП и их место в каталоге AD;
• отличие ГП домена от локальных политик рабочих станций;
• как создаются, назначаются и применяются ГП в домене;
• наследование и приоритеты для ГП;
• утилиты gpupdate, gpresult и RSoP;
• другие утилиты для управления и диагностики неисправностей в применении ГП;
• будущее ГП – что нового в плане групповых политик в Windows Vista.

Для чего нужны групповые политики в домене

В предыдущей статье [1] я говорил об управлении пользователями в среде Active Directory. Cлужба каталогов облегчает работу IT-подразделения по администрированию информационных ресурсов предприятия. Технологии Intellimirror и CCM (Change and Configuration Management – управление изменениями и конфигурациями) позволяют управлять рабочими местами, используя перемещаемые профили и перенаправление каталогов, автономные папки и распространение программ. Многие из этих задач легко выполняются при помощи групповых политик, обеспечивая при этом централизованное управление, а также гибкий механизм настройки и отладки. Групповые политики позволяют:

• назначать сценарии запуска, входа и выхода;
• распространять программное обеспечение в сети при помощи публикации или назначения;
• однозначно определять набор настроек безопасности для удаленных машин;
• определять политики паролей для пользователей домена;
• конфигурировать параметры Internet Explorer (даже несмотря на всю его «дырявость», по разным источникам от 60 до 80% пользователей во всем мире используют для просмотра веб-страниц именно этот браузер);
• настраивать перенаправление определенных папок из профиля пользователя;
• накладывать ограничения на рабочий стол;
• определять настройки таких категорий, как автономные папки, дисковые квоты и др., не исключением являются настройки самих групповых политик.

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

Структура объектов групповой политики и их место в службе каталогов

Объект групповой политики (GPO, Group Policy Object) состоит из двух частей: конфигурация компьютера (Computer Configuration) и конфигурация пользователя (User Configuration) (см. рис. 1). Он является контейнером для групп политик, применяемых соответственно к машинам и пользователям сети.

Рисунок 1. Редактор групповых политик gpedit.msc

В «Конфигурации компьютера» администратор может настроить параметры безопасности, политики паролей пользователей, параметры аудита, использование групп с ограниченным доступом (Restricted Groups), параметры реестра и так далее.

В разделе «Конфигурация пользователя» настраиваются параметры рабочего окружения пользователя (настройки рабочего стола, вид и ограничения для панели задач и меню «Пуск»), перенаправление папок, а также параметры Internet Explorer. Каждый объект GPO создается с помощью редактора групповых политик (Group Policy Object Editor). Запустить его можно из вкладки Group Policy свойств контейнера.

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

Каждая политика в объекте GPO может быть сконфигурирована и нет. В первом случае она воздействует на объект и может быть в состоянии включено/отключено, а также принимать значения с указанием дополнительных параметров. Во втором – политика на объект не воздействует.

Объекты групповых политик хранятся двумя частями: контейнер групповой политики (GPC, Group Policy Container) и шаблон групповой политики (GPT, Group Policy Template). Контейнер хранится непосредственно в службе каталогов и содержит информацию о свойствах, версии, статусе и список компонентов. Шаблоны GPT находятся в каталоге WindowsSYSVOLsysvolDomain_NamePoliciesGUID (см. рис. 2), где GUID – глобальный уникальный идентификатор объекта GPO. В этой папке содержатся административные шаблоны (ADM – файлы), настройки безопасности, информация о доступных приложениях и имена сценариев с командными строками.

Рисунок 2. Папка, содержащая шаблоны групповых политик на контроллере домена

Локальные политики рабочей станции

Каждая рабочая станция под управлением операционных систем семейства Windows 2000 имеет свои локальные политики, и администратор домена имеет возможность редактировать их. Они схожи с групповыми политиками домена, но применяются для всех локальных пользователей компьютера без исключения. Также невозможно настроить ряд установок, таких, например, как перенаправление каталогов и установка приложений. Несмотря на это, структура объекта локальных групповых политик такая же, как и GPO домена. Размещается он в папке \Windows\system32\GroupPolicy.

При помощи команды gpedit.msc вы можете редактировать локальные политики рабочей станции. Синтаксис строки для запуска gpedit.msc для просмотра локальной политики удаленной машины будет выглядеть следующим образом:

Gpedit.msc /gpcomputer: Имя_Компьютера

Однако стоить заметить, что вы не сможете посмотреть локальные настройки безопасности удаленной машины (видимо, Microsoft сделала это из-за соображений безопасности).

Групповые политики по умолчанию

После создания первого контроллера домена формируются политики по умолчанию: Default Domain Controller Policy (привязывается к контейнеру Domain Controllers, применяется исключительно для контроллеров домена и содержит настройки безопасности) и Default Domain Policy (политика безопасности для домена, привязывается к контейнеру домена и распространяется на весь домен). Вы легко их можете заменить своими политиками, либо использовать в сочетании с другими. Еще один нюанс, который стоит отметить – если вы попытаетесь открыть Default Domain Controller Policy из меню «Администрирование», вам будут доступны только настройки безопасности. Полностью увидеть и изменить все настройки этого GPO можно из оснастки Active Directory – Users and Computers (DSA.MSC) в свойствах контейнера Domain Controllers.

Создание объектов GPO

Несмотря на название, GPO не имеют ничего общего с группами. Объекты групповых политик могут быть связаны с контейнерами сайта, домена и OU (организационной единицы). Таким образом, для создания объекта GPO мы можем воспользоваться консолями Active Directory – Users and Computers или Active Directory Sites and Services, все зависит от того, для какого контейнера мы создаем GPO. Итак, запускаем DSA.MSC либо DSSITE.MSC. Далее заходим в свойства контейнера и открываем вкладку «Групповая политика» (Group Policy), как это показано на рис. 3. Здесь мы можем создать или изменить GPO, а также добавить и привязать к объекту уже существующий GPO. В этих настройках можно удалить как ссылку на GPO, и тогда пропадет всего лишь привязка GPO к контейнеру, так и сам объект групповой политики.

Рисунок 3. Открытие редактора групповых политик в DSA.MSC

В параметрах (Options) устанавливается, разрешено ли перекрытие для этого объекта. При включенной опции «Не перекрывать» (No Override) другие политики не могут наложить свои настройки на установки данной. Если включена опция «Отключить» (Disabled), это значит, что GPO не будет применяться на этом уровне (к этому контейнеру). При установленном флажке «Блокировать наследование политики» (Block Inheritance) политики верхних уровней иерархии службы каталогов применяться не будут. Однако, если для политики более высокого уровня включена опция «No Override», блокировать наследование не удастся.

В свойствах групповых политик можно увидеть дату создания, последнего изменения объекта GPO, его версию, GUID (Globally Unique Identifier, глобальный уникальный идентификатор) и домен, в котором располагается объект GPO. Здесь же есть возможность отключить настройки конфигурации компьютера или пользователя. На вкладке «Связи» (Links) можно посмотреть, с какими объектами службы каталогов GPO имеет связь. В настройках безопасности указывается, каким группам пользователей предоставляются права на чтение политики, изменение, применение и т. д. Напомню, что связывание и наследование объектов GPO происходит на уровне контейнеров. Но администратор может явно указать, будет ли той или иной группе пользователей, принадлежащих какому-либо контейнеру, разрешено чтение и применение групповых политик из объекта GPO, связанного с этим контейнером. Таким образом, при использовании ACL (Access Control List, список контроля доступа), определяются области действия политики на основе групп. На вкладке «Фильтр WMI» (WMI Filter) вы можете выбрать, будет ли применяться к объекту политик фильтр WMI (Windows Management Instrumentation), и если да, то какой.

При создании объект групповой политики привязывается к контейнеру, для которого вы его создали. Этот GPO будет храниться в Active Directory и может быть применен к другим контейнерам – сайтам, доменам и организационным единицам. Одновременно с этим вы можете удалить привязку GPO к контейнеру, не удаляя сам объект GPO. Групповые политики данного GPO к этому контейнеру применяться не будут, но сам объект все еще будет существовать в службе каталогов. Таким образом, может возникнуть ситуация, когда какой-либо объект групповой политики не будет связан ни с одним контейнером, но он все еще будет существовать в службе каталогов, и вы в любой момент сможете привязать его к сайту, домену или OU.

Каждый контейнер может иметь связь с несколькими GPO, которые будут отображены в списке на вкладке «Групповая политики». И, чем выше политика, тем выше ее приоритетность. Выигрывающей является самая верхняя в списке политика. Изменить приоритетность вы можете, передвигая объекты вверх-вниз и меняя тем самым очередность. Важно понимать, что применение параметров при воздействии многих политик происходит снизу вверх, и, если политика в объекте GPO не сконфигурирована, она не будет воздействовать на параметр. Таким образом, для параметра будет установлено значение, определенное самым верхним в списке объектом GPO, в котором политика сконфигурирована.

Порядок применения групповых политик

При загрузке компьютер получает от контроллера домена своего сайта список групповых политик в том порядке, в котором он должен их применить. Аналогично при входе пользователя в систему происходит запрос групповых политик, определенных для контейнера, которому этот пользователь принадлежит, и дальнейшее их применение. Далее в процессе работы групповые политики обновляются в фоновом режиме каждые X минут, где X – величина, лежащая в интервале 60-120 минут. Эту величину можно изменить при помощи групповых политик, но не рекомендуется делать ее очень маленькой, потому что это повлечет за собой затраты системных ресурсов из-за постоянного обращения к контроллеру домена. Для контроллеров домена групповые политики обновляются каждые 5 минут.

За обработку групповых политик на компьютерах клиентов отвечает набор динамических библиотек – клиентских расширений групповых политик. И, к слову говоря, если на локальной машине не будет файла scecli.dll (на компьютерах часто можно видеть событие с источником SceCli и описанием «Политика безопасности в объектах групповой политики успешно применена»), то групповые политики на нем и вовсе выполняться не будут.

Применение групповых политик пользователя и компьютера в системах Windows NT 5 происходит по-разному. В таблице показано, как это происходит в различных системах по умолчанию. Попросту говоря, в системе Windows XP политики применяются после того, как пользователь уже видит экран входа в систему. При входе в систему он сразу же видит рабочий стол, не дожидаясь применения всех политик. Для повышения безопасности такое поведение можно изменить с помощью параметра Computer Configuration/Administrative Templates/System/Logon/Always wait for the network at computer startup and logon.

Применение групповых политик пользователя и компьютера в системах Windows NT 5

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

• при установленной опции Merge (слияние) происходит объединение двух одинаковых для конфигурации компьютера и пользователя политик: в случае, если политика для компьютера не определена, а для пользователя задана, выигрывает пользовательская политика; в случае же, если политики конфликтуют – выигрывает политика компьютера;
• при установленной опции Replace (замена) пользовательские политики не обрабатываются.

Наследование и порядок применения групповых политик в иерархии службы каталогов

Главная формула применения объектов GPO в доменах Active Directory такова – LSDOU, что означает следующий порядок применения (последние имеют наивысший приоритет):

• локальные политики компьютера (Local Policies);
• групповые политики уровня сайта (Site);
• групповые политики уровня домена (Domain);
• групповые политики уровня организационного подразделения (Organizational Unit).

Однако, зная о том, что иерархия службы каталогов может иметь приличную вложенность OU друг в друга, можно продолжить это правило: групповые политики OU уровня 2, уровня 3 и т. д.

Существует несколько способов, чтобы переопределить такой порядок применения ГП (все параметры можно задать в свойствах целевого контейнера на вкладке Group Policy либо в системном реестре):

• включить блокирование наследования групповой политики с более высокого уровня (опция «Block Inheritance»);
• запретить перекрытие политик более высоких уровней политиками нижестоящих уровней (опция «No Override»);
• отключение применения групповой политики на заданном уровне иерархии (опция «Disabled»);
• использование списков контроля доступа (ACL) и инструментария WMI.

Напомню, что при включенном перекрытии групповых политик блокирование наследования не обрабатывается.

Поиск и устранение неисправностей при работе с групповыми политиками

Нетрудно понять, что групповые политики в доменах Active Directory – инструмент насколько гибкий, настолько и сложный. И, казалось бы, все вам понятно и как на ладони весь домен. Вы создаете групповые политики, привязываете их к контейнерам, включаете дополнительные опции по перекрытию и наследованию, и ждете, когда настроенный вами механизм наконец заработает. Но что-то идет не так, либо вообще ничего не происходит. Вы в замешательстве, но расстраиваться рано.

В составе Windows XP и Windows Server 2003 существует ряд утилит, которые помогут администратору в устранении проблем с групповыми политиками. Рассмотрим их подробнее.

Очень часто на форумах приходится видеть жалобы о том, что у кого-то не применяется групповая политика, хотя все параметры выставлены. Как уже говорилось, в процессе работы политики применяются в фоновом режиме через заданный интервал времени. А некоторые из них вообще требуют перезагрузки компьютера. Однако существует возможность принудительного применения групповых политик на конкретной машине. Ее обеспечивает утилита командной строки gpupdate. Она имеет несколько параметров, при помощи которых можно определить, как будет проведено обновление политик. Например, используя параметр /Target, можно указать, какие политики должны быть обновлены: пользователя, компьютера или и те и другие.

Для того чтобы посмотреть, какие политики применяются на конкретной машине, используется утилита gpresult. Без заданных параметров она выдает следующую информацию для текущего пользователя на данной машине:

• контроллер домена, с которого получены объекты групповой политики;
• когда и какие политики применялись;
• какие политики не применялись из-за фильтрации;
• членство в группах.

RSoP (Resultant Set of Policy, результирующие установки групповых политик) – это графический аналог утилиты gpresult с более широкими возможностями. RSoP – это инструмент составления запросов, с помощью которого администратор может получать информацию об отдельных системах, какие политики на них были применены, в каком порядке и с каким старшинством.

RSoP работает в двух режимах: режиме регистрации и режиме моделирования. В первом случае она берет информацию из базы CIMOM (Common Information Management Object Model, объектная модель управления общей информацией), используя WMI запросы. Это возможно, потому что при входе компьютера в сеть и применения к нему групповых политик все настройки и изменения записываются в CIMOM.

В режиме моделирования вы можете построить запрос и получить информацию о гипотетическом результате применения групповых политик. Режимы регистрации и моделирования могут применяться для отдельных пользователей и компьютеров. Для сайтов, доменов и OU возможно выполнить только моделирующие запросы. Для групп безопасности запросы RSoP не могут быть выполнены. Хотя членство в определенной группе может повлиять на конечный результат применения политик. Запустить выполнение запроса вы можете на контроллере домена из оснастки Active Directory Users and Computers (см. рис. 4).

Рисунок 4. Открытие инструмента RSoP в DSA.MSC

Утилита GPOTOOL проверяет целостность объектов GPO. Как вы помните, каждый такой объект состоит из двух частей: GPT – шаблон групповой политики, и GPC – контейнер групповой политики. Если одной из частей нет, политика работать не будет. Одна из неприятных особенностей данной утилиты (хотя эта особенность свойственна многим утилитам для работы с групповыми политиками) – она не показывает дружественные имена политик. Вместо этого она выводит их GUID. В статье Q216359 можно посмотреть способ, как сопоставить GUID имени политики. Аналогично для просмотра понятного имени политик можно воспользоваться инструментом ADSI Edit.

Утилита Dcgpofix поможет восстановить начальные настройки для групповых политик по умолчанию домена и контроллера домена.

Консоль GPMC.MSC

Мы рассмотрели большинство средств по созданию, настройке и отладке групповых политик. Но из-за их разрозненности существуют определенные неудобства для администратора. Поэтому компания Microsoft выпустила единый инструмент управления групповыми политиками – консоль GPMC.MSC (см. рис. 5), который позволяет выполнять все основные операции по администрированию ГП. Он не входит в состав ни одной из операционных систем, но доступен для свободного скачивания на официальном сайте Microsoft.

Рисунок 5. Консоль управления групповыми политиками GPMC.MSC 

GPMC.MSC является незаменимым инструментом администратора по управлению групповыми политиками в рамках домена, который интегрирует в себе функционал вышеописанных утилит. В дополнение к этому вы можете:

• создавать резервные копии объектов GPO и осуществлять их восстановление;
• составлять отчеты в формате HTML;
• смотреть сконфигурированные настройки политик;
• копировать политики и импортировать настройки политик;
• использовать функцию Drug’n’Drop для назначения привязки объектов GPO к контейнерам.

С помощью GPMC.MSC нельзя выполнить обновление групповых политик, для этого вам придется прибегнуть к gpupdate.

Будущее групповых политик

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

Vista имеет несколько локальных объектов GPO, что позволяет по-разному настроить параметры локальных рабочих станций для администраторов и обычных пользователей. Однако в рамках домена групповые политики Active Directory имеют более высокий приоритет над локальными. Помимо этого, администраторы домена могут выключить локальные политики.

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

В заключение хотелось бы дать несколько советов по работе с групповыми политиками:

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

Многие тонкости работы с групповыми политиками остались за рамками статьи. Используйте статьи базы знаний Microsoft и специальную литературу в качестве теоретической базы для овладения лучшими навыками управления сетевой инфраструктурой при помощи групповых политик.

1. Александр Емельянов. Администрирование пользователей в домене Active Directory. //«Системный администратор», №4, 2007 г.