Я помню, как где-то читал, что рекомендуется не вносить изменения непосредственно в объект групповой политики домена по умолчанию, а вместо этого создать новый объект групповой политики, который наследуется от объекта по умолчанию.
Звучит разумно. Я разработчик, поэтому мне нравится идея инкапсуляции.
Однако я не могу понять, как заставить мой новый GPO унаследовать от Default. Я создал и связал его в домене, но изменения в Default не отражаются в новом.
Вы правы, что обычно рекомендуется оставить GPO домена по умолчанию в покое.
Если я правильно понимаю ваш вопрос, вам нужен другой объект групповой политики, связанный на том же уровне (т. Е. С доменом на верхнем уровне), но если в вашем настраиваемом объекте групповой политики есть какие-либо параметры, которые конфликтуют с тем, что находится в объекте групповой политики домена по умолчанию, тогда настройки в вашем настраиваемом объекте групповой политики должны иметь приоритет.
В этом случае вы хотите посмотреть на порядок ссылки групповых политик.
Объект групповой политики с наименьшим порядком ссылок обрабатывается последним и, следовательно, имеет наивысший приоритет.
Вы можете изменить порядок связывания объектов групповой политики в консоли управления групповой политикой. Это просто стрелки вверх и вниз, которые меняют порядок объектов групповой политики. Если ваш объект групповой политики имеет порядок ссылок 1, то он обрабатывается последним, что означает, что он имеет приоритет над другими объектами групповой политики в том же контексте (связан на том же уровне) или перезаписывает объект групповой политики домена по умолчанию только для параметров, которые настроены в вашем пользовательский GPO. Для параметров, которые вы не настраиваете в пользовательском объекте групповой политики, по-прежнему будут применяться параметры объекта групповой политики домена по умолчанию (если он настроен).
Вы неправильно понимаете, что такое наследование групповой политики и что оно означает. Объекты групповой политики не наследуют параметры друг от друга. Изменения, которые вы вносите в один объект групповой политики, применимы к этому объекту групповой политики, другие объекты групповой политики не наследуют настройки от другого объекта групповой политики.
Я уверен, что кто-то еще здесь опубликует пространный и познавательный ответ о наследовании групповой политики, поэтому я воздержусь от этого. Достаточно сказать, что если вы хотите оставить свой объект групповой политики домена по умолчанию нетронутым, но хотите создать новый объект групповой политики со всеми настройками объекта групповой политики домена по умолчанию, в который вы затем можете внести изменения, тогда вы можете просто сделать копию GPO домена по умолчанию, переименуйте его и свяжите с доменом. Затем вы можете внести любые изменения в этот новый объект групповой политики.
Следует иметь в виду, что если вы не впадаете в экстравагантности, такие как контейнеры с заблокированным наследованием или GPO с фильтрами безопасности, излишне настраивать один и тот же параметр для более чем одной политики, особенно если обе политики связаны с одним и тем же контейнером. . Таким образом, вы обычно хотите создать новый объект групповой политики, а не копировать существующий.
Если вы не хотите отключать и отменять привязку политики домена по умолчанию, вы не хотите ее копировать. Оставьте его в покое и дайте ему настроить большинство параметров. Создайте новый объект групповой политики, который изменяет только то, что вы хотите изменить. В идеале ваша политика домена по умолчанию не должна содержать никаких настроек (или, самое большее, только стандартные политики учетных записей, локальные политики безопасности и политики открытых ключей). См. Пример наших настроек политики домена по умолчанию:
Все остальное должно быть определено в создаваемой вами базовой политике. Не беспокойтесь об определении каких-либо параметров в этой базовой политике, которые уже применяются в вашей политике домена по умолчанию. Просто определите любые новые настройки, которые вы решите применить здесь. Подробнее о причинах ниже.
Поскольку я обедаю, это скорее «быстро и грязно», чем «долго и познавательно», тем не менее, важно хорошо понимать наследование, чтобы настройки политики работали так, как вы ожидаете. В этом случае «быстро и грязно» означает «меньше времени, потраченного на удаление содержимого». Идите по разделам.
Сосредоточьтесь на «Не копируйте GPO!» подзаголовок. В других разделах основное внимание уделяется фактической функции наследования и его правильному использованию, нюансам, почему вы не должны копировать объекты групповой политики, и очень редким, нескольким исключениям, подтверждающим правило.
На изображении представлен обзор того, как работает наследование. Изображения взяты из консоли управления групповой политикой Microsoft, которая визуализирует параметры групповой политики. Не паникуйте, я расширю картинку:
Когда вы нажимаете «Domain.Forest.com» (или любой контейнер, например «Контроллеры домена»), на правой панели появляется изображение ниже:
Вы заметите, что у нас есть две политики, настроенные с более высоким порядком ссылок, чем политика домена по умолчанию. Они будут применять свои настройки после обработки политики домена по умолчанию и перезаписывать любые настройки, которые с ней конфликтуют. Однако если политика домена по умолчанию определяет параметры, которые они не определяют, эти параметры все равно будут применяться, поскольку они не были перезаписаны.
Например, предположим, что политика домена по умолчанию предусматривает, что для служб автонастройки проводной сети и автонастройки беспроводной локальной сети задано значение «Автоматический запуск» (Конфигурация компьютера \ Параметры Windows \ Параметры безопасности \ Системные службы). Если политика «Безопасность домена» затем предусматривает, что автонастройка WLAN должна быть установлена на «Отключено» и что все события входа в систему должны проходить аудит (Конфигурация компьютера \ Параметры Windows \ Параметры безопасности \ Локальные политики \ Политика аудита), то это результирующий набор политик. (RSoP):
Проводная автонастройка: автоматический запуск
Автонастройка WLAN: отключено
Аудит входа в систему: успех, сбой
Таким образом, параметр автонастройки проводной сети был сохранен из политики домена по умолчанию, потому что он не был перезаписан. Но новый параметр автонастройки WLAN был перезаписан, поскольку он был 1) определен и 2) политикой с более высоким приоритетом.
Если мы выберем «Политика домена по умолчанию» на втором изображении и нажмем единственную стрелку вверх в левой части этого изображения (изменив порядок ссылок), политика домена по умолчанию теперь будет иметь более высокий приоритет, чем Домен Политика безопасности. RSoP сейчас:
Проводная автонастройка: автоматический запуск
Автонастройка WLAN: автоматический запуск
Аудит входа в систему: успех, сбой
Помните об этом при определении параметров политики. Определение параметра (например, включение службы) в политике порядка ссылок 3, а затем повторное определение его в политике порядка ссылок 2, является расточительным. Независимо от того, включает ли политика порядка ссылок 2 службу или нет (продолжение нашего примера). Не стесняйтесь разделять настройки между политиками для упрощения администрирования и создания логических групп настроек, но никогда не определяйте один и тот же параметр более одного раза для нескольких политик на одном уровне иерархии.
Также известно, что обработка объектов групповой политики приводит к увеличению времени входа на рабочие станции. Чем больше политик нужно обработать и чем больше параметров в политике, тем медленнее вход.
Определите параметр один раз в политике с соответствующим именем и не переопределяйте его на том же уровне контейнера.
Вот почему вы хотите создавать новые политики, а не копировать их. В противном случае политики обрабатываются один раз. Затем политика с более высоким приоритетом обрабатывает их все снова, и единственным преимуществом будет один или два параметра, которые вы изменили по сравнению с исходной политикой.
Вместо этого эти параметры можно просто поместить в новый, иначе пустой объект групповой политики. Затем обрабатываются одна или две дополнительные настройки, а не сотни. В идеале, затем удалите эти параметры из исходной политики, чтобы не обрабатывать и повторно обрабатывать параметры.
Единственные случаи, когда вы должны указывать параметры, которые конфликтуют, - это когда у вас есть контейнеры более низкого уровня, переопределяющие настройки, применяемые контейнерами более высокого уровня.
Например, вы можете включить службу автонастройки WLAN в своей политике безопасности домена, но отключить ее для своей политики контроллера домена (в контейнере контроллеров домена). В этом случае приоритет имеет политика нижнего уровня, и ваши контроллеры домена не пытаются автоматически настраивать беспроводную локальную сеть. Однако ваши рабочие станции и ноутбуки, унаследованные от корневого домена и не находящиеся в контейнере «Контроллеры домена», по-прежнему получают настройку для включения автонастройки WLAN и попытки подключения к беспроводной сети, если она доступна с использованием профилей WLAN, определенных вашей политикой. .
Опять же, это не повод для копирования объектов групповой политики. Просто создайте новый объект групповой политики на соответствующем уровне иерархии и определите только те параметры, которые вы хотите перезаписать.
Возвращаясь к управлению наследованием, «Связанные объекты групповой политики» можно редактировать, но отображаются только групповые политики, связанные с текущим контейнером (для этой цели корень домена считается контейнером). У каждого контейнера свой порядок ссылок. «Наследование групповой политики» дает вам полное представление, которое выглядит почти так же для корневого домена (обратите внимание, что несвязанная политика «Политика паролей» не отображается):
Но если вы посмотрите на окно наследования из контейнера, расположенного дальше по дереву (также известного как иерархия домена):
Обратите внимание, что политики из контейнеров нижнего уровня имеют более высокий приоритет. Политики из контейнеров более низкого уровня всегда будут запускаться после политик из контейнеров более высокого уровня, перезаписывая их настройки. Порядок связывания важен только в контексте текущего контейнера, контейнеры более низкого уровня всегда будут иметь приоритет над контейнерами более высокого уровня независимо от порядка связывания. Как и раньше, если политика нижнего уровня не указывает параметр, параметр политики верхнего уровня не перезаписывается и продолжает применяться.
Мы уже сталкивались со случаями, когда НЕ СЛЕДУЕТ копировать GPO. Предположим, вы хотите создать контейнер с заблокированным наследованием. В этом случае к нему будут применяться только политики, напрямую связанные с этим контейнером. Контейнеры ниже контейнера с заблокированным наследованием будут по-прежнему наследовать политики от контейнера с «заблокированным наследованием» (как если бы это был корень домена), если только они сами не настроены на блокирование наследования.
В этом случае, если вам нужно вырезать большое количество корпоративных политик, но по-прежнему требуется большая часть настроек из некоторых конкретных объектов групповой политики, находящихся на более высоком уровне иерархии, просто добавьте ссылку групповой политики на более высокий уровень групповой политики. Щелкните правой кнопкой мыши контейнер с заблокированным наследованием и выберите «Связать существующий объект групповой политики». Выберите нужный объект групповой политики из списка.
Допустим, у вас есть контейнер с заблокированным наследованием, и вам нужно несколько сотен настроек из объекта групповой политики, расположенного выше в иерархии. Также вам нужно изменить несколько десятков настроек в той же политике. В этом случае допустимо скопировать политику, переименовать ее, внести изменения, а затем связать ее с вашим контейнером с заблокированным наследованием.
В этом случае из-за способа настройки наследования клиенты не обрабатывают как исходную политику, так и ее копию. Они обрабатывают только одно или другое, в зависимости от того, где они находятся в иерархии. Если вы перестанете использовать группы с фильтром безопасности, применяются те же правила.
Если вы решили смешать фильтрацию безопасности с обработкой обратной связи, прочитайте это. Сначала попробуйте не использовать ни фильтрацию безопасности, ни шлейф. В противном случае попробуйте использовать режим замены. Если вы используете режим слияния, вам нужно будет использовать дополнительные параметры безопасности, чтобы разрешить чтение учетных записей компьютеров, но не применять разрешения к групповой политике. Не просто добавляйте их к фильтру безопасности - это подразумевает, что применяйте, а также читайте!
Наконец, если вы запускаете тестовую или подготовительную среду, вам часто нужно переносить объекты групповой политики между доменами. Есть способы сделать это, используя Таблицы миграции GPO. Если параметры вашей политики не ссылаются на участников безопасности домена (не беспокойтесь о параметрах безопасности в самом объекте групповой политики), более простой способ - использовать PowerShell.
Создайте новую пустую папку с файлами на машине в исходном домене. На том же компьютере выполните следующие команды:
import-module grouppolicy
backup-GPO -GUID "<aka Unique ID from GPMC including parenthesis - select the GPO in the left-hand pane and then select the Details tab>" -path "<Backup Path>"
Скопируйте папку с файлами из исходного домена на компьютер в целевом домене. Обратите внимание на новую подпапку вашего пути к резервной копии сверху - в ней будет заключенный в круглые скобки номер, который выглядит как GUID. Я буду называть это «папкой уникального идентификатора». Убедитесь, что также присутствует файл manifest.xml.
Создайте новый пустой объект групповой политики в целевом домене, запишите его уникальный идентификатор и выполните следующие команды:
import-module grouppolicy
import-gpo -targetGUID "<Unique ID from GPMC of new policy in target domain>" -backupID "<Unique ID folder name from your backup path>" -path "<The parent folder, under which your unique ID folder sits>"
Все настройки из вашего GPO в исходном домене теперь будут содержаться внутри вашего GPO в целевом домене.