Vvmebel.com

Новости с мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Групповые политики применение к группе безопасности

Фильтрация объектов групповой политики по группам безопасности

Структура организационной единицы (Organizational Unit, OU) в домене Active Directory имеет критически важное значение. Она должна обеспечивать полноценное централизованное управление, быть гибкой и в то же время простой. Тем не менее, бывают ситуации, в которых требуется применение глобальных настроек для пользователей или компьютеров, принадлежащих к разным организационным единицам.

Существует возможность создать объект групповой политики (Group Policy Object, GPO) для организационной единицы или всего домена и применить его только к отдельным пользователям или компьютерам, входящим в конкретную группу безопасности. Это особенно актуально в тех случаях, когда требования конфигурации отдельных учетных записей не согласуются со структурой организационной единицы. Принцип действия одинаков как для компьютеров, так и для пользователей, но для начала стоит отфильтровать их по типам.

В моем примере на верхнем уровне домена расположены два объекта групповой политики, которые применяются ко всем объектам домена, но раздельно для пользователей и компьютеров. На рис. A показаны эти два GPO в корне домена.

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

В моем примере объекты названы в соответствии с принципами самодокументирования: «Filter-GPO-ComputerAccounts» и «Filter-GPO-UserAccounts». Имена указывают на то, что данные объекты групповой политики отфильтрованы по группам «GPO-ComputerAccounts» и «GPO-UserAccounts», которые тоже нося говорящие названия. Обе группы безопасности показаны на рис. B.

В группу безопасности «GPO-ComputerAccounts» входят две учетные записи компьютеров. Компьютеры, как и пользователи, могут входить в группы безопасности.

Определив организационные единицы и группы безопасности, можно настроить фильтры таким образом, чтобы объекты групповой политики применялись только к определенным членам группы. Для начала нужно удалить из GPO стандартный элемент «Авторизованные пользователи» (Authenticated Users) с правами чтения. Этот элемент выделен на рис. C красным.

После этого нужно добавить группу безопасности на вкладке «Безопасность» (Security) объекта групповой политики и разрешить ей чтение и применение групповой политики. На рис. B показаны настройки для группы «GPO-ComputerAccounts» и объекта «Filter-GPO-ComputerAccounts».

Обратите внимание на выделенную кнопку «Дополнительно» (Advanced) внизу окна. Если параметры безопасности конфигурируются после создания GPO, с ее помощью можно вызвать окно, в котором настраивается разрешение применять групповую политику. После этого GPO можно применять к группам безопасности.

А вы как используете фильтрование объектов групповой политики? Я могу предложить сразу несколько полезных вариантов применения, хотя злоупотреблять этой возможностью рискованно. Поделитесь своим опытом в комментариях!

Фильтрация групповых политик Windows

Фильтрация групповых политик Windows

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.

Для чего нужен механизм фильтрации GPO

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

Лично я стараюсь не создавать лишних организационных подразделений, так как, чем проще система, тем проще ею управлять. У вас может быть вообще одна OU и все навалено в ней, но это вам не мешает грамотно применять политики к конкретным объектам, благодаря фильтрации на разных этапах GPO.

Виды фильтрации групповых политик

  1. Это фильтр безопасности
  2. Это фильтр WMI
  3. Это фильтр на вкладке делегирование
  4. Это фильтр на вкладке сведения

Фильтр безопасности GPO

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

  • Пользователям
  • Компьютерам
  • Группам

то вы можете их добавить в данный фильтр, после чего нужно удалить группу «Прошедшие проверку (authentication user)«, так как в нее входят все пользователи и компьютеры домена. Давайте это попробуем. Открываем оснастку «Управление групповой политикой». В прошлый раз я создавал политику «Настройка MaxTokenSize» в задачи которой входило изменение размера токена kerberos. Предположим, что я хочу применить ее только в локальной доменной группе MaxTokenSize. Для этого я нажимаю кнопку «Добавить» в области «Фильтры безопасности«, находим ее и нажимаем «Ok».

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

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

В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).

Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку «Человек посередине (Man in the Middle)», тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи.

Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016).

