Глава 10. Управление Групповыми политиками

Групповая политика имеет два типа установок: настройки компьютеров и настройки пользователей. В зависимости от требований бизнеса и операций нам придётся применять об типа настроек в политиках. Давайте пройдём далее и выполним обзор какие преимущества политик могут предоставляться компании.

Я полагаю, что большинство из вас слышали про стандарты ISO (International Organization for Standardization). Они позволяют организациям запускать свои собственные операции в соответствии со стандартами отрасли. Раз организация удовлетворяет соответствующим стандартам ISO, в свою очередь, для подтверждения того, что эта организация соответствует, будет выпущен сертификат. Даже если организации прошли сертификацию ISO, соответствующая организация с имеющимися на то правами будет проводить ежегодную оценку для подтверждения того что они поддерживают указанные стандарты. Большинство компаний следуют данным стандартам на протяжении всего года, но для некоторых им уделяется внимание только когда должна быть проведена соответствующая оценка. Это происходит по той причине, что внедрение таких стандартов проходит просто, но их сопровождение является непростой задачей.

Наши инфраструктуры также являются предметом множества стандартов. Эти стандарты могут основываться на самой природе их бизнеса, рекомендаций приложений и служб, деловых предпочтений, стандартов отрасли и тому подобного. Задание таких стандартов внутри вашей организации выполняется относительно просто по сравнению с усилиями, которые требуются для их сопровождения. Лучшим способом следования стандартам является принуждение к ним. Например, распространённым стандартом безопасности для пароля является применение сложных паролей. Однако всякий раз, когда вы запрашиваете определение пароля, персонал следует самым простым паролям, которые они способны запоминать. Однако в конкретной системе, когда у нас имеется возможность принуждения на практике не принимать простые пароли, у пользователей просто нет выбора. Они вынуждены соответствовать стандартам пароля для его определения.

Групповые политики позволяют нам выполнять принуждение к установленным в инфраструктуре стандартам. Групповая политика может основываться либо на стандартах пользователей, либо на стандартах компьютеров. Это обеспечивает то, что компании будут следовать данным стандартам с минимальными усилиями по их поддержке, так как после применения такой Групповой политики, целевой группе пользователей или компьютеров придётся соответствовать им и не разрешается делать какой бы то ни было иной выбор. Это почти как преобразование некого стандарта в какое- то правило (rule).

Я начинал свою карьеру в качестве веб разработчика и позднее перешёл к системному администрированию. В данное время названием моей должности является Руководитель системных администраторов (associate system administrator). Одним из наиболее распространённых запросов на обслуживание от управляющих коллективами разработчиков было оснащение программным обеспечением компьютеров инженеров. В нашей компании было около 20 сотрудников, а поскольку я был начинающим сотрудником, мне всегда приходилось идти и устанавливать необходимое ПО для всех 20 компьютеров. Это было головной болью, но так как речь шла всего о 20 компьютерах, это было как- то контролируемо. Однако представьте себе сотни компьютеров; я бы проводил дни напролёт выполняя нудные и повторяющиеся задачи.

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

По умолчанию система Windows обладает неким программным межсетевым экраном для защиты машин от угроз, но порой это препятствует доступу к определённому обмену приложений. В большинстве случаев основной реакцией на это будет либо отключение установленного межсетевого экрана, либо разрешение обмена приложения посредством какого- то индивидуального правила. Однако когда кто- кто изменяет настройки межсетевого экрана без надлежащих навыков команды ИТ, это может приводить к риску для всей инфраструктуры целиком.

Групповые политики делают возможным получать контроль над такими видами чувствительных настроек и предотвращать пользователям выполнение подобных изменений. Так же как и с настройками межсетевого экрана, Групповые политики тоже способны применяться для предотвращения изменения служб, не допуская доступ к свойствам Панели управления (control panel), что исключает возможность внесения изменений в приложения и тому подобное.

В самом начале данного раздела мы изучили как можно применять Групповые политики для принуждения к стандартам. В делах компании некоторые из таких стандартов применяются ко всей организации, а прочие могут быть особенными для подразделений, бизнес- единиц или групп пользователей/ устройств. Групповые политики позволяют нам применять разные политики на основе площадок Active Directory, доменов, организационных элементов (OU) или групп.

Например, мы можем пользоваться Групповыми политиками для помещения различных настроек межсетевого экрана под компьютеры ИТ подразделения компьютеры подразделения продаж.

Мы можем создать две Групповые политики для покрытия своих предыдущих требований и присоединить их к некому надлежащему организационному элементу (OU). Такое гибкое указание цели делает для нас возможным применять различные системные настройки для определённых аудиторий.

Групповые политики также следуют архитектуре клиент- сервер. Контроллеры домена Active Directory содержат установленные Групповые политики и применяют их к устройствам клиента при его входе в систему. Для применения Групповой политики к некому клиенту нам не требуется выполнять какие бы то ни было изменения в системе или профиле. Когда данная цель соответствует установленному критерию Групповой политики, будет осуществлён процесс настройки такой Групповой политики. Такое построение упрощает обработку Групповых политик, поскольку имеется меньше зависимостей.

Групповая политика может применяться для выполнения многих разнообразных задач в инфраструктуре. Здесь я перечисляю некоторые из таких возможностей:

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

Когда добавляются некие новые объекты Active Directory, сама система сохраняет необходимые данные этого объекта в имеющейся базе данных Active Directory. Однако обсуждаемая процедура сохранения GPO отличается от обычного объекта Active Directory; содержимое объекта GPO сохраняется в двух местах (в имеющейся базе данных Active Directory и в папке SYSVOL) в установленной среде Active Directory.

