Настраиваете вы десять серверов 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 имеют разные настройки?
Процесс обработки 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.
Даррен Мар-Элиа (dmarelia@windowsitpro.net) — редактор журнала Windows IT Pro