Читать еще:  Вирус вулкан как удалить

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

Фильтрация GPO через ACL (Запрет GPO)

И так фильтрацию в фильтре мы сделали, чтобы политика применилась нам необходимо выбрать политику и перейти на вкладку «Делегирование». Тут нам необходимо добавить одну из двух групп «Прошедшие проверку (Authenticated Users)» или «Все компьютеры (Domain Computers)«. Я добавляю первую. Нажимаем кнопку «Добавить» и находим нашу группу.

Уровень прав оставляем «Чтение», этого будет достаточно.

Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду:

В итоге я вижу, что среди примененных объектов групповой политики, моя «Настройка MaxTokenSize» в списке присутствует.

Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.

Еще вкладку «Делегирования» используют и для запрещения, простой пример вы сделали политику которая для всех пользователей домена применяет корпоративные обои на рабочий стол. Допустим, что вам для администраторов домена или для круга избранных нужно сделать так, чтобы к ним не применялась политика. Вы создаете группу и уже ей запрещаете чтение данной политики, хоть пользователи и будут по прежнему входить в группу «Прошедшие проверку», но прочитать они ее не смогут так как явный запрет для другой группы куда они входят, гораздо сильнее и приоритетнее чем права чтения.

Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.

Далее даем права «Чтение».

Далее нажимаем кнопку «Дополнительно«, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку «Запретить«. В таком случае данная группа будет получать при попытке считать GPO «Отказано (безопасность)».

Фильтрация GPO по WMI

Еще одним действенным методом фильтровать получателей групповой политики, это использование WMI фильтров. Мы с вами их уже применяли, когда нужно было применить политику только к ноутбукам.

Простой пример вы создали политику и хотели бы ее применить скажем только на компьютеры у кого установлена операционная система Windows 7. Для нашей задачи нам необходимо создать WMI фильтр, для этого перейдем в «Фильтры WMI«, где выбираем соответствующий пункт.

Задаем имя WMI фильтра, после чего нажимаем кнопку «Добавить». Откроется окно для составления запроса. Конструкция для Windows 7 будет такая:

Номера для Win32_OperatingSystem

  • Windows Server 2019Windows 10 1809 — 10.0.17763
  • Window Server 2016Windows 10 — 10.0
  • Window Server 2012 R2Windows 8.1 — 6.3
  • Window Server 2012Windows 8 — 6.2
  • Window Server 2008 R2Windows 7 — 6.1

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

  • 1 — рабочая станция;
  • 2 — контроллер домена;
  • 3 — сервер.

Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:

Сохраняем наш WMI запрос.

Если хотите перед внедрение проверить будет ли применена групповая политика к нужному объекту, то можете провести тестирование в WMI Filter Validation Utility. Если все настроено корректно, но политика не применяется, почитайте по ссылке возможные варианты. Далее берем вашу политику и применяем к ней WMI.

Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)

Фильтрация через состояние GPO

Еще на вкладке «Сведения» есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:

  • Включено
  • Все параметры отключены
  • Параметры конфигурации компьютера отключены
  • Параметры конфигурации пользователя отключены

Групповые политики применение к группе безопасности

название исправлено для вящей информативности
dg

да. снять галку «apply policy» у прошедших проверку и добавить нужную группу.

нет. эта галочка (и галка read)- у тех кому нужно применять политику. прошедшие проверку это все пользователи в домене. у них галка должна быть снята, иначе расставление прав не имеет смысла, политика будет применяться ко всем.

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору А как сделать, чтобы эта политика не применялась для учётной записи «Администратор», но при этом он мог ею управлять (редктировать, изменять права доступа и т.д.).

Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Vby
Спасибо
Только вот ещё такой вопрос. Если политика применяется только к конфигурации компьютера, а конфигурацию пользователя не затрагивает, какой учётной записи убирать/ставить галку «apply policy»?

Учётной записи компьютера или учётной записи пользователя?

Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Если тех к кому не должна применяться политика мало — можно им тупо запретить ее читать и применять. Правда микрософт не рекомендует так делать.

Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору Ziateles
Вынеси в нижележащее OU эти компы и прикрути к им политику с включенным фаером.
А включать/выключать фаер в зависимости от залогинившегося пользователя нельзя.

нет не затронет. политики применяются только к пользователям или компьютерам.

А вот это что?
Как уже было сказано выше, политики действуют только на пользователей и компьютеры. Часто возникает вопрос: «как сделать так, чтобы определенная политика действовала на всех пользователей, входящих в определенную группу безопасности?». Для этого GPO привязывается к объекту домена (или любому контейнеру, находящемуся выше контейнеров или OU, в которых находятся все объекты пользователей из нужной группы) и настраиваются параметры доступа. Нажимаем Properties, на вкладке Security удаляем группу Authenticated Users и добавляем требуемую группу с правами Read и Apply Group Policy.

Читать еще:  Политика безопасности сети

Добавлено:
В догонку вопрос. Группа может располагаться и за пределами конкретного OU в данном случае OU1 или обязательно в него входить?

Это цитата из моей статьи.

где здесь говорится о местоположении объекта группы? или о том, что политики применяются к группам? групы используются для фильтрации области применения GPO.

Почему не применяется групповая политика к компьютеру или OU?

В этой обзорной статье я постараюсь разобрать типовые причины, из-за которых та или иная групповая политика может не применяться к подразделению (OU) или конкретному компьютеру / пользователю. Я думаю эта статья будет полезна как новичкам, так и профессионалам групповых политик AD для понимания принципов работы и архитектуры GPO. В первую очередь в статье я расскажу о возможных проблемах применения GPO, связанные с настройками самих политик на уровне домена, а не о траблшутинге применения GPO на клиентах. Практически все настройки, описанные в статье, выполняются в консоли редактора доменных групповых политик — Group Policy Management Console (GPMC.msc).

Область действия (scope) GPO

Если некой параметр политики не применятся на клиенте, проверьте область действия (scope) групповой политики. Если вы настраиваете параметр в секции Конфигурация компьютера (Computer Configuration), значит ваша групповая политика должна быть привязана к OU с компьютерами. Соответственно, если настраиваемый параметр относится к Конфигурация пользователя (User configuration).

Также проверьте, что объект, к которому вы пытаетесь применить политику находится в нужном OU с компьютерами или пользователями. Можно воспользоваться поиском по домену. OU, в котором находится объект содержится на вкладке Object в консоли ADUC.

Т.е целевой объект должен находится в OU, на который назначена политика (или во вложенном контейнере).

Фильтр безопасности GPO

Проверьте значение фильтра безопасности политики (Security Filtering). По-умолчанию на всех новых объектах GPO в домене присутствуют разрешения для группы «Authenticated Users«. Эта группа включает в себя всех пользователей и компьютеры домена. Это означает, что данная политика будет применяться на всех пользователях и ПК, которые попадают в область ее действия.

Если вы решили изменить этот фильтр безопасности, чтобы политика применялась только к членам определенной группы безопасности домена (или конкретным пользователям/ компьютерам), удалив группу Authenticated Users, убедитесь, что целевой объект (пользователь или компьютер) добавлен в эту группу AD. Также проверьте, что для группы, которую вы добавили в Security Filtering на вкладке GPO -> Delegation -> Advanced в списке разрешений присутствуют права Read и Apply group policy с полномочиями Apply.

Если вы используете нестандартные фильтры безопасности политик, проверьте, что для целевых групп нет явного запрета на применение GPO (Deny).

WMI фильтры GPO

В групповых политиках можно использовать специальные WMI фильтры. Это позволяет применить политику к компьютерам на основании некоторого WMI запроса. Например, мы можете создать WMI фильтр GPO для применения политики только к компьютерам с определенной версией Windows, к ПК в определенной IP подсети, только к ноутбукам и т.д.

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

gwmi -Query ‘select * from Win32_OperatingSystem where Version like «10.%» and ProductType=»1″‘

Если запрос возвращает любые данные, значит WMI фильтр применится к этому компьютеру.

Статус групповой политики