Как и в отношении всех прочих объектов, имеющаяся база данных Active Directory также содержит и сведения GPO. Эта информация больше связана с установками системы и значением пути ссылки на другой набор данных. При создании некого GPO, как и в случае с прочими объектами Active Directory, он также обладает значением GUID (Globally Unique Identifier). Это важно, так как данное значение используется в обоих наборах для ссылки друг на друга. Такое значение также применяется и в CN (Common Name). Прежде чем мы рассмотрим наборы данных, нам требуется отыскать значение GUID для своего GPO. Это можно сделать воспользовавшись такой командой:

Get-GPO -name "Test Users"
		

Наша предыдущая команда PowerShell перечислит список установленных по умолчанию свойств для GPO Test Users:

На нашем предыдущем снимке экрана значение атрибута Id представляет собой значение GUID для GPO Test Users.

Теперь, когда у нас имеются сведения о необходимом GUID, нашим следующим шагом является просмотр сведений GPC (Group Policy Container, Контейнера Групповой политики) для данного GPO. К этим сведениям можно получить доступ при помощи MMC ADSI Edit, или через Ldp.exe. В данном случае давайте воспользуемся для просмотра данных Ldp.exe.

Чтобы открыть Ldp.exe, наберите Ldp.exe в блоке Run контроллера домена. Затем пройдите в меню Connection и выберите Bind. Когда учётная запись с которой вы зашли имеет подходящие полномочия (такие как схема или администратор предприятия), выберите установленные по умолчанию варианты. На следующем этапе кликните по Tree во View и выберите значение DN домена.

В качестве примера, в моей демонстрации значением DN является DC=rebeladmin,DC=com. Значения GPC располагаются в CN=Policies,CN=System,DC=rebeladmin,DC=com:

Данный объект политики дальше дробится на два раздела, которые представляются в соответствующей конфигурации машины (computer) и конфигурации пользователя (user):

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

Как уже упоминалось в самом начале, данные GPO хранятся в двух местоположениях. В данном разделе мы рассмотрели данные, хранимые в базе данных Active Directory, а в следующем мы намерены взглянуть на данные, хранимые в папке SYSVOL.

Когда мы рассматривали возможности Групповой политики, мы видели что они могут применяться для публикации приложений, исполнения сценариев запуска/ останова и прочего. С точки зрения объектов Active Directory, все эти настройки являются атрибутами и все такие файлы и сценарии требуется сохранять для обработки в неком центральном местоположении. Вместо того чтобы хранить их в какой- то базе данных, наша система сохраняет все эти связанные с политиками файлы и установки в каталоге SYSVOL. Значением пути по умолчанию для всех данных этих шаблонов GPT (Group Policy template) выступает \\rebeladmin.com\SYSVOL\rebeladmin.com\Policies. Здесь rebeladmin.com можно заменить вашим собственным FQDN (fully qualified domain name).

Внутри этой папки политик имеются две вложенные папки с названиями Machine и User. Указанные папки содержат файлы и настройки относящиеся к конфигурациям GPO, соответственно, компьютеров и пользователей. Имеется ещё один файл с названием GPT.INI, который содержит значения номера версии применяемой Групповой политики. В каждой редакции Групповой политики номер версии будет увеличиваться автоматически и он будет применяться как ссылка для синхронизации изменений из одного контроллера домена в другой.

Когда жизнеспособная репликация на своём месте, значения номеров версий должны быть равными:

Внутри рассматриваемых папок Machine и User, имеется ряд папок, которые будут содержать сведения, устанавливаемые для соответствующих настроек GPO. Как пример, папка Applications будет содержать файлы установки соответствующего программного обеспечения когда данный GPO устанавливается для публикации приложений, в то время как папка Scripts будет содержать все сценарии запуска/ останова, которые публикуются через данный GPO:

Для успешной обработки Групповой политики критически важным является синхронизация сведений GPT между Контроллерами домена. Выпуски репликации SYSVOL будет оказывать влияние на обработку политики GPO. Вплоть до служб домена Windows Server 2008 репликации SYSVOL применяли FRS (File Replication Service). Начиная с AD DS 2008, она была заменена на DFS (Distributed File System), которая предоставляет большую действенность и надёжность при репликациях.

Оценка требований Групповой политики может указывать некие настройки, которые являются общими для объектов во всём домене целиком. Однако в то же самое время, некоторые установки являются уникальными для особых подразделений или групп. Любые Групповые политики, которые применяются на уровне самого корня, по умолчанию будут наследоваться прочими организационными элементами (OU). Таким образом организационные элементы способны наследовать Групповые политики, а также напрямую связываться с Групповыми политиками.

В каком порядке будут обрабатываться Групповые политики, когда к некому организационному элементу применяется множество Групповых политик? Не прекратит ли это обработку какой- то из Групповых политик? Если одни и те же настройки применяются к различным политикам, какие именно будут применены? Для ответа на все эти вопросы важно понимать как выполняется обработка Групповых политик.

В установленной среде Active Directory имеются два основных вида политик:

Групповые политики могут применяться на трёх уровнях имеющейся среды Active Directory:

Приводимая ниже схема иллюстрирует имеющиеся в AD уровни политик:

В конкретной среде Active Directory групповые политики будут обрабатываться в следующем порядке:

