Vvmebel.com

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

Фильтрация отказано безопасность

Фильтрация отказано безопасность

А есть что-то в event viewer в Microsoft-Windows-GroupPolicy?

inter71
Папка с политикой на КД видна

Для КД своя собственная политика — Default Domain controller policy.

inter71
Пользователь ПК включен в две группы на КД: расчетчики, обновления wsus
политика «обновление wsus» применяется к конфигурации компьютера
В обоих политиках в делегировании добавил «прошедшие проверку» на чтение
Пользователь ПК и компьютерная политика WSUS никак не связаны и членство пользователя в группе WSUS ни на что не влияет. Authenticated users в политиках присутствуют по умолчанию и их лучше не трогать без нужды.

Где эта политика «обновление wsus» применяется, на уровне корня домена или же специфической OU?

Спасибо всем. Немного изменил.
Джамаль
Да, я может не правильно написал, я имел ввиду политику, применяемую не к КД, а к домену.
IlyaK
Почитал, там вроде другая проблема, у меня доступ к папке с политикой есть.
Что сделал, удалил политику, создал заново, назвал пока test, для пользователя просто добавил выполнить в пуск, для компьютера добавил обновления, к пользователю применяется, к компьютеру нет.
А прошедших проверку в делегировании у меня по умолчанию нет. Она у меня по умолчанию в фильтре безопасности.

Программа формирования отчета групповой политики операционной системы
Microsoft (R) Windows (R) версии 2.0
© Корпорация Майкрософт (Microsoft Corporation), 2017. Все права защищены.

Создано ?22.?05.?2017 в 17:45:19

Конфигурация ОС: Рядовая рабочая станция
Версия ОС: 10.0.15063
Имя сайта: Default-First-Site-Name
Перемещаемый профиль: Н/Д
Локальный профиль: C:Userstest_r
Подключение по медленному каналу: Нет

Конфигурация компьютера
————————
CN=TEST_R,CN=Computers,DC=komitet,DC=local
Последнее применение групповой политики: 22.05.2017 в 17:41:45
Групповая политика была применена с: domainr.komitet.local
Порог медленного канала для групповой политики: 500 kbps
Имя домена: KOMITET
Тип домена: Windows 2008 или более поздняя версия

Примененные объекты групповой политики
—————————————
Default Domain Policy
Политика паролей домена
Always Off

Следующие политики GPO не были применены, так как они отфильтрованы
———————————————————————
Local Group Policy
Фильтрация: Не применяется (пусто)

test
Фильтрация: Отказано (безопасность)

Компьютер является членом следующих групп безопасности
——————————————————
Администраторы
Все
Пользователи
СЕТЬ
Прошедшие проверку
Данная организация
TEST_R$
Компьютеры домена
Обязательный уровень системы

Конфигурация пользователя
—————————
CN=test_r,OU=BUH,OU=Komitet,DC=komitet,DC=local
Последнее применение групповой политики: 22.05.2017 в 17:42:06
Групповая политика была применена с: domainr.komitet.local
Порог медленного канала для групповой политики: 500 kbps
Имя домена: KOMITET
Тип домена: Windows 2008 или более поздняя версия

Следующие политики GPO не были применены, так как они отфильтрованы
———————————————————————
Сетевой диск Пенсионный
Фильтрация: Отказано (безопасность)

Local Group Policy
Фильтрация: Не применяется (пусто)

Сетевой диск Сбербанк
Фильтрация: Отказано (безопасность)

Пользователь является членом следующих групп безопасности
———————————————————
Пользователи домена
Все
Администраторы
Пользователи
ИНТЕРАКТИВНЫЕ
КОНСОЛЬНЫЙ ВХОД
Прошедшие проверку
Данная организация
ЛОКАЛЬНЫЕ
Бухгалтерия
Komitet
обновления wsus
Высокий обязательный уровень

Почему перестали работать некоторые 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

Фильтрация обработки 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, чтобы не применять политику к этим пользователям.

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

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

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

У меня проблема с моим доменом, если групповые политики не применяются.

В настоящее время у меня есть две группы безопасности; 1) 32-битные клиенты 2) 64-битные клиенты В эти две группы входят наши разные компьютеры под управлением 32-битной и 64-битной Windows 7.

В консоли управления групповыми политиками я создал две политики, которые влияют как на рабочий стол пользователя, так и на настройки компьютера. Теперь все, что я хочу сделать, это установить так, чтобы 32-битная группа получала 32-битную политику, а 64-битные компьютеры получали 64-битную политику, но она не работает.

Следуя различным инструкциям в Интернете по настройке фильтрации безопасности, я связал объект групповой политики с доменом, перешел на вкладку делегирования, открыл ACL, снял флажок «Применять для аутентифицированных пользователей», добавил группу 32 или 64, затем щелкнул «прочитать и применить для их. Затем я вернулся к клиенту (в данном случае это 64-битный ПК), и после завершения gpupdate /force я запустил gpresult, и он говорит, что объект групповой политики не был применен из-за «Отказ в доступе (фильтрация безопасности)» ,

Это сбило меня с толку, так как я проверил, что ПК находится в 64-битной группе, проверил настройки чтения и применения, но не повезло. Я пытался добавить и удалить проверенных пользователей на вкладке «Фильтрация безопасности», но безуспешно.

Это меня раздражает, потому что это должно быть так просто!

Любая помощь будет принята с благодарностью.

Настройка: Windows Server 2008

4 ответа

Сообщение «Отказано в доступе (фильтрация безопасности)» обычно означает, что настройки компьютера не были применены из-за gpupdate не был запущен из командной строки с повышенными правами.

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

Windows 7 x64:
SELECT * FROM Win32_OperatingSystem ГДЕ версия LIKE «6.1%» И ProductType = «1» И OSArchitecture = «64-разрядная версия»

Windows 7 x86:
ВЫБЕРИТЕ * ИЗ Win32_OperatingSystem, ГДЕ версия ПОЛНОСТЬЮ «6.1%» И ProductType = «1», А НЕ OSArchitecture = «64-битная»

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

У них не будет нового членства в группе до тех пор, пока они не получат новый, который по умолчанию составляет около недели (или до перезагрузки).

Я столкнулся с той же проблемой и обнаружил, что, поскольку я связал объект групповой политики, мне пришлось выбрать ярлык объекта групповой политики «Выбор делегирования» в правой панели. Выберите Advanced, Authenticated Users и установите флажок «Применить групповую политику», как он уже прочитал.

Затем я вернулся на сервер и запустил (из командной строки с повышенными правами) gpudate /force .

Ответ Дерека К привел меня к острому решению для меня. Я применял политику к компьютеру, но только пользователи имели разрешение на применение. Добавил компьютеры в разрешения, и все было хорошо.

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