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

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

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

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

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

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

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

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

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

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

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

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

Как и в отношении всех прочих объектов, имеющаяся база данных AD также содержит и сведения GPO. Эта информация больше связана с установками системы и ссылочным значением пути на другой набор данных. При создании некого GPO, как и в случае с прочими объектами AD, он также получает и значение 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, включая значения определённых атрибутов:

Когда мы рассматривали возможности Групповой политики, мы видели что они могут использоваться для публикации приложений, исполнения сценариев запуска/ останова и прочего. С точки зрения объектов AD, все эти настройки являются атрибутами и все такие файлы и сценарии требуется сохранять в неком центральном местоположении. Вместо того чтобы хранить их в некой базе данных, наша система сохраняет все эти связанные с политиками файлы и установки в каталоге 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. Таким образом организационные элементы способны наследовать Групповые политики, а также напрямую связываться с Групповыми политиками.

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

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

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

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

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

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

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

В целом Групповые политики обрабатываются в двух различных режимах. По умолчанию, установки Групповых политик компьютера начинают обрабатываться в процессе запуска, прежде чем блок регистрации пользователя выдаст приглашение на ввод данных. Данный режим предварительного выполнения именуется обработкой с высоким приоритетом (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. Для просмотра наследуемых данных вначале кликните по рассматриваемому OU, а вслед за этим по закладке Group Policy Inheritance

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

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

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

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

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

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

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

После блокирования наследования таких Групповых политик, единственной политикой в списке наследования является именно та политика, которая связана с данным OU.

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

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

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

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

В нашем предыдущем примере Policy 01 была превращена в принудительную. Она выступает связанной с доменом Групповой политикой. При обычных обстоятельствах при применении к OU Users наименьшее значение следования получает Policy 02. Однако будучи enforced, наименьшее значение следования будет иметь Policy 01. Когда мы рассмотрим выигравшие значения OU 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 можно создать при помощи cmdlet PowerShell New-GPO:

New-GPO -Name GPO-Test-A
		

Наша предыдущая команда создаст GPO с именем GPO-Test-A. По умолчанию он не будет связан ни с каким OU, доменом или площадкой. Из GPMC его можно просмотреть в контейнере Group Policy Objects.

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

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

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

Оба этих cmdlet можно скомбинировать для одновременного создания GPO и его связывания:

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 или при помощи cmdlet PowerShell Set-GPLink:

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

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

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

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. Она удалит этот GPO из списка Precedence, а также из списка Link Order.

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

Remove-GPO -Name GPO-Test-A
		

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

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

Групповые политики позволяют нам управлять установками компьютера и пользователя множеством способов. Однако, операционные требования среды часто изменяются в силу целого ряда причин. Например, они могут основываться на новых версиях приложений, новых требованиях безопасности им тому подобного. Мы знаем, что Групповые политики могут применяться для управления настройками по всей организации, однако не все имеющиеся требования будут поддерживаться по умолчанию. Например, на момент выпуска AD DS 2008 не было возможности иметь Групповые политики, которые были бы способны управлять установками в приложениях Office 2016. Производители и разработчики приложения могут разрабатывать административные шаблоны и публиковать их через Групповые политики для индивидуализации, управления и оптимизации своих продуктов и служб. Административные шаблоны содержат изменения на основе реестра для применяемой системы. 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 является частью конкретного GPO, а потому он всегда хранится в общей папке 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. Значение языка, применяемого при изменении политики будет приниматься на основе того языка, который применяется в соответствующей рабочей станции.

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

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

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

Для добавления фильтрации безопасности своим GPO мы можем применять GPMC или cmdlet -ы PowwerShell:

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

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

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

Для внесения этих изменений проследуйте в Групповую политику, а далее в закладку Delegation. Кликните по Advanced, выберите Authenticated Users, а после этого удалите полномочия Apply group policy:

Теперь мы можем вернуться обратно в закладку Scope и добавить необходимую группу безопасности или объекты в свой раздел Security Filtering. Это автоматически добавляет надлежащие полномочия Read и Apply group policy:

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

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

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

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

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

Для создания фильтра WMI откройте GPMC, кликните правой кнопкой по WMI Filters, а вслед за этим по New...:

Это откроет некое новое окно, в котором мы можем задать необходимый запрос WMI:

Кликнув по кнопке Add мы можем задать Namespace и Query WMI. В качестве примера, я создал некий запрос WMI для фильтрации OC Windows 10, которая запущена в 32- битной версии:

select * from Win32_OperatingSystem WHERE Version like "10.%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"
	   

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

После того как создан некий фильтр WMI, его следует подключить к необходимому GPO. Для этого проследуйте в GPMC и выберите необходимый GPO. Затем в разделе WMI Filtering выберите требующийся фильтр WMI из ниспадающего блока:

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

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

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

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

Установки Групповой политики и предпочтения Групповой политики обрабатываются двумя различными способами. Настройки Групповой политики применяются в процессе загрузки и входа пользователя в систему. После этого настройки обновляются каждые 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 также можно применять через изменение реестра; предпочтения Групповой политики делают это простым, так как применяют GUI, похожий на реальное окно настроек 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

В полученном окне Properties выберите закладку Common, кликните по Item-level targeting, а вслед за этим кликните по кнопке Targeting...:

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

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

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

Групповые политики обладают двумя основными конфигурациями. Одной является целеуказание настроек компьютера, а другой выступает целеуказание настроек конфигурации пользователя. Когда мы применяем конфигурацию пользователя к некому расположенному в OU пользователю, не имеет значения в каком именно компьютере он выполнил вход в систему - его настройки политик следуют за ним. Например, давайте предположим, что пользователь Liam располагается в OU Sales. Тот компьютер, с которого он обычно регистрируется для входа в систему также располагается в том же самом OU. Однако время от времени он он входит в систему с ноутбука в переговорной комнате, который находится в OU IT operations. OU IT operations обладает собственными назначенными ему политиками Computer Configuration и User Configuration. Однако когда Liam регистрируется в нём, он всё ещё обладает теми настройками, которые он имел в своём ПК OU Sales. Именно это является нормальным поведением Групповых политик. Тем не менее, имеются ситуации, при которых требуется применение настроек политик пользователя на основании того компьютера, в котором регистрируется данный пользователь. Решения RDS (Remote Desktop Services) и Citrix Xenapp/XenDesktop выступают одним из превосходных примеров такой ситуации. Эти решения по большей части открываются для регистрации в системе из удалённых сетевых сред. Таким образом, их требования безопасности и работы отличаются от некого компьютера в локальной сети. Когда пользователи, которые входят в систему из другого OU намерены иметь иные настройки, трудно поддерживать данную систему требуемым уровнем защиты. Применяя обработку петель (loopback processing) мы можем принуждать пользователей обладать настройки политик пользователя, которые связаны с тем OU в котором расположены компьютеры.

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

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

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

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

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

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