Обычно такой порядок именуется как LSDOU. Самой первой для обработки политикой выступает локальная политика, а самой последней является политика организационного элемента. Это вовсе не означает, что наиболее предпочтительной политикой является локальная. Из всех четырёх политик, именно той политикой, которая удерживает самое низкое значение следования будет выигравшим GPO, которым и выступает политика организационного элемента. Данный порядок следования политик важен в случае, когда политики обладают конфликтующими значениями, потому как выигрывающей политикой является именно та политика, которая ближе всего к данному объекту. Именно политика уровня организационного элемента будет ближайшей политикой к конкретному объекту

Как я уже говорил ранее, установки политики уровня организационного элемента являются более конкретными в соответствии с организационными требованиями. Тем самым, они содержат наиболее точные настройки политики для своих целевых объектов. Данный порядок является установленным по умолчанию, но при наличии требований существует возможность изменения такого порядка следования. Мы рассмотрим это позднее в данной главе.

Для успешного применения Групповой политики компьютера, данное устройство должно иметь допустимое взаимодействие с неким Контроллером домена, а для применения установок Групповой политики пользователя пользователь (точнее, его учётная запись), должна выполнить вход в том подключённом к домену компьютере, который способен взаимодействовать с каким- то Контроллером домена.

В целом, Групповые политики обрабатываются в двух различных режимах. По умолчанию, установки Групповых политик компьютера начинают обрабатываться в процессе запуска, прежде чем блок регистрации пользователя выдаст приглашение на ввод данных. Данный режим предварительного выполнения именуется обработкой с высоким приоритетом (foreground processing). На протяжении этой обработки с высоким приоритетом некоторые политики завершают выполнение, а некоторые нет. Они будут продолжены в фоновом режиме (background) после входа в систему и инициализации сетевого подключения. Помимо этого, после того как пользователь вошёл в систему, по умолчанию имеющиеся групповые политики будут запускаться в фоновом режиме каждые 90 минут. Именно это и является вторым режимом обработки Групповой политики.

Обработка в фоновом режиме может быть и далее разделена на два подчинённых режима. Вплоть до представления Windows XP, все те установки, которые запускались в фоновом режиме, будут обработаны прежде чем соответствующий пользователь увидит свой рабочий стол. Это носит название синхронного режима. Однако после появления Windows XP устанавливаемым по умолчанию режимом обработки стал асинхронный, что означает, что операционная система не дожидается пока завершится процесс применения Групповых политик.

Существует четыре определённых Microsoft настройки политик, которые всегда применяются в синхронном режиме. Если какая- то политика имеет включённым перенаправление папки, установку программного обеспечения, квотирование диска и установку дискового соответствия, они будут применяться в синхронном режиме. Кроме того, все сценарии запуска также будут обрабатываться синхронно в приоритетном режиме.

Такое установленное по умолчанию поведение предоставляет более быстрое время входа пользователя в систему, но в то же самое время некоторые установки политик могут занимать до двух циклов входа в систему для полного применения изменений. Это поведение оказывает воздействие на настройки безопасности. В качестве примера, когда вы желаете блокировать доступ к настройкам в Панели управления и в том случае если настройки этих политик не обрабатываются в синхронном режиме, после входа такого пользователя в систему, для него имеется возможность получить доступ к Control Panel. Тогда это не приводит к ожидаемым результатам. Такой установленный по умолчанию режим полезен в случае когда пользователи подключаются через медленные соединения. Если они не подключены, применение установленных Групповых политик может потребовать ужасающе длительного времени. Когда нет особых причин для применения асинхронного режима, вам рекомендуется всегда применять синхронный режим. Мы можем принудительно установить такое применение Групповых политик; Эти настройки групповой политики расположены в Computer Configuration\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon.

Как мы уже говорили ранее, существуют четыре заданные по умолчанию Microsoft настройки Групповой политики, которые всегда выполняются в синхронном режиме. Даже когда система подключается через медленное соединение, она будет применять эти политики в синхронном режиме. Таким образом, при входе в систему через медленное подключение и для служб удалённого рабочего места вам рекомендуется включить следующие две установки Групповой политики на их принудительное применение в асинхронном режиме. Асинхронный режим для медленных подключений может быть включён через Computer Configuration\Administrative Templates\System\Group Policy\Change Group Policy Processing to run asynchronously when a slow link is detected. Асинхронный режим для служб удалённых рабочих мест может быть включён посредством Computer Configuration\Administrative Templates\System\Group Policy\Allow asynchronous user Group Policy processing when logging on through Remote Desktop Services.

Обработка Групповой политики имеет непосредственное воздействие на наследование Групповой политики. На основании требований Групповой политики порой нам приходится отключать имеющееся наследование. Давайте проследуем далее и в своём следующем разделе более подробно исследуем наследование Групповой политики.

Всякая применяемая к самому верхнему уровню имеющейся структуры Групповая политика наследуется её нижними уровнями. По самому порядку наследования политик решение применяется моделью LSDOU, которую мы рассматривали в разделе Обработка Групповой политики. Просмотреть наследование Групповой политики для каждого организационного элемента (OU) можно при помощи MMC {Консоли управления} Group Policy Management.

Для просмотра наследуемых данных вначале кликните по рассматриваемому организационному элементу, а вслед за этим по закладке Group Policy Inheritance:

Также сведения о наследуемых Групповых политиках можно просмотреть с помощью командлета PowerShell Get-GPInheritance. В качестве примера, те же сведения, что перечислены на предыдущем снимке экрана, можно просмотреть с помощью следующей команды:

Get-GPInheritance -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com"
		

