Применение групповых политик (часть 1)
Групповые политики являются одним из наиболее мощных инструментов управления пользователями и компьютерами в домене Active Directory. Однако, как и любой сложный инструмент, они требуют четкого понимания принципов своей работы и тщательного планирования. Без этого применение групповых политик может выдать не совсем тот результат, который требуется.
Вот собственно о них, основных принципах, и пойдет речь в этой статье. И начнем мы с самого основного — области действия.
Область действия групповых политик
Все групповые политики имеют свою область действия (scope), которая определяет границы влияния политики. Области действия групповых политик условно можно разделить на четыре типа.
Локальные групповые политики
Групповые политики, применяемые к локальному компьютеру, или локальные групповые политики. Эти политики настраиваются в оснастке «Редактор локальных групповых политик» и применяются только к тому компьютеру, на котором они были настроены. Они не имеют механизма централизованного развертывания и управления и, по сути, не являются групповыми политиками.
Групповые политики доменов
Объекты групповых политик, применяемые к домену Active Directory (AD) и оказывающие влияние на все объекты, имеющие отношение к данному домену. Поскольку в рамках домена работает механизм наследования, то все политики, назначенные на домен, последовательно применяются и ко всем нижестоящим контейнерам.
Групповые политики подразделения
Политики, применяемые к подразделению (OU) и оказывающие влияние на все содержимое данного OU и дочерних OU (при их наличии).
Групповые политики сайтов
Напомню, что в отличие от доменов, которые представляют из себя логическую структуру организации, сайты в AD используются для представления ее физической структуры. Границы сайта определяются одной или несколькими IP-подсетями, которые объединены высокоскоростными каналами связи. В один сайт может входить несколько доменов и наоборот, один домен может содержать несколько сайтов.
Объекты групповой политики, примененные к сайту AD, оказывают влияние на все содержимое этого сайта. Следовательно, групповая политика, связанная с сайтом, применяется ко всем пользователям и компьютерам сайта независимо от того, к какому домену они принадлежат.
Порядок применения групповых политик
Порядок применения групповых политик напрямую зависит от их области действия. Первыми применяются локальные политики, затем политики, назначенные на сайт, затем отрабатывают доменные политики и затем политики, назначенные на OU.
Так в нашем примере (на рисунке ниже) сначала отработает локальная политика (условно назовем ее GPO0), затем политика сайта GPO1, затем политика домена GPO2, ну а затем применятся политики, назначенные на OU. При этом политики применяются в соответствии с иерархией — сначала политика GPO3, назначенная на вышестоящее OU, затем нижестоящие политики GPO4 и GPO5.
Если на одну OU назначено несколько GPO, то они обрабатываются в том порядке, в котором были назначены. Например, к подразделению TechSupport относятся GPO4 и GPO5, которые обрабатываются согласно порядку назначения (Link Order).
Политики обрабатываются в обратном порядке (снизу вверх), т.е. политика с номером 1 отработает последней. При необходимости этот порядок можно изменить, выделив политику и передвинув ее вверх или вниз с помощью соответствующих стрелок.
Приоритет групповых политик
Приоритет GPO напрямую зависит от порядка их применения — чем позднее применяется политика, тем выше ее приоритет. При этом нижестоящие политики могут переопределять вышестоящие — например локальная политика GPO0 будет переопределена доменной политикой сайта GPO1, доменая политика GPO2 — политикой GPO3, а политика вышестоящего GPO3 — нижестоящими политиками GPO4 и GPO5.
Для большей наглядности проведем эксперимент. Для проверки действия политик будем заходить на рабочую станцию WKS1 под учетной записью пользователя Kirill, находящегося в OU TechSupport.
На рабочей станции WKS1 открываем редактор локальных групповых политик (gpedit.msc) и переходим в раздел Конфигурация пользователя\Административные шаблоны\Рабочий стол\Рабочий стол (User Configuration\Administrative Template\Desktop\Desktop).
Откроем политику Фоновые рисунки рабочего стола (Desktop Wallpaper) и укажем использовать в качестве обоев изображение local.png.
Затем перелогиниваемся и проверяем, что политика отработала и обои изменены.
Следующим шагом будет настройка доменной политики. Для этого в оснастке «Group Policy Management» выбираем политику GPO2 и открываем ее для редактирования.
Находим политику, отвечающую за смену обоев и устанавливаем в качестве рисунка рабочего стола изображение domain.png.
Дополнительно переходим в раздел выше и включаем политику «Remove Recycle Bin icon from desktop», удаляющую корзину с рабочего стола.
Еще раз заходим на WKS1 и удостоверяемся в том, что обои рабочего стола изменены и корзины не видно. Это значит, что доменные политики успешно применились и переопределили настройки, задаваемые локальными политиками.
Ну и в качестве завершаюшего шага открываем на редактирование политику GPO4 и устанавливаем политику «Remove Recycle Bin icon from desktop» в положение Disabled.
А также меняем рисунок рабочего стола на изображение с именем ou.png.
Теперь, зайдя на WKS1 мы видим, что обои опять изменены и на рабочий стол вернулась корзина. Из этого следует, что доменная политика GPO2 переопределена политикой GPO4, назначенной на OU.
Отключение наследования
Как я уже говорил, на все политики в домене распространяется наследование, т.е. политики, назначенные на родительский контейнер (домен или OU), последовательно применяются ко всем дочерним контейнерам. Это поведение по умолчанию, но при необходимости его можно изменить, отключив наследование для отдельно взятого OU.
Отключение наследования производится достаточно просто, надо только в оснастке «Group Policy Management» выбрать нужное OU, кликнуть на нем правой клавишей мыши и в контекстном меню отметить пункт «Block Inheritance». После этого для данного OU и его дочерних OU (при их наличии) отменяется воздействие всех вышестоящих политик.
Примечание. Политика Default Domain Policy содержит настройки, определяющие политику паролей и учетных записей в домене. Эти настройки не могут быть заблокированы.
В нашем примере отменим наследование для OU TechSupport, чтобы на него воздействовали только те политики, которые назначены непосредственно на данное OU.
Форсирование применения групповых политик
Форсирование применения групповых политик применяется тогда, когда данная политика должна отработать независимо от остальных политик. Если политика форсирована, то, вне зависимости от своей области действия она получает наивысший приоритет. Это значит, что ее настройки не могут быть переопределены нижестоящими политиками, а также на нее не действует отмена наследования.
Чтобы форсировать политику, надо выбрать ее в оснастке управления групповыми политиками, кликнуть на ней правой клавишей мыши и в контекстном меню отметить пункт «Enforced». Для примера форсируем политику GPO2, назначенную на домен.
Затем зайдем на WKS1 еще раз и увидим знакомую картину. Как видите, политика GPO2 отработала не смотря на блокировку наследования и перебила настройки нижестоящей политики GPO4.
Для одной статьи информации, я думаю, достаточно. А в следующей части разговор пойдет об особенностях применения групповых политик к пользователям и компьютерам.
Азбука групповых политик
Настраиваете вы десять серверов Windows или настольных компьютеров или десять тысяч, знайте, что групповая политика предлагает неоценимую помощь в решении этой задачи.
Настраиваете вы десять серверов Windows или настольных компьютеров или десять тысяч, знайте, что групповая политика предлагает неоценимую помощь в решении этой задачи. Но многие, вероятно, слышали ужасные истории о сложностях групповых политик, когда системный администратор вносил изменения, не понимая их последствий, и в результате не упрощал себе жизнь, а совсем наоборот. Например, изменив разрешения Logon Locally в объекте групповой политики Group Policy Object (GPO) для удаления ненужных групп, вы можете обнаружить, что сделали это в GPO, который применяется ко всем компьютерам в домене, и теперь никто не может зарегистрироваться. Я могу рассказать, как это произошло.
Подобные проблемы весьма распространены. Но вы можете убедиться, что групповая политика соответствует своему потенциалу, оперируя несколькими основными концепциями: как применяются GPO, как работают разрешения и фильтры, в чем разница между политиками и предпочтениями и что в первую очередь следует предпринять для выявления проблем.
Понимание работы групповой политики
Разобраться в том, как клиентская система работает с GPO, важно для того, чтобы гарантировать, что все происходит согласно плану. Давайте для начала поймем, что, несмотря на присутствие в названии функции слова «групповые», политики применяются только для компьютера и пользователя. Поэтому когда вы назначаете Group Policy Object (GPO) объекту Active Directory (AD), компьютерная часть GPO применяется только для объектов компьютера в AD, а пользовательская часть применяется только для пользовательских объектов. Можно использовать группы безопасности, чтобы выявить с помощью фильтра, какие пользователи и компьютеры связаны с данным GPO, однако нельзя нацелить GPO на определенные группы безопасности.
Следуйте правилу: всякий раз, когда вы привязываете GPO к объекту, домену или организационному подразделению (OU) в Active Directory, убедитесь, что пользователь или компьютер, с которым вы хотите, чтобы он был связан, находится в нужном контейнере в иерархическом дереве Active Directory.
Процесс привязки GPO отличается от процесса его создания. Cоздавая GPO в оснастке Active Directory Users and Computers консоли Microsoft Management Console в Windows 2000, вы одновременно связывали этот GPO с контейнером AD. Возможность создавать GPO без подсоединения возникла с появлением Group Policy Management Console (GPMC). Используя GPMC, можно создавать разные GPO, подсоединяя их позже.
Вы также можете вторично использовать GPO, подсоединяя его к нескольким контейнерам AD, например, можно соединить один налагающий строгие ограничения на систему GPO с четырьмя или пятью OU. Смысл подсоединения GPO к нескольким контейнерам состоит в том, что любое изменение в GPO, которое будет внесено впоследствии, повлияет на пользователей и компьютеры во всех соединенных с ним OU. Однако, поскольку можно подсоединить разные GPO к нескольким контейнерам в AD, к конкретному пользователю или компьютеру могут применяться несколько GPO. Чтобы узнать, какая политика реализована в том или ином случае, нужно ответить на два вопроса:
Процесс обработки Group Policy происходит следующим образом. Локальный GPO на данном компьютере обрабатывается в первую очередь, затем GPO, подсоединенные к сайту AD, далее GPO, подсоединенные к домену AD, и, наконец, те, которые подсоединены к OU. Поскольку GPO, подсоединенные к OU, обрабатываются в последнюю очередь, они в итоге и определяют, какие настройки GPO применяются к компьютеру или пользователю. Например, если назначенный домену GPO удаляет команду меню Run из меню Start в Windows, а GPO, подсоединенный к OU, добавляет эту команду обратно в меню, настройки последнего будут применимы к компьютеру или пользователю, потому что система пользователя обрабатывает этот объект вторым. Это приведет к тому, что команда меню Run появится в пользовательском меню.
Group Policy обрабатывается как в оперативном, так и в фоновом режиме. Для компьютера обработка в оперативном режиме происходит, когда система еще только запускается, обычно до того, как пользователь видит окно регистрации, но это не всегда так. Для пользователя обработка в оперативном режиме происходит, когда он регистрируется, обычно до того, как пользователь видит свой рабочий стол, но это опять же не всегда так. Фоновая обработка происходит периодически с целью обновления Group Policy. На контроллерах домена (DC) фоновая обработка для компьютера и пользователя выполняется каждые пять минут. На автономном сервере и рабочих станциях это происходит по умолчанию с периодичностью от 90 до 120 минут. Хотя Group Policy в ходе фоновой обработки обновляется автоматически, не все части политики применяются в процессе фоновой обработки. Так, ни установка программного обеспечения, ни переадресация папок Folder Redirection в фоновом режиме не применяются.
Разрешения Group Policy и фильтрация
Как отмечалось выше, разные GPO обрабатываются только пользователями или компьютерами, но они могут быть отфильтрованы по группам безопасности, которые содержат учетные записи пользователей и компьютеров. По умолчанию, когда администратор создает GPO, группа аутентифицированных пользователей получает разрешения читать Read и применять Apply это GPO, которые дают всем пользователям и компьютерам в данном OU возможность читать и затем обрабатывать GPO. Но, возможно, понадобится наложить данный GPO на часть пользователей или компьютеров в организационном подразделении. В этом случае вы можете использовать группы безопасности для выбора GPO. Это легко сделать, используя обязательный для администратора инструмент, Group Policy Management Console (GPMC), который поставляется с Windows Vista или может быть загружен в разделе System Tools сайта www.microsoft.com/downloads.
Как показано на экране 1, можно менять группы безопасности для данного GPO, просто добавляя или удаляя группы из раздела Security Filtering в GPMC.
Предположим, у вас есть GPO, подсоединенный к Marketing OU, который содержит 200 учетных записей пользователей. Вы хотите добавить некоторые настройки в пользовательской политике части этих пользователей, которые являются членами группы Marketing Special Projects. С помощью GPMC это сделать очень легко. Запустите GPMC, введя gpmc.msc
в строке Run меню Start. Под узлом Group Policy Objects в панели слева выберите тот GPO, который хотите просмотреть. Удалите группу аутентифицированных пользователей из GPO, поскольку она позволяет всем пользователям и компьютерам обрабатывать эту политику. Чтобы это сделать, выделите группу в окне Security Filtering и нажмите кнопку Remove. Затем добавьте группу Marketing Special Projects к списку, нажав кнопку Add и введя имя Marketing Special Projects или отыскав эту группу в домене AD. GPMC позаботится о предоставлении разрешений Read Group Policy и Apply Group Policy данному GPO.
Фильтрация по разрешениям безопасности определяет, какие компьютеры и пользователи могут обрабатывать GPO. Существуют также разрешения, которые указывают, кто может редактировать GPO. Вы можете увидеть эти разрешения, выделяя GPO в GPMC и выбирая вкладку Delegation, как показано на экране 2.
На вкладке Delegation показаны разрешения безопасности из предыдущего диалогового блока Security Filtering вместе с разрешениями на редактирование и изменение GPO. Фактически вы здесь можете обеспечить оба вида доступа: предоставить разрешения на обработку GPO (как и в области Security Filtering) и указать, кто может редактировать GPO. Более того, кнопка Advanced внизу экрана является единственным инструментом в GPMC, с помощью которого вы можете наложить запрет на доступ Deny к данному GPO. Помните, что разрешения безопасности могут либо разрешать, либо запрещать доступ и оба вида записей управления доступом Access Control Entries (ACE) допустимы для разрешений GPO. Однако по умолчанию интерфейс GPMC позволяет накладывать только открывающие доступ разрешения. Так, например, если нужно наложить запрет на использование разрешений Read Group Policy и Apply Group Policy для группы пользователей или компьютеров, которые требуется исключить из обработки GPO, понадобится нажать кнопку Advanced. Откроется знакомый текстовый редактор Access Control List, используемый для установки разрешений на файлы или в AD.
Еще один тип фильтра, доступный на Vista, Windows Server 2003 и Windows XP, — это фильтр Windows Management Instrumentation (WMI). WMI представляет собой набор инструментов Windows, которые можно задействовать для расширенной фильтрации обработки GPO. Например, требуется применить GPO только к системам XP. Используя GPMC, можно создать фильтр WMI, щелкнув правой кнопкой мыши на узле WMI Filters в дереве окон и выбрав пункт New. Фильтр WMI должен иметь форму запроса WMI (для получения более подробной информации о фильтрах WMI следует пройти по ссылке technet2.microsoft.com/WindowsServer/en/library/dfba1 dc6–6848–4 ed8–96 da-f4241 c1 acfbd1033.mspx; для получения информации о запросах WMI см. «Sesame Script: WMI Query Language» по адресу www.microsoft.com/technet/scriptcenter/resources/begin/ss1206.mspx).
Вы можете связать только один фильтр WMI с данным GPO. Если запрос, указанный в фильтре, выдаст результат True при чтении GPO, значит, этот объект применяется. Проверка запроса WMI происходит на клиентском компьютере, который обрабатывает GPO. Запрос исследует собственный местный репозиторий WMI, чтобы получить ответ «верно» или «неверно». Если запрос возвращает False, то GPO к пользователю или компьютеру не применяется. Можно ли применять фильтр WMI к компьютеру или пользователю, зависит от запроса. Например, если запрашивается информация о том, управляется ли компьютер при помощи XP, это вопрос специфический для каждого компьютера, и если компьютер управляется при помощи XP, GPO применит фильтр, вне зависимости от того, зарегистрировался пользователь на компьютере или нет. Однако, если запрашивается информация о том, зарегистрировался ли пользователь Джо Смит на компьютере на данный момент, GPO применит фильтр только тогда, когда Джо Смит действительно зарегистрируется в системе.
Политики или предпочтения
Вероятно, самой популярной частью Group Policy являются административные шаблоны, Administrative Templates, или политики реестра. Эта область групповых политик позволяет контролировать многие аспекты системы Windows. Очень удобно, что политика реестра больше не прописывается явно в реестре и соответственно не применяется, когда не нужна, как это было в NT 4.0. Отсутствие явного прописывания означает следующее: допустим, вы включаете (или отключаете) элемент политики реестра в GPO и применяете его к пользователю или компьютеру, а затем удаляете этот GPO или меняете фильтр безопасности для пользователя или компьютера. Во время следующего цикла оперативной или фоновой обработки данный элемент политики будет автоматически удален, а не «застрянет» в реестре, пока вы его принудительно не удалите.
Процесс удаления работает описанным способом, потому что Microsoft намеренно создала четыре специальных раздела реестра, где записаны все политики, и они удаляются, когда их больше не применяют. Двумя разделами политик реестра для компьютера являются:
HKEY_LOCAL_MACHINESoftwarePolicies
HKEY_LOCAL_MACHINESoftware
MicrosoftWindowsCurrentVersionPolicies
Разделами политик реестра для пользователя являются:
HKEY_CURRENT_USERSoftwarePolicies
HKEY_CURRENT_USERSoftware
MicrosoftWindowsCurrentVersionPolicies
Поскольку настройки политики реестра пишутся в один из этих четырех ключей, они не будут оставаться в реестре, когда GPO удаляется. Конечно, чтобы записать политики в эти четыре раздела, приложения или компоненты в Windows должны быть написаны так, чтобы они опрашивали данные разделы на предмет настроек политик. Однако вы еще можете создавать файлы шаблонов ADM (или ADMX в Vista), которые могут записывать в любые разделы реестра (в HKEY_ LOCAL_MACHINE или HKEY_CURRENT_ USER). Политики, которые это делают, называются «предпочтения» и будут внедрены в реестр, даже если GPO, содержащий их, удален. Таким образом, если вам нужно отменить предпочтение, которое реализовано, необходимо отключить его в интерфейсе Group Policy Editor (GPE) или вручную удалить параметр реестра.
Явное наложение настроек ассоциируется с политиками реестра, но и другие политики показывают такое поведение. Например, политика безопасности принудительно реализует постоянные изменения в системе, когда применяется. Так, если вы задаете пользовательские права в конкретной системе (используя политику, найденную по Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser rights assignment), и затем удаляете GPO, который реализовал данные настройки оттуда, откуда компьютер обрабатывал их, эти назначения пользовательских прав остаются до тех пор, пока вы их явно не измените. Это важно понять, потому что каждая область политик ведет себя по-разному, «оставляя следы» в системах. В некоторых случаях, например в случае с политиками для Folder Redirection или Software Installation, необходимо указать политике, что делать, когда GPO больше не применяется, как показано на экране 3.
Диагностика неисправностей в Group Policy
Групповые политики — инструмент сложный, и иногда они работают не так, как ожидается. По невнимательности вы можете настроить что-то не так или политика может не работать просто из-за сбоя. Процесс обработки Group Policy требует, чтобы некоторые компоненты работали в согласии. Инфраструктура вашей AD и рабочие станции должны быть исправны, а различные настройки, которые вы задаете, должны быть совместимы с приложениями, запущенными на компьютерах. Когда что-то из перечисленного не так, вы можете увидеть, что процесс обработки Group Policy не выполнен.
Как определить, в чем причина? Для начала нужно создать отчет Resultant Set of Policy (RSoP) на неисправной системе. RSoP собирается с помощью мастера Group Policy Results Wizard из состава GPMC. Кроме того, можно использовать из командной строки утилиту gpresult.exe, которая поставляется с Vista, Windows 2003 и XP. Самый простой способ — запустить мастер Group Policy Results из GPMC. Он позволит выбрать локальный или удаленный компьютер для подключения, затем выбрать пользователя, который зарегистрировался на компьютере. После этого мастер соединяется с удаленным компьютером и собирает информацию о процессе обработки Group Policy, который был выполнен последним. Самая полезная часть отчета — это вкладка Summary, которая представлена на экране 4.
Вкладка Summary показывает, какие GPO были применены к компьютеру и пользователю, и, что самое важное, какие GPO были отклонены и почему. Раздел отчета Component Status может дать информацию о том, все ли части процесса обработки Group Policy были выполнены, и если нет, то почему. Элемент Group Policy Infrastructure, который вы увидите в этом разделе, расскажет о том, была ли базовая часть процесса обработки Group Policy успешной. Если это не так, то обычно выявляются некоторые проблемы в инфраструктуре, которые мешают выполнению процесса обработки Group Policy. Если ошибка появляется в так называемых расширениях клиента, которые реализуют различные аспекты политики, можно устранить эту проблему, используя представленные сообщения об ошибках. Если вы хотите посмотреть, какие настройки индивидуальной политики были доставлены компьютеру или пользователю, вы можете открыть вкладку Settings в итоговом отчете по Group Policy, чтобы увидеть, какие настройки в результате были применены. Однако сообщение о применении настроек в отчете RSoP еще не означает, что они были выполнены успешно. Лучше иногда проверять базовые настройки, чтобы узнать, сделана ли данная настройка в рамках применения политики безопасности или существует значение параметра реестра.
Кроме того, можно заглянуть в журнал приложения системы Windows (заметьте, что Vista размещает события Group Policy в системном журнале и в журнале Group Policy Operations), чтобы просмотреть другие ошибки, связанные с процессом обработки Group Policy.
Знание — сила
Group Policy сложны и могущественны. Поняв, как они обрабатываются, вы сможете в полной мере использовать их силу. Помните, что Group Policy обрабатываются в следующем порядке: локальный GPO, сайт AD, домен, затем OU (иногда для этой последовательности применяют сокращение LSDOU) и, в типичной ситуации, «пишущий последним выигрывает», если есть конфликтующие настройки. Политики и предпочтения могут влиять на то, как политика «оставляет следы» в системах, когда GPO удаляется, что важно при выборе в пользу того или иного инструмента. Политики реестра, распространяемые Microsoft в стандартных файлах ADM и ADMX, обычно не меняют реестр, но созданные самостоятельно файлы ADMX могут это делать. Вдобавок другие аспекты политики, такие как безопасность, меняют системы и должны быть явно и принудительно отменены, тогда как некоторым частям политики нужно указать, что следует отменить свои действия, когда они больше не применяются. Наконец, если политика все-таки работает не так, как ожидалось, обратитесь к мастеру Group Policy Results в GPMC.