Проверьте статус групповой политики, перейдя в консоли GPMC.msc в свойствах политики на вкладку Details. Обратите внимание на значение в поле GPO Status.

Как вы видите, доступно 4 варианта:

  • All setting disabled – все настройки политики отключены (не применяются);
  • Computer configuration settings disabled – не применяются настройки из параметров GPO компьютера;
  • User configuration settings disabled – не применятся настройки пользовательских политик;
  • Enabled – все настройки политики применяются к целевым объектам AD (значение по –умолчанию).

Делегирование GPO

На вкладке политики Delegation указаны разрешения, настроенные для данной групповой политики. Здесь можно увидеть каким группам даны права на изменения настроек GPO, а также на разрешение или запрет применения политики. Вы можете предоставить права на управление GPO из этой консоли или с помощью мастера делегирования в ADUC. Кроме того, наличие строки доступа для Enterprise Domain Controllers определяет возможность репликации данной политики между контроллерами домена Active Directory (это нужно иметь в виду при наличии проблем с репликацией политики между DC). Обратите внимание, что права на вкладке Delegation соответствуют NTFS правам, назначенным на каталог политики в папке SYSVOL

Наследование групповых политик

Наследование это одна из основных концепции групповых политик. Политики верхнего уровня по-умолчанию применяются ко всем вложенным объектам в иерархии домена. Однако, администратор может заблокировать применение всех наследованных политик на определенный OU. Для этого в консоли GPMC нужно щелкнуть ПКМ по OU и выбрать пункт меню Block inheritance.

Организационные подразделения с отключенным наследованием политик в консоли отображаются с синим восклицательным знаком.

Если политика не применяются на клиенте, проверьте, не находится ли он в OU с отключенным наследованием.

Имейте в виду, что доменные политики, для которых включено свойства “Enforced”, применяются даже на OU с отключённым наследованием (наследованные политики, которые применяются к контейнеру доступны на вкладке Group Policy Inheritance).

Область действия и порядок применения групповых политик (LSDOU)

Чтобы запомнить особенности порядка применения групповых политик в домене, нужно запомнить аббревиатуру LSDOU. Это аббревиатура позволяет запомнить порядок применения GPO:

  1. Локальные политики компьютера (Local), настроенные через gpedit.msc (при некорректной настройке их можно сбросить);
  2. Групповые политики уровня сайта (Site);
  3. Групповые политики уровня домена (Domain);
  4. Групповые политики уровня организационного подразделения (Organizational Unit).
Читать еще:  Origin код безопасности

Последние политики имеют наивысший приоритет. Т.е. если вы включили некий параметр Windows на уровне политики домена, но на целевом OU данный параметр отключается другой политикой – это означает, что нужный параметр в результате будет отключен на клиенте (выиграет ближайшая политика к объекту в иерархии AD).

При использовании параметра Forced у GPO выигрывает та, политика находится выше в иерархии домена (например, при включении Forced у политики Default Domain Policy, она выигрывает у всех других GPO).

Кроме того, администратор может изменить порядок обработки политик (Link Order) в консоли GPMC. Для этого нужно выбрать OU и перейти на вкладку Linked Group Policy Objects. В списке содержаться список GPO, которые применяются к данной OU с указанием приоритета. Политики обрабатываются в обратном порядке (снизу-вверх). Это означает что политика с Link Order 1 выполнится последней. Вы можете изменить приоритет GPO с помощью стрелок в левом столбце, передвинув ее выше или ниже в списке.

GPO Link Enabled

У каждого объекта GPO, который привязан к организационному контейнеру AD вы можете включить или отключить связь (применение политики). Для этого нужно включить или отключить опцию Связь включена (Link Enabled) в меню политики. Если связь для политики отключена, ее иконка становится бледной. При отключении связи политика перестает применяться к клиентам, но ссылка на объект GPO не удаляется из иерархии. Вы можете активировать данную связь в любой момент.

Замыкание групповой политики