В данном примере у меня имеется одна подключённая к площадке Групповая политика с названием Site 1. Существует две связанные с доменом Групповые политики именуемые Root 1 и Root 2. Также у меня имеется связанная с организационным элементом Групповая политика под именем Test Users:

В данном перечне первой в последовательности идёт Групповая политика Test Users, которая ближе всего к данному организационному элементу - именно она является связанной с этим организационным элементом Групповой политикой. Далее с порядковым номером 2 в последовательности проходит та Групповая политика, которая связана с родительским организационным элементом. Порядковые номера 3, 4 и 5 в последовательности отведены связанным с доменом Групповым политикам. Самой последней идёт Групповая политика Site 1, которая связана с самой площадкой Active Directory.

Такое наследование полезно не в любой ситуации. Могут иметься случаи, при которых данному организационному элементу требуется иметь очень особые настройки и при этом не должны распространяться прочие наследуемые политики. При росте числа Групповых политик также возрастает и время, необходимое на их обработку. Когда моих требований можно достичь при помощи единственной Групповой политики, которая связана с данным организационным элементом, зачем мне всё ещё применять наследуемые политики которые не помогут мне ни коим образом? В подобной ситуации наследование Групповых политик можно блокировать на уровне данного организационного элемента. Это осуществляется с помощью MMC Group Policy Management или командлета PowerShell Set-GPinheritance:

Set-GPInheritance -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com" -IsBlocked Yes
		

Наша предыдущая команда заблокирует наследование Групповых политик для OU=Users,OU=Europe,DC=rebeladmin,DC=com:

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

Порядок следования Групповых политик в LSDOU и наследование Групповых политик также принимают решение какая именно политика выигрывает когда у нас имеются конфликтующие установки. Давайте рассмотри это на следующем примере:

В соответствии с предыдущим примером, у нас имеются две наследуемые политики для организационного элемента Users. Policy 01 является соединённой с доменом Групповой политикой, а Policy 02 является подключённой к организационному элементу (OU) Групповой политикой. Каждая Групповая политика имеет свои собственные значения для трёх отобранных установок. На основании установленного по умолчанию наследования Групповых политик, наш организационный элемент Users будет иметь применёнными обе Групповые политики. Согласно LSDOU, Policy 02 будет иметь более низкое значение приоритета, так как именно она является ближайшей к рассматриваемому организационному элементу Users. Для Password Policy Settings имеет определённым значение только Policy 01. Следовательно, хотя она и менее предпочтительная Групповая политика, данное значение будет применено к организационному элементу Users. Для Windows Firewall Settings имеет значение лишь Policy 02. Та же самая политика также будет применена к организационному элементу Users. Когда же дело касается Internet Explorer Settings, значения имеются у обеих политик, что создаёт некий конфликт. Решение о выигрывающих в этом конфликте установках политики будет основано на LSDOU. Тем самым, побеждающие значения будут взяты от Policy 02.

Microsoft позволяет вам изменять такую процедуру выигрывающей по умолчанию политики принудительными (enforcing) политиками. После того как некая Групповая политика установлена принудительной, она будет иметь наинизший уровень приоритета относительно того, к чему она присоединена. Другим преимуществом принудительной политики является то, что она будет применяться даже когда данный организационный элемент имеет блокируемым наследование.

Когда определённая связанная с доменом политика установлена принудительной, она будет применяться ко всем организационным элементом в данном домене и она будет обладать наинизшим уровнем приоритета. Когда множество политик установлено принудительными, все они будут обладать наинизшими номерами приоритетов по порядку.

Для установки некой политики принудительной, загрузите GPMC (Group Policy Management Console), кликните правой кнопкой по выбираемой Групповой политике и вслед за этим выберите параметр Enforced. Это включит данную политику как принудительную и изменит внешний вид иконки этой политики на имеющую небольшой висячий замок. Это позволит вам быстро выявлять принудительные политики в своём перечне политик:

В нашем предыдущем примере Policy 01 была превращена в принудительную. Она выступает связанной с доменом Групповой политикой. При обычных обстоятельствах при применении к организационному элементу Users наименьшее значение приоритета получает Policy 02. Однако будучи enforced, наименьшее значение приоритета будет иметь Policy 01. Когда мы рассмотрим выигравшие значения организационного элемента Users для Password Policy Settings, эта система будет применять значение Policy 01, поскольку именно она является единственной, в которой определено данное значение. Для Windows Firewall Settings Policy 01 не имеет определёнными никакие значения. А потому, даже хотя политика была enforced, выигрывающие настройки будут взяты из Policy 02, поскольку это значение определяется только там. И Policy 01, и Policy 02, обе имеют значение для Internet Explorer Settings, однако enforced Policy 01 расположена в вершине списка политик и выигрывающие настройки будут браться из неё.

До сих пор мы обсуждали конфликтующие установки политик с различных уровней в установленной структуре домена. Как же всё будет работать, когда они на одном и том же уровне? Политики с одного и того же уровня также применяются в соответствии с установленным порядком приоритета.

Когда политики находятся на одном и том же уровне, применяется LSDOU. Решение о победившей политике принимается на основании их положений в списке политик. Такой порядок следования определяется на основании списка Linked Group Policy Objects. Этот список можно просмотреть воспользовавшись закладкой Linked Group Policy Objects в окне подробностей организационного элемента (OU) в GPMC:

