Vvmebel.com

Новости с мира ПК
9 просмотров
Рейтинг статьи
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 можно применять к группам безопасности.

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

Почему перестали работать некоторые GPO после установки MS16-072

На прошлой неделе Microsoft выпустила обновления безопасности, меняющих стандартную схему работы механизма применения групповых политик Windows. Речь об обновлениях, выпущенных в рамках бюллетеня MS16-072 от 14 июня 2016 года, который предназначен для устранения уязвимостей в механизме GPO. Разберемся для чего выпущено это обновление и что нужно знать системному администратору об изменениях в применении групповых политик.

Обновления из MS16-072 устраняют уязвимость, позволяющую злоумышленнику реализовать атаку Man in the middle (MiTM), и получить доступ к трафику, передаваемому между компьютером и контроллером домена. Для защиты от уязвимости разработчики MS решили изменить контекст безопасности, в котором получаются политики. Если ранее, пользовательские политики получались в контексте безопасности пользователя, то после установки MS16-072, пользовательские политики получаются в контексте безопасности компьютера.

В результате многие пользователи обнаружили, что после установки обновлений из данного бюллетеня, перестали применяться некоторые политики. GPO со стандартными разрешениями, у которых в Security Filtering даны права на Read и Apply Group Policy для группы Authenticated Users, применяются как обычно. Проблема наблюдается только с политиками, на которых настроена фильтрация безопасности (Security Filtering) и из разрешений которых удалена группа Authenticated Users .

Во всех предыдущих рекомендациях при необходимости использовать Security Filtering MS всегда советовали удалять группу Authenticated Users и добавлять группу безопасности пользователей с правами Read и Apply.

После установки обновления MS16-072 /KB3159398 теперь для успешного применения политики, права Read на доступ к объекту GPO должны быть также и у учетной записи самого компьютера.

А так как под Authenticated Users подразумеваются, как пользовательские, так и компьютерные учетки, то удаляя эту группу, мы тем самым блокируем доступ к GPO.

Чтобы решить проблему, нужно удалить обновление (не верный, но действенны способ) или с помощью GPMC.MSC для всех политик, у которых используется фильтрация безопасности по пользовательским группам, на вкладке Delegation добавить группу Domain Computers (нужны права только на Read).

Таким образом, у компьютеров домена появится право на чтение этой политики .

Чтобы найти все объекты GPO в домене, у которых в Security Filtering отсутствует группа Authenticated Users, можно воспользоваться таким скриптом:

Get-GPO -All | ForEach-Object <
if (‘S-1-5-11’ -notin ($_ | Get-GPPermission -All).Trustee.Sid.Value) <
$_
>
> | Select DisplayName

Для больших и сложных инфраструктур с запутанной структурой групповых политик для поиска проблемных политик можно воспользоваться более удобным PowerShellскриптом MS16-072 – Known Issue – Use PowerShell to Check GPOs

Фильтрация групповых политик 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. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:

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

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

Структура организационной единицы (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 можно применять к группам безопасности.

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

Отказано в доступе фильтрация ограничений безопасности

Вы хотите сказать, что объекты в списке «безопасность» имеют друг перед другом какие-то приоритеты? :confused:

Это сейчас не приоритетно.

Ответьте на мой вопрос — » Какие из этих двух разделов затрагивает Ваша политика?»

Если я хочу, чтобы политика применялась для компа — нужно использовать группу с компом, если для юзера — с юзером. Да прекрасно я понимаю, к чему какая политика применяется. Я же представил распечатки gpresult. Данная утилита русским языком расписывает что куда применилось, а что — нет. Другое дело, что причины этого определить сложнее.

Вобщем-то у меня получилось, докладываю:
Повоевав с утра с VMware (VMware — дерьмо, VirtualPC — дерьмо), соорудил изолированный домен и приступил к тренировкам на кошках.
Довольно скоро выяснил, что фильтрацию по группам безопасности можно выполнить так: Для «Прошедших проверку» оставляем применение политики, а для группы — чтение (наоборот не работает). В этом случае на компе, не вошедшем в группу, gpresult вещает, что:

Читать еще:  Удалить антивирус mcafee

Следующие политики GPO не были приняты, поскольку они отфильтрованы

Не изобретайте велосипед. Его изобрели уже давно и написано много книг, как им управлять ПРАВИЛЬНО.
Корректная работа политики гарантируется только при правильной установке прав. А именно — совокупности параметров Чтение / Применение. Либо мы явно запрещаем чтение/применение, либо мы явно разрешаем чтение и применение.

Я еще раз прошу ответить на мое самое первое сообщение. В каких разделах ГП proxy2 сделаны изменения?

«Я хочу чтобы она применялась не для всех». Здесь есть несколько вариантов. Целесообразность каждого из них оценивается исходя из полноты предоставляемой информации.

Конфигурация пользователя/Конфигурация Windows/Настройка Internet Explorer/Подключение/Параметры прокси-сервера.
Данный раздел имеется только для юзеров, поэтому применяется группа с пользователями.

1. Цепляем к домену/сайту/OU. Главное чтобы на этом уровне содержались нужные нам пользователи. Если все пользователи находятся в отдельном OU, то цепляем именно к нему.
2. Добавляем нужную группу. Задаем явно разрешающее право — чтение и применение ГП.
3. Удаляем группу «Прошедшие проверку» или снимаем галку «Применение ГП» .
4. Проверяем.

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

Политики отрабатываются в порядке L-S-D-OU. Сверху вниз.
OU находится в самом низу. Политика примененная к уровню домена применяется КО ВСЕМ OU этого домена.
Так что если вы ее применили на уровне домена, а фильтруете на уровне групп, то все нормально будет работать. И применена она будет ко всем интересующим нас пользователям, неважно в каких контейнерах или OU они у нас будут находиться.

Так в том то и вопрос, что не работает она так!

1) Вы точно снимаете галку с параметра «Применение ГП» у группы «Прошедшие проверку» или ВЫ ставите запрет? Если ставите запрет — оно и не будет работать.