При включении опции Режим замыкания групповой политики (Loopback Processing mode) вы можете применить к компьютеру настройки, которые содержаться в секции GPO с настройками пользователями. Например, если вы примените к OU с компьютерами политику, в которой настроены параметры в секции User Configurations, эти политики не будут применены к пользователю бзз использования замыкания. Режим Loopback Processing включается в разделе Computer Configuration -> Administrative Templates -> System -> Group Policy -> Configure user Group Policy Loopback Processing mode.

У этой политики есть два возможных значение:

    Режим Merge (слияние) – к компьютеру применяться GPO основанные на расположении пользователя, а потом GPO, привязанные к компьютеру. При возникновении конфликтов между политиками OU пользователя и OU компьютера, политика в компьютер будет иметь более высокий приоритет

Диагностика применения GPO на стороне клиента

Вы можете провести диагностику применения групповых политик на стороне клиента с помощью утилит gpresult, rsop.msc и журнала событий Windows. При использовании Event Viewer нужно использовать фильтр по источнику GroupPolicy (Microsoft-Windows-GroupPolicy), а также в журнале Application and Services Logs -> Microsoft -> Windows -> Group Policy -> Operational.

Также можете познакомиться со статей, описывающей принципы диагностики при слишком долгом применении политик на клиентах.

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

Фильтрация обработки GPO с помощью групп безопасности.

Фильтрация обработки GPO с помощью групп безопасности.

Один из способов модификации области обработки GPO состоит в фильтрации применения параметров групповой политики. Для этого можно использовать Security Filtering или привязать к GPO фильтр WMI.

Фильтры безопасности. По умолчанию при создании GPO параметры поли­тики применяются ко всем прошедшим проверку пользователям. Для проверки этого параметра выберите объект GPO и перейдите на вкладку Scope (Область). Как показано на рис. 1, в разделе Security Filtering Section указано, что параметры объекта групповой политики Desktop Policy применяются ко всем членам группы Authenticated Users (Прошедшие проверку), содержащей стан­дартных пользователей, компьютеры и администраторов.

Рис. 1. Фильтры безопасности GPO

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

Вы можете указать пользователей и компьютеры, на которых будут влиять параметры GPO, модифицируя список учетных записей в списке Security Filtering (Фильтры безопасности). Для начала удалите из списка группу Authenti­cated Users. Затем с помощью кнопки Add добавьте в список соответствующие учетные записи. Хотя вы можете добавить любой принципал безопасности, лучше использовать группы безопасности Active Directory, а не добавлять в этот список отдельных пользователей или компьютеры.

Вы можете просмотреть список контроля доступа ACL, открыв вкладку Delegation (Делегирование) и щелкнув кнопку Advanced (Дополнительно). В списке контроля доступа будет указано, что каждому принципалу безопасности, добавленному в список фильтров безопасности, в GPO назначаются разрешения групповой политики Allow Read и Allow Apply. На рис. 2 показан принципал безопасности Отдел продаж с разрешениями групповой политики Read (Чтение) и Apply (Применить групповую политику).

Рис. 2. Фильтрация объектов GPO с помощью списка контроля доступа

Избирательно применять параметры групповой политики к группам удоб­но во многих ситуациях. Например, если необходимо установить отдельный пакет программного обеспечения для пользователей, принадлежащих к группе безопасности, чьи учетные записи распределены по множеству подразделений в домене. Для того чтобы установить это приложение с помощью групповой политики, объект GPO нужно связать с объектом родительского контейнера (например, объекта домена), содержащего учетные записи всех пользовате­лей, а затем модифицировать фильтр безопасности GPO, чтобы применять политику лишь к указанной группе, которая должна получить пакет програм­много обеспечения. Вы также можете привязать GPO к подразделению, но не применять его ко всем пользователям в этом OU. Для этого есть два способа. Во-первых, создать группу, содержащую все учетные записи пользователей, для которых требуются параметры групповой политики, а затем отконфигурировать только для этой группы разрешение Apply Group Policy. Во-вторых, создать группу, содержащую учетные записи всех пользователей, для которых не требуются параметры групповой политики, а затем использовать параметр Deny для разрешения Apply Group Policy, чтобы не применять политику к этим пользователям.

Ссылка на основную публикацию
Adblock
detector