Установленный порядок политик одного и того же уровня может быть изменён при помощи двух методов. Одним из методов является установка этой политики принудительной. Когда данная политика принудительная, она будет получать приоритет над прочими политиками с того же самого уровня, однако это не изменяет Link Order (Порядок связей) данной политики. Значение порядка в данном списке может изменяться кнопками вверх и вниз в закладке Linked Group Policy Objects. Устанавливаемый порядок будет соответствовать порядку следования имеющихся Групповых политик:

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

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

При создании некого объекта Групповой политики и его привязке к площадке, домену или Организационному элементу (OU) существует несколько моментов, которые нам следует рассмотреть:

Некий новый объект GPO можно создать при помощи командлета PowerShell New-GPO:

New-GPO -Name GPO-Test-A
		

Наша предыдущая команда создаст Объект Групповой политики (GPO) с именем GPO-Test-A. По умолчанию он не будет связан ни с каким Организационным элементом, доменом или площадкой. Из Консоли управления Групповой политикой его можно просмотреть в контейнере Group Policy Objects.

После создания некого объекта, его можно связать с неким Организационным элементом, доменом или площадкой при помощи командлета New-GPLink:

New-GPLink -Name GPO-Test-A -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com"
		

Наша предыдущая команда привязывает Объект Групповой политики с названием GPO-Test-A к OU=Users,OU=Europe,DC=rebeladmin,DC=com.

Оба этих командлета можно скомбинировать для одновременного создания Объекта Групповой политики и его привязки:

New-GPO -Name GPO-Test-B | New-GPLink -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com"
		

Наша предыдущая команда создаст некий новый GPO с названием GPO-Test-B и в то же самое время свяжет его с OU=Users,OU=Europe,DC=rebeladmin,DC=com.

Бывают ситуации, при которых имеющуюся связь к Групповой политике необходимо отключать. Это полезно когда вы выполняете устранение неисправностей Групповой политики. После того как определённая ссылка к вашей Групповой политике отключена, она будет удалена из списка приоритетов данной Групповой политики; однако, это не удаляет Групповую политику из Link Order или из её местоположения. Это можно выполнить через Консоль управления Групповой политикой (GPMC) или при помощи командлета PowerShell Set-GPLink:

Set-GPLink -Name GPO-Test-B -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com" -LinkEnabled No
		

Приводимая выше команда отключит ссылку между нашим Объектом Групповой политики GPO-Test-B и OU=Users,OU=Europe,DC=rebeladmin,DC=com. Это обычно применяется для временного отключения какой- то политики. Она может быть в любой момент включена при помощи параметра -LinkEnabled Yes.

Однако когда это необходимо на постоянной основе, такая ссылка Объекта Групповой политики может быть полностью удалена при помощи командлета Remove-GPLink. Он удалит саму ссылку, но он не удалит сам Объект Групповой политики. Он также не оказывает воздействия на прочие имеющиеся ссылки для данного Объекта Групповой политики:

Remove-GPLink -Name GPO-Test-B -Target "OU=Users,OU=Europe,DC=rebeladmin,DC=com"
		

Приводимая команда удалит политику GPO-Test-B из OU=Users,OU=Europe,DC=rebeladmin,DC=com. Она удалит этот Объект Групповой политики из списка Precedence (приоритетов), а также из списка Link Order.

Когда такой Объект Групповой политики требуется удалить полностью, мы можем воспользоваться для этого командлет Remove-GPO:

Remove-GPO -Name GPO-Test-A
		

Данная команда удалит упомянутый в ней GPO целиком из всей системы. Когда такой GPO был связан, это также принудительно удалит и связи в то же самое время.

Без отключения связей, удаления связей или удаления самого GPO, также имеется возможность отключения только настроек Объекта Групповой политики. Такая функциональная возможность предоставляет вариант для отключения настроек компьютера, установок пользователя, либо и того и другого. После отключения таких установок, они не будут удалены из списков Link Order и Precedence. Будут лишь отключены применяемые установки:

В своём следующем разделе мы намерены изучить как можно использовать Групповые политики для управления приложениями и настройками служб даже когда они имеют новые обновления.

Групповые политики позволяют нам действенно управлять установками компьютера и пользователя. Однако, операционные требования инфраструктуры часто изменяются. Например, они могут основываться на новых версиях приложений, новых требованиях безопасности, новых требованиях политики бизнеса и много чего ещё. Мы знаем, что Групповые политики могут применяться для управления настройками по всей организации, однако не все имеющиеся требования будут поддерживаться по умолчанию. Например, на момент выпуска AD DS 2008 не было возможности иметь Групповые политики, которые были бы способны управлять установками в приложениях Office 2016, поскольку он просто не существовал.

Итак, как мы можем управлять новыми приложениями и новыми настройками ОС при помощи Групповых политик? Следует ли нам продолжать обновлять Active Directory? Нет, не стоит. Мы можем делать это при помощи шаблонов администрирования. Производители и разработчики приложения могут разрабатывать шаблоны администрирования и публиковать их через Групповые политики для индивидуализации, управления и оптимизации своих продуктов и служб.

Шаблоны администрирования содержат изменения на основе реестра для применяемой системы. Administrative Templates в Computer Configuration для определённого GPO можно применять для изменения записей реестра в ключе HKEY_LOCAL_MACHINE.

Administrative Templates в User Configuration для конкретного Объекта Групповой политики (GPO) можно использовать для модификации записей реестра в ключе HKEY_CURRENT_USER. Microsoft также имеет предварительно развёрнутые шаблоны администрирования, которые можно применять для изменения более чем 1 000 индивидуальных настроек реестра. Шаблоны администрирования не ограничиваются лишь производителями приложения; когда это необходимо, мы можем создавать персональные шаблоны администрирования.

