Как устроены групповые политики
При создании домена AD автоматически создаются два объекта групповой политики:
Политика домена по умолчанию устанавливает базовые параметры для всех пользователей и компьютеров в домене в трех плоскостях: политика паролей, политика блокировки учетных записей и политика Kerberos.
Политика контроллеров домена по умолчанию устанавливает базовые параметры безопасности и аудита для всех контроллеров домена в рамках домена.
Для вступления настроек в силу, объект групповой политики необходимо применить (связать) с одним или несколькими контейнерами Active Directory: сайт, домен или подразделение (OU). Например, можно использовать групповую политику, чтобы потребовать от всех пользователей в определённом домене использовать более сложные пароли или запретить использование съемных носителей на всех компьютерах только в финансовом подразделении данного домена.
Объект групповой политики не действует, пока не будет связан с контейнером Active Directory, например, сайтом, доменом или подразделением. Любой объект групповой политики может быть связан с несколькими контейнерами, и, наоборот, с конкретным контейнером может быть связано несколько объектов групповой политики.
Кроме того, контейнеры наследуют объекты групповой политики, например, объект групповой политики, связанный с подразделением, применяется ко всем пользователям и компьютерам в его дочерних подразделениях. Аналогичным образом, объект групповой политики, применяемый к OU, применяется не только ко всем пользователям и компьютерам в этом OU, но и наследуется всем пользователям и компьютерам в дочерних OU.
Настройки различных объектов групповой политики могут перекрываться или конфликтовать. По умолчанию объекты групповой политики обрабатываются в следующем порядке (причем созданные позднее имеют приоритет над созданными ранее):
- Локальный (индивидуальный компьютер)
- Сайт
- Домен
- Организационная единица
В эту последовательность можно и нужно вмешиваться, выполнив любое из следующих действий:
Изменение последовательности GPO. Объект групповой политики, созданный позднее, обрабатывается последним и имеет наивысший приоритет, перезаписывая настройки в созданных ранее объектах. Это работает в случае возникновения конфликтов.
Блокирование наследования. По умолчанию дочерние объекты наследуют все объекты групповой политики от родительского, но вы можете заблокировать это наследование.
Принудительное игнорирование связи GPO. По умолчанию параметры родительских политик перезаписываются любыми конфликтующими политиками дочерних объектов. Вы можете переопределить это поведение.
Отключение связей GPO. По умолчанию, обработка включена для всех связей GPO. Вы можете предотвратить применение объекта групповой политики для конкретного контейнера, отключив связь с объектом групповой политики этого контейнера.
Иногда сложно понять, какие политики фактически применяются к конкретному пользователю или компьютеру, определить т.н. результирующий набор политик (Resultant Set of Policy, RSoP). Microsoft предлагает утилиту командной строки GPResult, который умеет генерировать отчет RSoP.
Для управления групповыми политиками Microsoft предоставляет консоль управления групповыми политиками (GPMC). Используя этот бесплатный редактор групповой политики, ИТ-администраторы могут создавать, копировать, импортировать, создавать резервные копии и восстанавливать объекты групповой политики, а также составлять отчеты по ним.
По умолчанию любой член группы администраторов домена может создавать объекты групповой политики и управлять ими. Кроме того, существует глобальная группа под названием «Владельцы-создатели групповых политик»; его члены могут создавать объекты групповой политики, но они могут изменять только созданные ими политики, если им специально не предоставлены разрешения на редактирование других объектов групповой политики.
В этой же консоли можно делегировать вспомогательным ИТ-администраторам разрешения для различных действий: создание, редактирование и создание связей для определенных объектов групповой политики. Делегирование — ценный инструмент; например, можно предоставить группе, ответственной за управление Microsoft Office, возможность редактировать объекты групповой политики, используемые для управления настройками Office на рабочем столе пользователей.
Групповая политика: замыкание на себя
В данной статье я хотел бы рассказать о такой замечательной опции групповых политик, как loopback processing – замыкание на себя. Иногда сталкиваюсь с тем, что администраторы просто не знают про такую возможность и усложняют организационную структуру AD. Проще всего описать поведение данной политики на живом примере.
Итак, предположим в глобальной групповой политике Default Domain Policy определен таймаут скринсейвера в 30 минут. Данная политика настроена в разделе User Configuration.
Теперь посмотрим где расположены объекты, с которым мы будем эксперементировать:
Хотя в целом подобная настройка скринсейвера подходит в большинстве случаев, может возникнуть ситуация когда для определенных компьютеров нужно изменить поведение скринсейвера. Предположим что для компьютеров, расположенных в OU HR нам необходимо изменить поведение скринсейвера, а для двух других OU оставить поведение групповой политики по умолчанию.
Для выполнения данной задачи мы используем режим замыкания политики на себя для принудительного применения настроек пользователя в групповой политике, применяемой к организационной единице, содержащей рабочие станции. Так как все остальные пользовательские политики должны применяться в полном объеме, мы будем использовать замыкание на себя с объединением.
Создадим новую групповую политику, прикрепленную к Workstations OU.
Так как в данном случае эта политика примениться ко всем дочерним разделам, нам необходимо контролировать к каким рабочим станциям будет применяться наша политика. Для этого создадим новую группу безопасности Loopback и разделе Security Filtering удалим права Read и Apply у группы Authenticated Users. После чего дадим эти права на свежесозданную группу Loopback.
Мы знаем что опция для настройки скринсейвера настраивается в разделе User Configuration групповой политики и обычно применяется на пользователей. Однако, так как мы используем замыкание на себя, мы настроим нужное нам значение скринсейвера в разделе User Configuration новой политики ScreenSaver15 и прилинкуем данную политику на OU, где расположены рабочие станции.
Так как политика замыкания на себя фильтруется на более верхнем уровне, в политике ScreenSaver15 мы оставляем права Read и Apply по умолчанию.
Итак, настройка закончена и теперь нам необходимо приступить к проверке того факта, что для любого пользователя, залогинившегося на компьютер, находящийся в OU HR, эффективный таймаут скринсейвера будет 15 минут вместо 30-ти.
Аккаунт пользователя, под которым мы будем выполнять проверку находиться в Users OU. Он называется John.Galt.
Аккаунт компьютера находиться в HR OU и называется XP01.
И данная рабочая станция добавлена в группу Loopback.
Теперь залогинимся под указанным пользователем на данный компьютер и посмотрим на параметры скринсейвера.
Запустив результирующую политику на этой машине мы увидим что применяется именно политика ScreenSaver15 хотя OU HR содержит только объекты-компьютеры, а политика настроена в конфигурации пользователя..
Надеюсь в результате прочтения данной статьи вам удалось понять действие режима замыкания на себя. Хотелось бы отметить, что в некоторых сценариях возможно применение данной политики в режиме замены, при котором не происходит слияния. Конкретно для нашего примера это означало бы, что к любому пользователю после логона на компьютер XP01 применилась бы только политика ScreenSaver15, все остальные политики были бы отброшены.
Интересное в сети:
Качественный и недорогой монтаж камер наблюдения для вашего офиса, подъезда, дома. Широкий спект оборудования для различных режимов.
Типография “Формула цвета” предлагает качественные полиграфические услуги на современном оборудовании: оперативная печать брошюр с доставкой заказчику.
Алгоритм устранения проблем с GPO
Предположим, что у меня есть групповая политика, которая применяется на организационное подразделение «Client Computers». Политика называется «Управление UIPI». По какой-то причине пользователь жалуется, что она у него не применилась.
Из информации, об области действия групповой политики, первое на что нужно обратить свое внимание, это находится ли объект пользователя или компьютера по нужному пути. Сделать, это просто в оснастке «Управление групповой политикой» найдите вашу политику и посмотрите к каким OU она применяется, это видно на вкладке «Область (Scope)», ее еще называют областью действия политики
В моем случае, это путь root.pyatilistnik.org/Client Computers.
Так как Active Directory, это иерархическая структура, то одна OU можете быть часть дерева из других и сама включать в себя большое количество организационных подразделений. Поэтому если у вас есть вложенность, то просто зайдя в нужную OU вы можете сразу не найти нужный объект. В таком случае воспользуйтесь поиском по Active Directory. Например у меня есть рабочая станция с которой идут жалобы на применение объекта GPO. В поиске выбираем в поле «Найти» компьютеры и в имени указываем w10-cl01, после чего нажимаем «Найти». В результатах поиска вы получите выдачу. Щелкаем по нужному объекту и переходим в нем на вкладку «Объект», где смотрим «Каноническое имя объекта», по сути это его путь расположения в Active Directory. Сравниваем его с тем, что получили из области применения групповой политики и делаем вывод, попадает объект под действие или нет.
Далее убедитесь, что у вас элементарно включена связь объекта групповой политики с нужным организационным подразделением. Для этого в оснастке управления GPO, щелкните правым кликом по нужной политике и в контекстном меню проверьте, что установлена галка «Связь включена», ее так же можно проверить на вкладке «Область» в столбце «Связь задействована», должно стоять значение «да».
Следующим моментом необходимо проверить, что политика не отключена на определенный объект. Для этого перейдите на вкладку «Сведения» на нужной GPO. Нас интересует строка «Состояние GPO». По умолчанию там стоит значение «Включено», означающее, что политика будет пытаться примениться заданные в ней настройки к обоим типам объектов (Пользователю и компьютеру). Но может быть выставлено значение:
- Параметры конфигурации компьютера отключены (Computer configuration settings disabled)
- Параметры конфигурации пользователя отключены (User configuration settings disabled)
- Все параметры отключены (All setting disabled) — запретит применение политики для любого объекта
Сделано, это для ускорения применения политики к объекты. Согласитесь, что если у вас в GPO настроены изменения только для пользователя, то нет смысла проверять политику для компьютера. Поэтому системные администраторы могут отключать это, но могут и ошибиться, выключив не тот объект
Выше я вам писал, что структура OU иерархическая, а это означает, что политика прилинкованная с вышестоящего организационного подразделения применяется на нижестоящее. Но вот если у нижестоящей OU отключено наследование сверху, то он не сможет применить данную политику. Проверяется очень просто, найдите нужную вам OU, щелкните по ней правым кликом и удостоверьтесь, что не стоит пункт «Блокировать наследование».
Он кстати будет иметь характерный значок с восклицательным знаком. Данный механизм создан специально, чтобы изолировать данную OU от ненужных политик GPO.
Восстановление элементов
В ряде случаев может потребоваться особая процедура работы с объектами групповой политики — восстановление. Active Directory — программная среда, в которой происходит большое количество процессов, при этом могут возникать ситуации, при которых объекты по каким-либо причинам удаляются. Однако всегда есть шанс восстановления их предыдущих версий из резервных копий, существующих в системе.
Инструменты, необходимые для решения соответствующей задачи, также присутствуют в консоли, которую мы сегодня исследуем. С их помощью можно осуществить восстановление как одного, так и нескольких объектов соответствующего типа за счет резервных копий, располагающихся в специальной папке.
Последовательность действий пользователя в ходе решения данной задачи может выглядеть так.
Во-первых, необходимо в главном интерфейсе консоли щелкнуть на папке «Объекты групповой политики». После этого на экране отобразятся соответствующие элементы.
Во-вторых, необходимо щелкнуть правой кнопкой мышки на папке «Объекты групповой политики», после чего выбрать опцию «Управление резервными копиями».
В-третьих, необходимо выбрать место, где располагается резервная копия соответствующих настроек, с помощью специального списка, доступного в диалоговом окне интерфейса. Можно также использовать кнопку «Обзор», после чего вручную выбрать папку, в которой находятся нужные файлы.
После проведения соответствующих операций необходимо обратить внимание на список «Резервные копии». Там будут отображаться доступные для восстановления элементы
Необходимо выбрать нужные. После этого — нажать на кнопку, которая запустит процесс восстановления. Возможно, доступными окажутся несколько версий объекта. В этом случае полезно будет использовать специальный флажок, с помощью которого задается отображение на экране интерфейса только самых свежих резервных копий объектов групповой политики.
Далее нужно проверить то, насколько успешно осуществлена операция (в диалоговом окне отобразятся необходимые сведения), после чего нажать на кнопку «OK». Так осуществляется восстановление Active Directory в части удаленных объектов соответствующей системы управления корпоративной компьютерной сетью.
Проверка прав на политику
Объекты групповой политики, так же имеют свой ACL (лист доступа), это означает, что вы можете более тонко настраивать к каким объектам применяется данная политика. В редакторе «Управление групповой политикой» выберите ваш GPO. На вкладке «Область» найдите раздел «Фильтры безопасности», он отображает к каким объектам применяется политика. Данный фильтр безопасности может включать объекты:
- Пользователь
- Компьютер
- Группа безопасности
По умолчанию тут прописана группа безопасности «Прошедшие проверку (Authenticated Users)». По умолчанию в данную группу входят все доменные пользователи и доменные компьютеры
Если у вас тут выставлена другая группа или отдельные записи, то убедитесь, что нужный объект состоит в данном ACL. Хочу отметить, что если даже нужный объект присутствует в списке фильтра безопасности, то это не означает, что политика к нему применяется и тут дело все в том, что в 2014 году Microsoft изменила принцип чтения политики, таким образом, что у вас в делегированном фильтре безопасности обязательно должна присутствовать группа «Компьютеры домена» или «Прошедшие проверку» у которой должны быть прав на чтение политики. Вся соль в том, что когда вы удаляете группу «Прошедшие проверку» из фильтра безопасности, она удаляется и из вкладки делегирование.
Чтобы параметры групповой политики для пользователя успешно применялись, она требует наличия у каждой учетной записи компьютера разрешения на считывание данных GPO из контроллера домена. Удаление группы «Прошедшие проверку» может предотвратить обработку групповых политик для пользователя. добавьте группу безопасности «Пользователи, прошедшие проверку подлинности» или «Компьютеры домена», у которой есть по крайней мере разрешение только для чтения (https://support.microsoft.com/en-us/kb/316622)
Поэтому перейдите на вкладку «Делегирование» и проверьте наличие любой из групп «Прошедшие проверку» или «Компьютеры домена» и, что есть права на чтение. Если групп нет, то добавьте любую из них. Для этого нажмите кнопку «Дополнительно», далее добавить и выберите «Прошедшие проверку».
Удостоверьтесь, что выставлена галка «Чтение».
Тут же убедитесь, что нет запретов на нужный вам объект, в моем примере, это W10-CL03. Если есть снимите.
Обратите внимание на группу «КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (Enterprise Domain Controllers)» данная группа определяет, будет ли происходить репликация данной политики на другие контроллеры или нет, так что если политика отсутствует в папке SYSVOL на других контроллерах, то проверьте права у данной группы
Еще одним механизмом фильтрации групповой политики, может выступать WMI фильтры. Если они есть и ваш объект не соответствует его требованиям, то вы не сможете применить политику. Посмотреть, это можно в соответствующем разделе. В моем примере есть WMI фильтр для ноутбуков, который не даст применения политики на стационарные компьютеры. Подробнее, о создании WMI фильтров и механизме проверки WMI фильтров, читайте по ссылкам. Ниже я покажу, как на конечном компьютере увидеть, что он не подошел из-за фильтрации GPO по WMI.
ОБЪЯСНЕНИЕ 1
Режим обработки замыкания групповой политики (Loopback Policy Processing)
Если управлять пользовательскими профилями через групповые политики, то можно заметить, что некоторые настройки, например, перенаправление папок, располагаются в разделе User configuration (Конфигурация пользователя) политики.
А это значит, что если пользовательская учетная запись находится в организационном подразделении (Organization Unit, OU), на которое распространяется действие такой политики, то применяться эти настройки будут при входе пользователя в систему независимо от того, локальный это компьютер или сервер RDS. Такое поведение может быть нежелательным, вполне разумно иметь одни пользовательские настройки для сервера, другие — для локального компьютера.
Но если поместить политику с настроенными разделами User Configuration в раздел OU с серверами, то она не будет обрабатываться, так как учетные записи пользователей не находятся в этом OU.
Чтобы это произошло, существует специальная политика Loopback Policy Processing (Режим обработки замыкания пользовательской групповой политики), располагающаяся в разделе Computer Configuration (Конфигурация компьютера) -» Policies (Политики) -> Administrative Templates (Административные шаблоны) -> System (Система) -> Group Policy (Групповая политика).
У нее два режима работы — Replace (Замена) и Merge (Слияние). В первом случае происходит замещение пользовательских политик из OU пользователя, во втором — объединение с ними.
Например, на рис. 5 изображен домен с двумя организационными подразделениями — OU1 и OU2.
В первом находятся объекты учетных записей пользователей и их локальные компьютеры, во втором — объекты серверов RDS.
Если пользователь осуществляет вход в систему на локальном компьютере, то он оказывается под действием доменной групповой политики (Default domain policy), затем политики GP1 локального компьютера (которая была применена при его включении) и политики GP2 пользователя (примененной при входе в систему).
Если пользователь осуществляет вход на сервер RDS, то будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2.
Если же включить Loopback Policy Processing, то при входе на сервер RDS будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2+GP4 (в режиме Merge) или только GP4 (в режиме Replace).
При возникновении любых конфликтов настроек между политиками OU пользователя и OU сервера в режиме Merge политика в OU сервера будет иметь более высокий приоритет.
Используя несколько серверов RDS в кластере, просто необходимо управлять пользовательскими профилями. К счастью, для этого есть достаточно много возможностей со своими сильными и слабыми сторонами. Остается только выбрать то сочетание, которое лучше всего будет подходить для каждого конкретного случая.
( взято тут: http://www.xnets.ru/plugins/content/content.php?content.240.4 )
Особенности Active Directory
Групповые политики Active Directory причисляются к самым удобным вариантам настройки ПК и пользовательских сред в компьютерных сетях, работающих под управлением Windows. Задействуя данный инструмент, компания может осуществлять эффективный контроль над работой сети, поддерживать производительность инфраструктуры, повышать степень защищенности корпоративной информации.
Особенность Active Directory — это, как мы отметили выше, иерархическая структура соответствующей программной среды. Основные ее элементы — объекты. В свою очередь, их можно классифицировать на различные категории. В числе базовых – ресурсы (таковыми могут быть, например, принтеры и иная офисная техника), программные службы (например, интерфейсы обмена электронными сообщениями), а также учетные записи сотрудников компании и идентификационные данные о компьютерах. Программная среда Active Directory может предоставлять системному администратору сведения о тех или иных объектах, осуществлять управление ими, задавать критерии, касающиеся доступа к ним.
Объекты, которые являются основными компонентами групповых политик, могут вмещать в себя дополнительные элементы. Это могут быть, например, группы безопасности. Объект характеризуется рядом уникальных признаков — именем, совокупностью атрибутов (например, типов данных, которые он включает в себя). Можно отметить, что свойства атрибутов, о которых идет речь, фиксируются в схемах, определяющих специфику тех или иных объектов.
Ключевые параметры
В каких разделах интерфейса консоли содержатся ключевые параметры, влияющие на групповые политики Active Directory? В числе таковых — папки Computer Configuration, а также User Configuration. В первой содержатся параметры, которые актуальны для всех ПК, подключенных к корпоративной сети.
Неважно, какие именно сотрудники пользуются Active Directory. Авторизация под конкретным логином в данном случае второстепенна
Как правило, в интерфейсе Computer Configuration фиксируются настройки безопасности. В папке User Configuration определяются параметры, применяемые, в свою очередь, к конкретным сотрудникам. Неважно, на каком именно компьютере они собираются работать.
Рассмотрим другие ключевые параметры, которые может задействовать системный администратор, осуществляющий управление Active Directory. Например, в папке Policies располагаются настройки, которые в целом отвечают за групповую политику. В папке Preferences фиксируются параметры, имеющие отношение к предпочтительным настройкам компьютера. Они могут затрагивать самые разные компоненты операционной системы — реестр, файлы, папки. Данная область настроек, к слову, может использоваться не только как инструмент настройки групповой политики, но и для управления иного типа функциями Windows.
Обновление gpo через psexec
Я вам очень часто рассказываю в своих примерах из моей практики, об утилите PSexec и сборнике SysInternals от Марка Руссиновича. Суть метода в том, что с помощью специальной утилиты вы сможете выполнить удаленную команду, ранее я так удаленно включал RDP на сервере или клиентской машинке.
Далее вы распаковываете архив, если он в таком виде и открываете папку с утилитами SysInternals в командной строке, напомню сделать, это можно через команду cd или через правый клик с зажатым Shift по нужной папке, выбрав пункт «Открыть окно команд».
Обращаю внимание, что у вас должны быть соблюдены несколько требований:
Теперь выполните команду:
psexec \имя компьютера –i gpupdate
Обратите внимание, что параметр -i здесь важен. Это гарантирует, что PsExec взаимодействует с удаленным рабочим столом, что необходимо для обновления пользовательских политик
Если этот параметр не указан, будут обновлены только конфигурации компьютера, хотя ни PsExec, ни gpupdate не выдадут сообщение об ошибке.
В результате будет удаленный запуск утилиты gpupdate, если все хорошо, то вы получите сообщение «gpupdate exited on svt2021s01.root.msconfig.ru with error code 0».
на удаленном компьютере в журналах системы вы увидите два события 1500 и 1501.
Событие 1500: Параметры групповой политики для этого компьютера обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики.
Событие 1501: Параметры групповой политики для этого пользователя обработаны успешно. Не обнаружено изменений со времени последней успешной обработки групповой политики.
Так же вы можете подключиться вообще к удаленной командной строке, через команду:
psexec \имя компьютера –i cmd
Далее просто пишите gpupdate /force, обратите внимание я через команду hostname показал, что подключение идет с одного компьютера на другой. Если компьютер не подключен к сети, вы получите следующее сообщение об ошибке:
Если компьютер не подключен к сети, вы получите следующее сообщение об ошибке: