Я надеюсь, что мои советы помогут вам подготовить эффективную групповую политику.

Как правильно проектировать групповые политики

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

* минимальное воздействие на конечного пользователя;

* равновесие безопасности и блокировок;

* минимальные накладные расходы и сложность управления.

Проблема в том, что иногда эти три цели противоречат друг другу. Например, трудно избежать неудобств для конечного пользователя и одновременно удовлетворить требования компании к информационной безопасности.

Раньше, используя групповую политику (и даже предшествующий вариант системной политики в Windows NT 4.0), я был склонен применять новые возможности технологий, чтобы изменить как можно больше настроек. Со временем я убедился, что для групповой политики больше — не значит лучше. Поэтому прежде чем «завинчивать гайки» безопасности, важно определить реальные нужды компании.

Еще один ключевой вопрос, рассматриваемый в данной статье: какое количество объектов групповой политики (GPO) следует считать избыточным? Здесь я опять же предпочитаю умеренность: минимально достаточное число объектов GPO и минимальная сложность, чтобы охватить нужды компании — таков ключ к успеху.

Но довольно рассуждать об общих подходах к групповой политике. Поговорим о конкретных механизмах.

Монолитные и функциональные объекты GPO

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

* Монолитные объекты GPO содержат разнообразные настройки из многих областей политики (например, административные шаблоны, предпочтения групповой политики).

* Функциональные объекты GPO содержат один или несколько параметров из одной области политики и часто предназначены для выполнения одной функции (например, блокировки Internet Explorer).

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

Цель функционального объекта GPO — изолировать один или несколько параметров из одной области политики, чтобы работать с ними как с единым целым и при необходимости легко делегировать определенному пользователю или группе. Однако, работая с функциональными объектами GPO, легко потерять чувство меры. Наглядный пример — 100 объектов GPO, каждый с одним параметром. За избыточное количество объектов GPO приходится расплачиваться снижением производительности, хотя эти потери могут оказаться меньше, чем можно было предположить.

Цель монолитных объектов GPO — подготовить полный сценарий настройки в одном GPO. Назначение любого объекта, будь то блокирование настольных компьютеров в отделе маркетинга или настройки для мобильных пользователей — собрать все параметры, относящиеся к данному сценарию, в один управляемый и делегируемый GPO. Монолитные объекты GPO идеальны для администратора организационной единицы (OU), который должен управлять настройками групповой политики для пользователей, но не имеет права создавать их произвольно. Монолитные объекты GPO удобны для диагностики: поскольку один GPO определяет основные особенности политики, в случае сбоев требуется проверять лишь один элемент.

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

Привязка и фильтрация

Еще одно решение, отражающееся на сложности и производительности GPO — место привязывания объектов GPO и случаи, когда к ним нужно применять фильтрацию. Здесь возможны два варианта:

* привязывать объекты GPO как можно ближе к выбранной цели;

* привязывать объекты GPO в иерархии Active Directory (AD), а затем применять фильтрацию (например, фильтры WMI, предпочтения групповой политики на уровне элементов), чтобы задать параметр в нужном месте.

Свои преимущества есть у каждого подхода. В значительной мере выбор зависит от структуры AD (о чем будет рассказано в следующем разделе). Я считаю, что всегда следует привязывать GPO как можно ближе к целям и использовать фильтры только в исключительных случаях. Это проще сказать, чем сделать, если имеется плоская иерархия AD (то есть все пользователи принадлежат к одной OU). Однако если удается придерживаться этого принципа, то не только уменьшается сложность среды, но и клиентам не приходится выяснять, нужно ли применять разнообразные фильтры к данному GPO.

А если учесть целеуказание на уровне элементов с использованием предпочтений групповой политики, обеспечивающее создание фильтров для индивидуальных параметров, то легко увидеть, что сложность может выйти за пределы разумного. Клиентам придется очень быстро проверять десятки фильтров, просто чтобы определить, применим ли к ним данный GPO, не говоря уже об обработке параметров GPO. Влияние на производительность может быть еще сильнее, если используются цели на уровне элементов, требующие связи через сеть. Потери производительности могут быть еще больше, если среди элементов будут Security Group, LDAP Query, Domain, Site и Organizational Unit, для которых требуется направлять вызовы LDAP в AD.

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

Согласование структуры Active Directory и групповой политики

Согласовать структуру Active Directory со структурой групповой политики — часто непростая задача. При проектировании AD специалисты обычно руководствуются такими критериями, как требования приложений, делегирования и администрирования. Для групповой политики преобладают удобство нацеливания, тип платформы (то есть сервер или компьютер) и уровень безопасности. Поэтому важно учитывать требования групповой политики при проектировании (или внесении изменений) AD. При обсуждении структуры AD учитывайте следующее:

— постарайтесь разместить 80 % Remote Desktop Services, не применяя фильтрации;

— ищите структуру OU для близкой привязки к цели в 80 % случаев;

— в остальных 20 % случаев следует идти на компромисс, не изменяя структуры AD;

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

На уровне домена следует привязывать только действительно глобальные параметры, которых должно быть очень немного;

— избегайте излишне плоской структуры OU (то есть все пользователи в одной OU), если планируется сколько-нибудь широко применять политику к отдельным пользователям. В таких структурах приходится часто использовать фильтрацию в целях безопасности, что резко повышает сложность и риск (например, ошибочное нацеливание для многих объектов, если применен не тот фильтр);

— избегайте структуры, которая требует замыкания на себя для всех компьютеров. Замыкание на себя следует ограничить такими применениями, как киоски, серверы Remote Desktop Services и т.д.

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

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

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

Фоновая обработка и обработка переднего плана. Как известно, существует два типа событий обработки групповой политики: переднего плана (foreground) и фоновая (background). Для компьютеров обработка переднего плана происходит при запуске. Для пользователей такая обработка выполняется при регистрации. Фоновая обработка, как следует из названия, выполняется периодически, в зависимости от роли клиента. Контроллеры домена (DC) выполняют фоновое обновление через каждые 5 минут, компьютеры с клиентскими версиями операционной системы, обычные серверы Windows обновляются через каждые 90 минут, плюс 30-минутный рандомизированный интервал. Кроме того, Windows Vista и более новые клиенты выполняют фоновое обновление в зависимости от состояния сети. В частности, если клиент Windows (например, ноутбук) не устанавливает контакт с DC при запланированном фоновом обновлении, такой клиент автоматически выполняет фоновое обновление, как только DC оказывается доступен. Такое обновление часто называют обновлением NLA (службы сведений о подключенных сетях).

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

На одном из этапов процесса запуска компьютера Windows клиент подключается к сети. В этот момент начинается обработка групповой политики компьютера. Если настройка выполняется синхронно, пользователь не увидит диалогового окна регистрации службы Graphical Identification and Authentication (GINA), пока обработка не будет завершена. После того, как пользователь зарегистрируется в системе, начинается обработка групповой политики пользователя; пользователь не увидит рабочего стола до тех пор, пока обработка не закончится. Таким образом, при синхронной обработке увеличивается время, которое требуется пользователю, чтобы загрузить компьютер, выполнить регистрацию и приступить к работе.

Но начиная с Windows XP, компания Microsoft по умолчанию использует асинхронный режим обработки групповой политики переднего плана. Обработка такого типа также называется Fast Logon Optimization; она остается стандартным методом обработки переднего плана во всех версиях вплоть до Windows 8. В сущности, при асинхронной обработке Windows функционирует как обычно, даже если обработка групповой политики все еще продолжается. Поэтому в процессе загрузки компьютер не ждет завершения обработки групповой политики, прежде чем выдать на экран диалоговое окно регистрации пользователя. Аналогично, когда пользователь выполняет регистрацию, не нужно ждать окончания обработки групповой политики пользователя, прежде чем предоставить ему рабочий стол.

Возникает вопрос, зачем в таком случае нужна синхронная обработка групповой политики? Дело в том, что некоторые расширения групповой политики на стороне клиента («Установка программного обеспечения», «Перенаправление папок», «Дисковая квота» и «Предпочтения групповой политики «Сопоставления дисков») работают только в синхронном режиме. Поэтому некоторые администраторы отказываются от асинхронной обработки, чтобы реализовать эти области политики. Они включают не совсем верно названный параметр политики Computer Configuration\Policies\Administrative Templates\System\Logon\Always Wait for the network at computer startup and user logon для принудительной синхронной обработки на переднем плане.

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

Значение изменений в обработке групповой политики

Важное преимущество, изначально заложенное в групповую политику, заключается в том, что независимо от обработки событий в фоновом режиме или на переднем плане никакая обработка не совершается, если ничего не менялось внутри объектов GPO, применяемых к данному компьютеру или пользователю. В таких случаях обработка групповой политики прочитывает все применяемые объекты GPO. Но если при сравнении существующего GPO в AD с его записью в клиентском реестре о действиях, произведенных в последний раз, выясняется, что никаких изменений не произошло, то каждое расширение на стороны клиента, реализующее эту область политики, просто «удаляется». Возможны некоторые отклонения от такого порядка, например если кто-то выполняет команду Gpupdate/force из клиента. В сущности, эта команда говорит: «Даже если не было никаких изменений, следует повторно обработать все политики».

