Как обойти обработку петли GPO для некоторых пользователей?
Как вы, наверное, знаете, обработка петли - это функция групповых политик Active Directory, которая применяет настройки пользователя в объекте групповой политики к любому пользователю, который входит на компьютеры в области действия объекта групповой политики (тогда как стандартным поведением будет применение пользовательских настроек только в том случае, если учетная запись пользователя действительно находится в области действия GPO). Это полезно, когда вы хотите, чтобы все пользователи, входящие в систему на определенном компьютере, получали некоторую политику пользователя, независимо от того, где их учетные записи фактически расположены в AD.
Проблема: когда обработка обратной связи включена, объект групповой политики, содержащий настройки пользователя, применяется ко всем всем , использующим эти компьютеры, и вы не можете обойти это, используя списки управления доступом к объекту групповой политики, потому что на самом деле он применяется не к пользователям , а к компьютерам .
Вопрос: как можно обойти обработку обратной петли для определенных пользователей, которым необходимо войти в систему на этих компьютерах, но не должны подпадать под эти параметры политики?
Показательный пример: существует несколько терминальных серверов, где объекты групповой политики с обработкой обратной связи используются для наложения жестких пользовательских ограничений на всех, кто входит в них (в основном они должны иметь возможность запускать только несколько приложений, одобренных компанией); но это относится даже к администраторам домена , которые, таким образом, лишены возможности даже запустить командную строку или открыть диспетчер задач. В этом сценарии, как я могу сказать AD не применять эти параметры, если входящий в систему пользователь принадлежит определенной группе (например, администраторам домена)? В качестве альтернативы подойдет даже противоположное решение («применять эти настройки только к пользователям, принадлежащим к определенной группе»).
Но, пожалуйста, помните, что здесь речь идет о кольцевой обработке . Политики применяются к компьютерам , а пользовательские настройки внутри них применяются к пользователям только потому, что они входят в систему на этих компьютерах (да, я знаю, что это сбивает с толку, обработка обратной связи является одним из из самых сложных вещей, которые нужно разобраться в групповых политиках).
Думаю, решением будет фильтрация WMI (именно так я сделал это на своем месте).
Вы создаете фильтр WMI, который улавливает те рабочие станции, которые вам нужны.
Вы создаете объект групповой политики только с пользовательскими настройками и с фильтрацией безопасности.
Вы соедините их вместе,и поместите объект групповой политики в контейнер пользователей.
Таким образом, WMI-фильтрация определяет компьютер, к которому он применяется, и фильтр безопасности, фильтрующий пользователей, к которым он применяется.
И отбрасывает петлю.
Это доставит вам больше головной боли, чем вы ожидали, поскольку это применимо не только к указанному объекту групповой политики, в котором он настроен, но и ко всем политикам, применяемым к компьютерам.
Обновление
Если у вас есть kb3163622 , установленный на ваших рабочих станциях, вы можете сделать то же самое, используя только группы безопасности.
Это обновление изменяет способ применения политик пользователей.
С этого момента пользовательские политики фактически применяются как в контексте безопасности компьютера, так и в контексте безопасности пользователя.
Поэтому, если вы включите фильтрацию безопасности этого объекта групповой политики для компьютеров и пользователей, к которым он должен применяться, это будет делать тот же трюк, что и WMI (при условии, что вы не собираетесь выполнять какой-то сложный запрос).
Запрещающий ACE для разрешения «Применение групповой политики» для рассматриваемых участников безопасности (пользователь / группа) в групповых политиках с пользовательскими настройками в компьютерном подразделении будет препятствовать групповым политикам пользователей, связанным в компьютерное ОУ из приложения.
Однако, если обработка политики обратной связи настроена для режима замены, политики группы пользователей, которые находятся в области действия для местоположения учетной записи пользователя (а не для компьютера), будут игнорироваться.