Вплоть до Windows Server 2008 шаблоны администрирования поступали как форматированные в Unicode текстовые файлы со значением расширения файла .adm. Однако они обладали некими недостатками. Они сохраняли такой файл .adm как часть определённой Групповой политики внутри SYSVOL. Когда они применялись в различных GPO, это приводило к сохранению копий .adm абсолютно для всех GPO. Это увеличивало в размере SYSVOL. Кроме того, когда вам требовалось изменять настройки определённого файла .adm, вам требовалось редактировать все копии .adm. Один файл .adm выполнял поддержку лишь одного языка; когда вам требовалось применять множество языков, вам необходима была копия .adm для каждого из языков.

Начиная с Windows Server 2008, шаблоны администрирования были представлены как два файла XML. Соответствующий файл с расширением .admx отвечает за публикацию настроек реестра, а файл с расширением .adml ответственен за предоставление относящихся к языку специфических настроек. Это позволяет администраторам изменять политики для множества языков и управлять ими. В отличии от файлов .adm, когда вам требуется изменение файла .admx, это требуется выполнять лишь в одном местоположении, к томк же, он будет соответствовать надлежащему файлу .adml для предоставления когда это требуется поддержки множества языков.

Определённый файл .adm является частью конкретного Объекта Групповой политики, а потому он всегда хранится в общей папке SYSVOL. Однако по умолчанию, для ADMX/ADML, Групповая политика содержит необходимые установки только для самой политики, а когда требуются изменения, выполнится активная доставка файлов ADMX и ADML с определённой локальной рабочей станции. Существует возможность изменения данного поведения и сохранения таких файлов в неком центральном местоположении. Это предоставляет простой доступ и лучшее управление шаблонами администрирования.

Мы можем переместить шаблоны администрирования в общую папку SYSVOL воспользовавшись такими шагами:

Это также переместит файлы ADML в \\rebeladmin.com\SYSVOL\rebeladmin.com\Policies\PolicyDefinitions с их названием языка. Например, US English будет в \rebeladmin.com\SYSVOL\rebeladmin.com\Policies\PolicyDefinitions\en-US. Значение языка, применяемого при изменении политики будет приниматься на основе того языка, который применяется в соответствующей рабочей станции. Папка "PolicyDefinitions" в SYSVOL также носит название "Central Store" (Центрального хранилища).

Как мы уже рассматривали ранее, некая Групповая политика может соответствовать площадкам, доменам и Организационным элементам (OU). Когда какая- то Групповая политика соответствует определённому Организационному элементу, по умолчанию, она будет применяться ко всем объектам в нём. Однако внутри какого- то Организационного элемента, домена или площадки имеется большое число объектов. Порой у нас могут иметься целью определённые объекты в Организационном элементе, домене или площадке без изменения текущей структуры Active Directory. Возможности фильтрации Групповой политики позволяют нам и далее сужать вниз цели определяемой Групповой политики на группы безопасности или индивидуальные объекты.

Имеется несколько различных способов выполнения фильтрации в Групповой политике:

Однако эти методы обладают своими собственными характеристиками. На основании их требованиям к фильтрации, выбор наилучшего метода отдаётся на откуп инженерам.

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

Для добавления фильтрации безопасности своим GPO мы можем применять Консолью управления Групповой политикой (GPMC) или командлеты PowwerShell:

Как вы можете видеть, по умолчанию, всякая имеющая некую группу Authenticated Users политика добавляется в соответствующий раздел Security Filtering. Это означает, что по умолчанию данная политика будет применяться ко всем аутентифицированным пользователям в этом OU. Когда мы для фильтрации безопасности добавляем любую группу или объект, это также создаёт некую запись делегирования. Для применения какой- то Групповой политики к некому объекту, как минимум, требуется следующее:

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

Теперь, прежде чем мы добавим индивидуальные объекты в свой раздел Security Filtering, нам требуется изменить установленное по умолчанию поведение фильтрации безопасности для Authenticated Users. В противном случае, вне зависимости от того добавляете группу безопасности или объект - установки Групповой политики будут всё ещё применяться ко всем аутентифицируемым пользователям. Прежде чем Microsoft выпустил исправление MS16-072 в 2016, мы могли просто удалять соответствующую группу Authenticated Users и добавлять сюда все необходимые объекты.

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

Для внесения этих изменений

В данном случае, хотя мы просматриваем как применять Групповые политики к некой конкретной цели, мы также разрешаем в явном виде применять политики большому числу объектов, а затем блокируем группы или объекты. Например, давайте допустим, что у нас имеется некий Организационный элемент с несколькими сотнями объектов различных классов. В числе прочих, у нас имеются 10 объектов компьютеров, к которым нам не следует применять какую- то определённую Групповую политику. Что проще всего? Пройти и добавить абсолютно все группы безопасности и объекты в Security Filtering или разрешить такую Групповую политику для всех и всего лишь блокировать одну группу безопасности?

Microsoft делает для вас возможным также применять и второй метод фильтрации. Для того чтобы осуществить его, Групповая политика должна иметь по умолчанию фильтрацию безопасности, для которой Authenticated Users установлены полномочия Read и Apply group policy. Далее, перейдите в закладку Delegation и кликните по возможностям Advanced. В полученном следом окне кликните по кнопке Add и выберите группу или объект, к которому вам требуется выполнить блокирование доступа:

В данном случае мы запрещаем полномочия Apply group policy для некого объекта с тем, в то время как все прочие объекты из этого Организационного элемента все ещё будут способны считывать и применять эту Групповую политику.

Фильтрация WMI является другим методом, который можно применять для фильтрации целей выбранной Группой политики. Этот метод можно применять для фильтрации только объектов компьютеров и он основывается на значениях атрибутов компьютера. Например, фильтрацию WMI можно применять для фильтрации различных версий ОС, архитектур процессоров (32бита/ 64 бита), ролей Windows Server, настроек реестра, идентификаторов событий и многого иного. Фильтрация WMI запускается для данных WMI определённого компьютера и принимает решение будет ли применяться данная политика или нет. Если выполняется соответствие данному запросу WMI, такая политика должна быть задействованной. Данный метод впервые был внедрён в Windows Server 2003.

Для создания/ управления фильтрацией WMI мы можем применять Консоль управления Групповой политикой (GPMC). Прежде чем применить некую фильтрацию к Объекту Групповой политики (GPO), нам требуется его создать. Отдельный фильтр WMI может присоединяться ко множеству Объектов Групповой политики, однако некий GPO способен иметь подключённым к нему лишь единственный фильтр WMI.

Для создания фильтра WMI откройте Консоль управления Групповой политикой (GPMC):

В приводимых ниже командах вы можете найти ряд примеров широко применяемых запросов WMI:

После того как создан некий фильтр WMI, его следует подключить к необходимому Объекту Групповой политики (GPO). Для этого:

Теперь самое время проверить. Наш проверочный запрос состоит в установке целью ОС 32- битных Windows 10. Когда мы попробуем запустить этот запрос для 64- битных ОС он не будет применён. Мы можем убедится в этом запустив gpresult /r для проверки полученных результатов:

Эта проверка была успешной и данная политика была блокирована, так как у нас запущена 64- битная ОС Windows 10.

Теперь мы знаем как применять эти разнообразные варианты фильтрации для целеуказания определённых объектов для Объекта Групповой политики. Но в каком порядке они применяются? Приводимый ниже список поясняет установленный порядок обработки:

Предпочтения Групповой политики были введены в Windows 2008 для публикации установок предпочтений администрирования в ОС рабочих станций Windows и ОС серверов. Эти установки предпочтения могут применяться только к подключённым к домену компьютерам. Предпочтения Групповой политики предоставляют гранулированный уровень целеуказания и предоставляют простое управление через расширенный графический интерфейс. Предпочтения Групповой политики заменили множество настроек Групповой политики, которые требовали изменения реестра или сложных сценариев входа. Предпочтения Групповой политики способны добавлять, обновлять и удалять следующие установки:

Установки Групповой политики и предпочтения Групповой политики обрабатываются двумя различными способами. Настройки Групповой политики применяются в процессе загрузки и входа пользователя в систему. После этого настройки обновляются каждые 90 минут (по умолчанию). Когда определённая Групповая политика применена, её значения невозможно изменить простым способом. Это требует активной доставки новых значений через Групповую политику. В противном случае, даже когда они изменены, они будут перезаписаны в следующем цикле обновления политики. Однако предпочтения Групповой политики не применяются принудительно. Это делает возможным для пользователя изменять их, когда то необходимо. Это также делает возможным настраивать приложения, которые не осведомлены о Групповой политике.

Предпочтения Групповой политики также разделяются на Computer Configuration и User Configuration. Для управления настройками предпочтений мы можем применять Консоль управления Групповыми политиками (GPMC).

Для доступа к настройкам предпочтений выберите соответствующую Групповую политику, кликните правой кнопкой по Edit... и раскройте Computer Configuration или User Configuration. Здесь мы можем увидеть контейнер Preferences:

В качестве примера мы можем рассмотреть настройку установок Internet Explorer. Это одна из наиболее часто применяемых в организациях установок предпочтений, в особенности при публикации установок посредника (прокси). Вплоть до Internet Explorer 10, установки Internet Explorer управлялись при помощи IEM (Internet Explorer Maintenance) в его Групповой политике. Если ваша организация имеет установки IE, публикуемые при помощи IEM, это не будет применимо никоим образом ни к IE 10, ни к IE11. Настройки Internet Explorer также можно применять через изменение реестра; предпочтения Групповой политики делают это простым, так как применяют графический интерфейс, похожий на реальное окно настроек IE.

Для настройки этих установок откройте установки Групповой политики, после чего проследуйте в User Configuration | Preferences | Control Panel Settings | Internet Settings. Вслед за этим кликните правой кнопкой и выберите New. Здесь мы имеем возможность выбора установок на основе версии IE. Нет возможностей для IE 11, но те настройки, которые применяются к IE 10, будут применимы также и к IE 11:

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

Один из моментов, в котором вам следует убедиться, так это то, что после того как вы ввели изменения, вы нажали на клавишу F6для применения изменений. Если они отработали нормально, выделенная красными точками линия изменится на обозначенную зелёными точками линию. Не имеет значения какие изменения вы выполняете; если вы не активируете их нажатием F6, они не будут опубликованы:

Эти установки предпочтений не запретят пользователю изменять их. Когда требуется запрещать пользователю вносить изменения предпочтений, тогда для них требуется применять установки Групповой политики.

В своём предыдущем разделе мы рассмотрели то как мы можем применять фильтры WMI для целеуказания Групповой политики на уровне грануляции. Аналогичным образом целеуказание на уровне элемента может применяться для указания цели настроек предпочтения Групповой политики на основе настроек приложения и свойств пользователей и компьютеров.