Что считается значимым изменением для клиента групповой политики? Ниже перечислены некоторые типы изменений, приводящие к полной повторной обработке политики.

* Кто-то вносит изменение, при котором увеличивается номер версии GPO. Различие между номером версии текущего, действующего GPO и номером версии, последний раз обработанной клиентом, считается изменением.

* Изменился список объектов GPO, применяемых к компьютеру или пользователю. Причиной такого изменения могут быть изменения фильтров группы безопасности для GPO, изменения WMI-фильтров, связанных с GPO, или изменения членства компьютера либо пользователя в группе безопасности, приведшие к рассогласованию GPO.

Обратите внимание, что даже если изменения вызывают полное обновление политики, не все расширения на стороне клиента полностью обновляют свои параметры. Предположим, что Microsoft Office был развернут через оснастку Group Policy Software Installation. Даже если из-за изменений расширение Software Installation на стороне клиента повторно обрабатывает GPO, предоставивший Office, это клиентское расширение не будет удалять и переустанавливать Office. Расширение просто читает параметры объекта GPO и проверяет, не произошло ли серьезных изменений (например, Office был действительно удален из GPO).

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

Быстрота обработки групповой политики

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

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

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

 

Сравнение времени обработки основных и?клиентских расширений
Рисунок 1. Сравнение времени обработки основных и?клиентских расширений

Ситуация мало меняется, даже если клиент обрабатывает очень много объектов GPO. Так уж устроен этот механизм. Время, необходимое для того, чтобы запросить из AD информацию GPO, обычно гораздо меньше времени, затрачиваемого на запись разделов реестра, установку программного обеспечения, отображения дисков и т.д. Вспомните вопрос, заданный в начале статьи: какое количество объектов GPO будет избыточным? Число имеющихся объектов GPO менее важно, чем выполняемые ими действия. Если имеется много объектов GPO, каждый из которых совершает множество действий, то развертывание GPO неизбежно повлияет на работу пользователя настольного компьютера. Если существует много объектов GPO и половина из них размещает лишь один параметр реестра политики, то влияние будет меньше. Возникает также вопрос, зачем нужно так много объектов GPO, которые делают так мало, но он относится к категории сложности управления.

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

Оценка производительности расширений на стороне клиента

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

* Расширения на стороне клиента, такие как Software Installation, которые обслуживают длительные установки программного обеспечения, или Folder Redirection для копирования файлов пользовательского профиля через сеть (занимает много времени в первый раз). Речь не о том, чтобы отказаться от этих функций. Просто помните, что при первом запуске они обычно сильно влияют на работу пользователей.

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

* Расширение на стороне клиента Scripts, точнее сценарий запуска компьютера и регистрации пользователя, вызывает серьезные проблемы. Групповая политика обеспечивает обработку нескольких сценариев при запуске компьютера и регистрации пользователя, но это не всегда выгодно. Сценариям свойственно задерживаться в среде на долгое время. Некоторые продолжают функционировать, хотя потребность в них давно исчезла. Некоторые задачи, активно использующие сеть, продолжают обращаться к уже несуществующим сетевым ресурсам. И наконец, у большинства сценариев нет хороших журналов, поэтому поиск причин задержек, вызванных сценариями на основе групповой политики, затруднен. Как правило, я рекомендую всегда, когда возможно, переносить типовые задачи сценариев, такие как отображения дисков или принтеров и простые настройки реестра, в предпочтения групповой политики. Это гораздо более удобный механизм с более полной инфраструктурой диагностики, чем в случае сценариев.

Группирование расширений, работающих на стороне клиента

Два отдельных решения, относящихся к организации объектов GPO, могут оказать существенное влияние на производительность.

Первое решение связано с группированием часто изменяющихся областей политики. Ранее в данной статье упоминалось о возможном влиянии на производительность выбора между монолитными и функциональными объектами GPO. Создавая монолитные объекты GPO, содержащие несколько областей политики, можно нечаянно увеличить время обработки групповой политики. Причина связана со способом, используемым в групповой политике для обнаружения изменений в GPO (что в конечном итоге определяет, нужно ли выполнять работу). В механизме обнаружения применяется простая проверка номера версии GPO. Поэтому любое изменение в GPO требует, чтобы все расширения на стороне клиента, реализованные в этом GPO, выполнили работу в следующем цикле обработки. Дело в том, что клиенту групповой политики неизвестно, какая область политики изменилась в GPO; ясно только, что произошли какие-то изменения.