2) Удалите группу «Прошедшие проверку».

Я не понимаю, почему у Вас не работает. У меня так настроено 2 политики — никаких проблем.
Хоть удаляй «Прошедших проверку», хочешь снимай галку с права применения — все работает как требуется.

Извиняюсь, вчера у меня интернет лег.

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

. Вобщем я выяснил что политика все-таки работает как должно.
Но как трудно это было выяснить! Судите сами.
Сегодня пробовал на рабочем домене. Осторожно — для «Прошедших проверку» оставляя только одну галку — «применение». Политику смотрел на своём компе (под учеткой админа домена). Получалось как я и описывал выше:
для группы — чтение, для «Прошедших проверку» — применение — политика применяется.
Убираю применение у «Прошедших проверку»
для группы — чтение и применение — политика НЕ применяется.
пишет
Фильтрация: Отказано (безопасность)
Причем как то странно работает: при изменении разрешений ситуация менялась после 2-го запуска gpupdate /force и gpresult. Видимо кеширование доменной информации.

Ладно, запустил VirtualPC. Стал проверять виртуальный комп в рабочем домене.
И — о, чудо. GPO заработал как положено! Если кто-нибудь объяснит это с научной точки зрения, буду признателен.

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

Вот такие опыты с групповыми политиками.

P.S. Буквально на днях видел ресурс, где описывалась схожая ситуация. Там тоже товарисч оперировал комбинацией разрешений для группы безопасности и «Прошедших проверку». Никак не могу найти в истории посещений.

Сегодня пробовал на рабочем домене. Осторожно — для «Прошедших проверку» оставляя только одну галку — «применение». Политику смотрел на своём компе (под учеткой админа домена). Получалось как я и описывал выше:
для группы — чтение, для «Прошедших проверку» — применение — политика применяется.
Убираю применение у «Прошедших проверку»
для группы — чтение и применение — политика НЕ применяется.
пишет

Ну вот опять.
1. Чтобы политика могла быть прочитана ВСЕМИ клиентами, группе «Прошедшие проверку» должно быть выставлено разрешение на чтение.
2. Чтобы применить эту политику конкретным клиентам, мы должны этой группе выставить чтение и применение + выполнить условие пункта 1 ИЛИ(. ) удаляете группу «Прошедшие проверку» из списка.
3. Третьего не дано 😀

Тоесть в идеале должно быть так:
1. Прошедшие проверку — разрешаем «чтение», «Применение. » оставляем пустой.
2. Добавляем группу «нужные пользователи» — разрешаем И чтение И применение.

1. Удаляем группу «Прошедшие проверку»
2. Добавляем группу «нужные пользователи» — разрешаем И чтение И применение.

Все. Все остальное от лукавого.

Все остальное от лукавого
Тока на него и остается думать. 🙂

Я описал факты — попытки фильтрации по группам в трёх разных условиях:
1. Рабочий клиент, рабочий домен.
2. Виртуальный клиент, рабочий домен.
3. Виртуальные клиент и домен.

Только во втором случае фильтрация по группам сработала так как положено.

Вобщем, остаётся грешить только на какие-то алгоритмы кэширования. Получается, что политика не всегда применяется (или обновляется) немедленно, несмотря на gpupdate.

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