Введение
Из предыдущих статей данного цикла вы уже многое узнали о том, как следует правильно планировать инфраструктуру Active Directory в организации. По теме планирования логической структуры доменных служб уже было рассмотрено планирование внедрения служб Active Directory, где вы узнали об определении требований доменных служб в организации. Во второй статье текущего цикла я описал определение моделей лесов, которые вы можете применять на стадии проектирования структуры организации. В третьей статье данного цикла было рассказано о моделях доменов, а также о том, как определить необходимое количество доменов, которые будут развертываться в вашей организации. В следующей статье текущего цикла вы узнали о правильном размещении пяти ролей мастеров операций. Затем, в статье, связанной с планированием подразделений на предприятии, был рассмотрен процесс проектирования подразделений, согласно пяти известных моделей. Далее была рассмотрена концепция серверов глобального каталога, а также взаимодействие серверов глобального каталога с другими серверными технологиями корпорации Microsoft. В предпоследней статье данного цикла была описана процедура планирования инфраструктуры DNS для домена Active Directory, а именно были рассмотрены проектирование нового именного пространства, а также интеграция доменных служб с существующей инфраструктурой DNS. Последней статьей из цикла по планированию развертывания логической структуры доменных служб Active Directory будет текущая статья, из которой вы узнаете о планировании развертывания групповых политик. Так как большинство моих статей написаны непосредственно по функционалу групповых политик, эта тема для меня является самой интересной из всех этапов планирования логической структуры доменных служб Active Directory.
Как я уже не раз говорил в своих статьях, посвященных функционалу групповых политик, групповые политики предназначены для управления конфигурацией групп и пользователей вашей организации со структурой доменных служб Active Directory и все установленные вами параметры групповых политик располагаются в объектах групповой политики. Эти параметры групповой политики распространяются на ваших пользователей путем привязки объекта GPO к сайту, домену или подразделению, в котором находится учетная запись пользователя или компьютера. Также как и во всех случаях, которые рассматривались в предыдущих статьях этого цикла, процесс внедрения групповых политик состоит из пяти основных этапов: планирования, проектирования, развертывания, тестирования и обслуживания. К сожалению, при планировании внедрения групповых политик в организации не существует определенного набора правил, которыми следует руководствоваться для разработки стабильной структуры данного компонента, поэтому в данной статье будут рассмотрены общие рекомендации, которые следует принять во внимание на этапе внедрения групповых политик.
Процесс планирования развертывания групповой политики
Перед тем как начать выполнять задачи стадии планирования внедрения групповой политики, вам стоит обратить свое внимание на несколько важных моментов. Прежде всего, как уже упоминалось в первой статье данного цикла, для соблюдения тщательного планирования и последующего тестирования вашей инфраструктуры доменных служб Active Directory в большинстве организаций, предоставляющих свои услуги по выполнению такого рода работ, желательно использовать соглашение об уровне обслуживания, которое является регламентирующим документом, определяющим ожидаемый уровень быстродействия, категории ожидаемой производительности, бюджет и начальную стоимость проекта. При помощи такого соглашения вы можете установить некоторые стандарты, предназначенные для службы реагирования, например, максимальный период времени, требуемый для загрузки операционной системы и выполнения пользователем входа, позиционирование контроллеров домена в самом домене, размещение администраторов групповой политики и многое другое. Помимо этого стоит обратить свое внимание на тот момент, что при реализации каждого индивидуального случая внедрения групповой политики, сами цели объекта GPO могут существенно изменяться в зависимости от компетентности пользователей, корпоративных требований безопасности, местоположения самого пользователя, а также от многих других факторов и форс-мажорных обстоятельств. Самое главное, что от вас требуется на данном этапе – полностью удостовериться в том, что разработанная вами структура групповой политики, которая отчасти основывается на продуманной вами ранее структуре подразделений Active Directory существенно упростит как управление самой групповой политикой, так и управление компьютерами и пользователями организации, в которой внедряется данное решение. На этом этапе лучше всего еще раз убедиться, что подразделения спланированы так, чтобы групповые политики могли распространяться на все ваши отделы наиболее рациональным образом. Стоит всегда помнить о том, что непосредственно на уровне домена развертывается минимальное количество параметров групповой политики, а на уровне сайта параметры политики практически не задаются во всех случаях. Если вы изначально халатно отнеслись к планированию подразделений в своей организации, то в будущем у вас могут дублироваться объекты групповых политик, что повлечет за собой значительные задержки в производительности, а то и более существенные проблемы. При планировании структуры подразделений нужно группировать объекты, для которых будут применяться одни и те же параметры групповой политики. Так как все параметры групповой политики наследуются от родительских подразделений, чаще всего самые низкие уровни подразделений предназначаются исключительно для применения объектов GPO. Общепринятым методом создания подразделений в организации считается разделение подразделений с учетными записями пользователей и учетными записями компьютеров. Это делается с той целью, чтобы можно было разделять объекты GPO, которые будут распространяться только на пользователей определенного отдела или на все компьютеры в конкретном здании одновременно. Если компьютеры и пользователи вашей организации разбросаны по нескольким зданиям или даже городам, то, возможно, во избежание создания множества сайтов, что повлечет за собой репликацию и соответственно проблемы с пропускной способности сети, вам придется распределять все подразделения по так называемому географическому принципу, включая дочерние подразделения. Вы можете задаться следующим вопросом: что же плохого в том, что у вас будет несколько сайтов? Ответ достаточно простой: если во время процесса обновления групповой политики скорость сетевого подключения между клиентским компьютером и контроллером домена, размещенного в другом сайте упадет ниже порогового значения, то на клиентский компьютер будут применены только лишь административные шаблоны, политики безопасности и политики беспроводных подключений, а такие политики, как политика установки программного обеспечения будут игнорироваться. Всегда стоит учитывать то, что основной задачей проектирования инфраструктуры доменных служб Active Directory особо значимой задачей является обеспечение простоты администрирования и делегирования. Пример структуры подразделений в организации отображен на следующей иллюстрации:
Рис. 1. Структура подразделений, предназначенных для развертывания групповых политик
Помимо структуры подразделений вам всегда следует помнить об обеспечении безопасности, так как вопрос безопасности для любой организации можно отнести к самым актуальным задачам на сегодняшний день. В этот момент вам следует продумать, как будут изменяться настройки брандмауэра Windows в режиме повышенной безопасности на клиентских компьютерах, будут ли шифроваться диски ваших мобильных пользователей при помощи технологии BitLocker, будет ли использоваться функционал защиты доступа сети и многое другое.
Если вы имеете четкое представление о среде организации, в которой планируете внедрять групповые политики, в таком случае можно начинать разрабатывать сам план, который будет наиболее полным образом соответствовать всем требованиям организации. На этапе планирования следует обратить свое внимание на определение области применения групповой политики и определение параметров политики, применяемых ко всем пользователям, что подробно описано в следующих подразделах.
Определение области применения групповой политики и количества объектов GPO
Уже не раз было указано, что конфигурация, применяемая к пользователям и их компьютерам, определяется в объектах GPO, причем, изменения в конфигурации GPO не влияют на компьютеры или пользователей, если к ним не применяется сам объект групповой политики. Такая концепция называется областью действия объекта групповой политики, иными словами, это коллекция пользователей или компьютеров к которым будут применяться параметры объекта GPO. Методов применения области действия групповой политики не много. Основным методом считается связывание объектов групповой политики с сайтами, доменами или подразделениями, после чего этот сайт, домен или подразделение будут определять пределы области действия объекта GPO. Соответственно, параметры групповой политики будут распространяться еще и на всех пользователей и компьютеры, расположенные в дочерних подразделениях. Помимо связывания объектов групповой политики, вы можете ограничивать область действия объектов GPO при помощи фильтров безопасности, определяющих глобальные группы безопасности, на которые будут распространяться или не распространяться объекты групповой политики. При указании фильтров групп безопасности, определяется, будет ли применяться объект групповой политики к группам, пользователям или компьютерам целиком. Еще для указания области действия объектов групповой политики важным методом является фильтрация инструментария управления Windows, которая позволяет указать область действия при помощи таких характеристик операционной системы, как номер версии, конфигурация оборудования и прочее.
Вам не стоит забывать и о том, что объекты групповой политики применяются к компьютерам и пользователям, в зависимости от их приоритетов. Другими словами, если на вашего клиента распространяются три объекта групповой политики, где определенный параметр включен в одном объекте GPO, отключен во втором и не задан в третьем, то применение данного параметра к конечному клиенту, определяется при помощи приоритетов. Таким образом, объект с более высоким приоритетом будет преобладать над остальными объектами GPO. Если обратить внимание на расположение объектов в оснастке «Управление групповой политикой», то приоритеты объектов групповой политики указываются в виде номера, причем, чем меньше его значение, тем выше приоритет объекта GPO. Всегда нужно помнить, что по умолчанию порядок обработки объектов групповых политик следующий: локальные групповые политики, политики сайта, домена, подразделения. Соответственно, объект групповой политики, расположенный в ближайшем к компьютеру или пользователю подразделении, выполняется в последнюю очередь и считается наиболее приоритетным. Результат такого последовательного применения объектов групповой политики называется наследованием политики. Если в одном подразделении расположено множество объектов групповой политики, то их приоритет определяется при помощи порядка ссылок, где объект с наименьшим значением порядка ссылки в оснастке «Управление групповой политики» обладает более высоким приоритетом.
Если же вам нужно для конкретного подразделения запретить наследование параметров политики, то вы можете воспользоваться возможностью блокирования наследования. Блокирование наследования считается свойством домена или подразделения и позволяет заблокировать абсолютно все параметры групповой политики из объектов GPO, которые связаны с родительскими объектами в иерархии групповой политики. Данное свойство рекомендуется использовать только в самых крайних случаях, поскольку оно существенно ухудшает оценку приоритетов. Также в функционале групповой политики есть зеркальное свойство по отношению к блокированию наследования, которое называется принудительным включением связи GPO. Данная возможность позволяет назначить определенному объекту GPO наивысший приоритет по отношению ко всем остальным объектам групповой политики, причем, принудительная связь будет применяться ко всем дочерним подразделениям даже в том случае, если для них применяется блокирование наследования.
Важным этапом планирования считается определение количества объектов групповой политики, распространяемых на клиентские компьютеры и пользователей вашей организации. В этот момент необходимо иметь четкое представление обо всех подразделениях в вашей организации, так как если в доменной среде вашей организации несколько лесов или доменов, то, вполне очевидно, что для каждого домена будет разное количество объектов GPO и чем сложнее построена бизнес-среда домена, тем большее количество объектов GPO будет в таком домене распространяться. Важно обращать внимание на то, что работа администраторов групповой политики прямо пропорциональна количеству поддерживаемых в вашей инфраструктуре объектов GPO. Другими словами, чем больше вы внедрите объектов групповой политики, тем существеннее возрастёт объем работ этого персонала. Поэтому, если возможно каким-то образом сгруппировать несколько объектов GPO, которые будут применяться к одному и тому же набору пользователей или компьютеров в один, не упускайте такую возможность, так как это значительно упростит вам обслуживание GPO в ближайшем будущем. Другими словами, старайтесь назначать максимальное количество настроек родительским подразделениям, а исключения из таких ситуаций при добавлении параметров политики в дочерние подразделения лучше сразу документировать. На одного пользователя или компьютер может распространяться одновременно не более 999 объектов групповой политики, но если на такого пользователя будет распространяться даже 100 объектов GPO, проследить за всеми настройками, применяемыми для этого пользователя, будет очень сложно. Последнее, что, по моему мнению, нужно помнить на этом этапе планирования – это то, что количество объектов групповой политики, которое применяется к объекту пользователя или компьютера, существенно влияет на время запуска и входа в сеть и чем большее количество объектов GPO связано с пользователем или компьютером, тем больше времени потребуется на их обработку для окончания выполнения входа в систему.
Определение параметров политики, применяемых ко всем пользователям
Несмотря на параметры групповой политики, которые должны применяться непосредственно на определенное подразделение, вам следует определить параметры политики, принудительно распространяемые на всех пользователей или компьютеры организации. К таким параметрам можно отнести политики паролей и блокировки учетных записей пользователей. Такие параметры следует связывать с соответствующими подразделениями в Active Directory, например, подразделением, содержащим всю иерархию учетных записей пользователей. Соответственно, вам нужно четко понимать всю структуру ваших приоритетов объектов GPO, то есть учесть все принудительные связи и блокировку наследования для того, чтобы у вас не возникало проблем при устранении неполадок, которые могут быть у пользователей из-за того, что определенные параметры применяются не там, где нужно или не применяются вообще. Возможно, некоторые параметры следует даже привязывать не к родительским подразделениям, а непосредственно к самому домену. Обязательно обратите на это внимание и хорошо продумайте всю структуру GPO. Компьютеры и сервера вашей организации лучше всего группировать в подразделения с расчетом того, что сотрудники, которые будут за ними работать должны выполнять схожие должностные обязательства, а на серверах развертываются смежные роли. Перед тем как запускать все развернутые вами объекты GPO в производственную сеть их нужно тщательно протестировать. Тестировать их вы можете как в лабораторной среде, так и, попросив нескольких сотрудников из различных отделов посмотреть какие параметры политики применяются, проследить за задержкой перед выполнением входа в систему. Помимо среды тестирования также можно отметить и промежуточную среду, так называемая среда предварительной обработки, которая наиболее приближенная к рабочей среде. В большинстве случаев тестовая и промежуточная среды ничем не отличаются и применяются совместно. Но, тем не менее, так как параметры групповой политики изменяют параметры системного реестра, многие параметры безопасности, а также предназначены для развертывания программного обеспечения, желательно при создании промежуточной среды наиболее четко определить имеющееся оборудование, которое можно использовать для создания архитектуры, аналогичной рабочей среде. О создании промежуточной среды мы еще подробно поговорим в одной из следующих статей по функционалу групповой политики. После того как все тесты будут успешно пройдены и вы будете более чем уверены, что при развертывании в производственной среде не произойдет каких-либо инцидентов, вам следует воспользоваться средствами оснастки управления групповыми политиками и выполнить последнюю миграцию измененных или новых параметров групповой политики в рабочую среду.
После того как вы полностью спланировали инфраструктуру групповой политики, внедрили все параметры GPO в рабочую среду, вам следует разработать расписание резервирования всех настроек объектов GPO для того, чтобы можно было использовать их для восстановления отдельных объектов групповой политики в свое первоначальное состояние.