Рассмотрим конкретный пример, чтобы более наглядно представить концепцию. Предположим, что компьютер обрабатывает три объекта GPO: GPO A, GPO B и GPO C. GPO A и GPO B применяют настройки политики реестра и безопасности. GPO C применяет только политику реестра. Решено изменить политику безопасности GPO A. При следующей обработке групповой политики обнаруживается, что номер версии GPO A изменился, но неизвестно, какая область политики затронута изменениями. Поэтому во время обработки необходимо сообщить расширениям реестра и безопасности, работающим на стороне клиента, что они должны обработать настройки. Кроме того, хотя в GPO C реализована только политика реестра, расширение реестра на стороне клиента должно выполнить работу, поэтому ему необходимо обработать все объекты GPO в иерархии GPO объекта компьютера. Обработка только GPO A и GPO B нарушит иерархию обработки. Процесс показан на рисунке 2.

 

Влияние группирования расширений на?клиентской стороне на производительность
Рисунок 2. Влияние группирования расширений на?клиентской стороне на производительность

Неожиданно простое изменение одной области политики в одном GPO требует, чтобы два расширения на стороне клиента выполнили действия над тремя объектами GPO. Вывод: если области политики меняются часто, лучше сгруппировать их или расположить отдельно, чем смешивать с редко изменяемыми областями политики. В предшествующем примере при таком подходе следовало переместить области политики безопасности из объектов GPO A и GPO B в собственный GPO (или объекты GPO). Затем, если внести изменение в одну из этих областей, совершить работу потребуется лишь расширению безопасности на стороне клиента, и только применительно к объектам GPO, реализующим настройки.

Второе решение относится к проблеме выбора между синхронной и асинхронной обработкой. Я упоминал о четырех областях политики (установка программного обеспечения, перенаправление папок, дисковая квота и предпочтения групповой политики «Сопоставления дисков»), требующих синхронной обработки на переднем плане. Кроме того, если одна из этих областей реализована в GPO и этот GPO изменяется, то любое из данных четырех расширений на стороне клиента, обрабатывая изменившийся GPO, оповещает Windows о необходимости выполнять следующий цикл обработки на переднем плане синхронно, даже если система настроена на асинхронную обработку переднего плана. И конечно, если задана синхронная обработка, увеличивается время как запуска компьютера, так и регистрации пользователя. И вновь, важно правильно группировать области политики в объектах GPO. Если объект GPO реализует, например, политику Group Policy Preferences Drive Mappings and Registry, и вы изменяете параметр политики реестра в этом GPO, то клиенту, обрабатывающему GPO, неизвестно, какая область политики изменилась, очевидно только, что изменение произошло. Поэтому работают клиентские разрешения реестра и предпочтения групповой политики «Сопоставления дисков». Клиентское разрешение сопоставления дисков сообщает Windows о необходимости «на всякий случай» запустить следующий цикл переднего плана синхронно, и неожиданно маленькое изменение в политике реестра приводит к замедлению следующего запуска компьютера и регистрации пользователя. Точно так же, как принимая предыдущее решение о версиях и группировании разрешений на стороне клиента, при реализации одной из четырех синхронных областей политики рекомендуется поместить их в собственные объекты GPO или объединить друг с другом, отдельно от областей политики, не требующих синхронной обработки.

Скорость работы групповой политики и замыкание на себя

Здесь я хочу упомянуть о замыкании на себя (loopback) и его потенциальном влиянии на производительность. Обработка замыкания на себя обычно используется в киосках, службах Remote Desktop и среде Citrix XenApp. У этого типа обработки два режима: слияние и замена. Режим слияния потенциально влияет на производительность, в зависимости от места привязки объектов GPO относительно компьютеров, настроенных для замыкания на себя. Это происходит потому, что в режиме слияния сначала обрабатываются настройки пользователя для объекта пользователя, выполняющего регистрацию на компьютере с замыканием на себя. Затем обрабатываются настройки пользователя, применяемые к объекту компьютера с замыканием на себя. Возникает интересная возможность: например, один и тот же GPO, содержащий сценарии регистрации и другие настройки, может обрабатываться дважды, если он привязан и фильтруется таким образом, что применяется как к объекту пользователя, так и компьютера. Поэтому, если вы намерены выбрать режим слияния, используйте инструменты моделирования Resultant Set of Policy (RSoP) в консоли управления групповой политикой, чтобы выяснить, как это повлияет на пользователя. Время обработки политики может буквально удвоиться.

Видели, но не слышали

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