В настройках предпочтений мы можем применять элементы со множественным целеуказанием и делать выбор на основании логических операторов (таких как AND, OR, IS и IS NOT).

Целеуказание уровня элемента в предпочтениях Групповой политики может устанавливаться/ управляться с применением GPMC. Для этого откройте настройки соответствующей Групповой политики, пройдите в соответствующие настройки предпочтений, кликните правой кнопкой и выберите Properties.

Что касается нашего предыдущего примера (настройка IE 10), необходимым путём должен выступать User Configuration | Preferences | Internet Settings | Internet Explorer 10. Затем кликните правой кнопкой и выберите Properties.

В полученном окне Properties выполните такие шаги:

В своём следующем окне мы можем построить целеуказание гранулированного уровня на основании одного элемента или множества элементов при помощи логических операторов:

В своём предыдущем примере я построил запрос на основании трёх настроек, которыми выступают имя NetBIOS, значение ОС и значение IP адреса. Чтобы применить необходимые настройки предпочтения, все три выражения предоставляют значение true в качестве результата, так как воспользовался логическим оператором AND. Если бы тут стоял логический оператор OR, получаемый результат мог бы иметь либо значение true, либо значение false. {Прим. пер.: Но по крайней мере один из них в последнем случае должен иметь значение true.}

В своём предыдущем снимке экрана наше меню New Item содержит элементы, которые мы можем использовать для целеуказания. Add Collection позволяет вам создавать некое заключаемое в скобки группирование. Меню Item Options ответственно за определение логических операторов.

Групповые политики обладают двумя основными конфигурациями. Одной является целеуказание настроек компьютера, а другой выступает целеуказание настроек конфигурации пользователя. Когда мы применяем конфигурацию пользователя к некому расположенному в Организационном элементе (OU) пользователю, не имеет значения в каком именно компьютере он выполнил вход в систему - его настройки политик следуют за ним. Например, давайте предположим, что пользователь Liam располагается в Организационном элементе Sales. Тот компьютер, с которого он обычно регистрируется для входа в систему также располагается в том же самом OU. Однако время от времени он входит в систему с ноутбука в переговорной комнате, который находится в Организационном элементе IT operations. OU IT operations обладает собственными назначенными ему политиками Computer Configuration и User Configuration. Однако когда Liam регистрируется в нём, он всё ещё обладает теми настройками, которые он имел в своём ПК Организационного элемента Sales. Именно это является нормальным поведением Групповых политик. Тем не менее, имеются ситуации, при которых требуется применение настроек политик пользователя на основании того компьютера, в котором регистрируется данный пользователь.

Решения RDS (Remote Desktop Services) и Citrix Xenapp/XenDesktop выступают одним из превосходных примеров такой ситуации. Эти решения по большей части открываются для регистрации в системе из удалённых сетевых сред. Таким образом, их требования безопасности и работы отличаются от некого компьютера в локальной сети. Когда пользователи, которые входят в систему из другого Организационного элемента намерены иметь иные настройки, трудно поддерживать данную систему требуемым уровнем защиты. Применяя обработку петель (loopback processing) мы можем принуждать пользователей обладать только настройками политик пользователя, которые связаны с тем Организационным элементом, в котором расположены компьютеры.

Существует два режима обработки петель:

Для включения обработки петель в Групповых политиках пройдите в режим редактирования соответствующей Групповой политики и проследуйте к Computer Configuration| Policies| Administrative Templates | System | Group Policy | Configure user Group Policy loopback processing mode:

На Шри Ланке существует распространённое выражение для пояснения рискованного действия: слизывать творог с кончика ножа. Творог с мёдом это великолепно, однако если вы едите его применяя заострённый нож, имеется риск того, что вы пораните свой язык если будете не аккуратным. Однако иногда имеет смысл рискнуть (если вы когда- либо раньше пробовали творог с мёдом). Групповые политики в точности такие же; они способны выполнять множество полезных вещей, однако только тогда, когда вы делаете всё правильно. В установленной среде Active Directory связанные с Групповыми политиками проблемы являются самыми болезненными и затратным по времени задачами устранения неисправностей, так как существует очень много моментов, которые могут пойти не так как следует.

Здесь я перечисляю несколько советов, которые будут полезны при проектировании Групповых политик:

До сих пор в этой главе мы обсуждали преимущества Групповых политик и как использовать надлежащим образом Групповые политики. В качестве заключительного раздела этой главы я выбрал обсуждение некоторых полезных Групповых политик, которые могут применяться в средах. Это не означает что каждая среда должна обладать аналогичными политиками, но мы можем воспользоваться этим в качестве некого образца и наращивать его:

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

Групповые политики являются одной из центральных ценностей имеющейся среды Active Directory. По мере того как они проектируются и сопровождаются надлежащим образом, они могут действенно применяться для управления настройками компьютеров и пользователей. В данной главе мы изучили компоненты Групповых политик и их возможности. Вслед за этим мы объяснили те функциональные возможности, которые можно применять для проектирования и сопровождения жизнеспособной структуры Групповых политик. Мы также изучили рекомендации для Групповых политик. В своём последнем разделе мы прошлись по некоторым полезным Групповым политика.

В своей следующей главе мы перейдём к третьей части данной книги, которая сосредоточится на ролях сервера Active Directory. В этой части вы изучите современные функциональные возможности AD DS, включая схему, репликацию, RODC (read-only domain controller) и восстановление Active Directory.