Создание wmi фильтров для групповых политик (gpo) в домене ad

Create a WMI filter and use it

Add a WMI filter

1. Open the Group Policy Management console.

2. Click on the WMI Filters 1 folder located in the tree on the right.

3. At this location, we will find all the WMI filters that have been entered, a WMI filter can be used on several group policies.

4. To create a new filter, right-click in the central area and click on New 1.

5. Name the WMI filter 1 then click on the Add button 2.

6. By default, the namespace to select is root\CIMv2, which is the one you want to use. In the query area 1, enter the WMI query you want to apply and click OK 2.

7. We can see that the query is added 1, click on the Save button 2 to save the filter.

8. The WMI filter is added to the list.

Add a filter to Group Policy

1. Click on the Group Policy (or link) where you want to apply a filter by going to the Scope 1 tab.

2. In the WMI Filtering section 1, select the filter from the drop-down list 2.

3. A confirmation message is displayed, click on the Yes button 1 to confirm the application of the filter.

4. Once confirmed, we can see that the WMI filter is selected.

Now you know how to apply a WMI filter to Group Policy.

First – Setting done from Active Directory

Open the Active Directory Administrative Center:

• Go to ISL -> Users
• Right click and select New -> User
• Create a new user account (normal user) and specify their User Principle Name (UPN) login as “wmiuser@ISL.local“. 
• Make sure “Member of” is set to “Domain Users” so that the user is in a valid group.

1 – Create the Group Policy Object

Open the Group Policy Management:

• Create a new GPO and name it WMI Access
• Link it to ISL.local domain (drag and drop the it on ISL.local)
• Make sure that the GPO will be applied to all machines in the domain to be scanned (WMI adjust Security Filtering, etc.)

2 – Settings GPO

DCOM

• Right-click WMI Access (which is the GPO we just created), select Edit
• Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options
• Select Properties at: DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
• Check the Define this policy setting
• Select Edit Security …
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Under Permissions: Tick Allow on both Local Access and Remote Access
• Click OK
• Click OK
• Select Properties under: DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
• Check Define this policy setting
• Select Edit Security …
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Under Permissions: Tick Allow at Local Launch, Remote Launch, Local Activation and Remote Activation
• Click OK
• Click OK

Firewall

• Right-click WMI Access (the GPO we just created), select Edit
• Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security
• In the right pane, expand Windows Firewall with Advanced Security until Inbound Rules visible. Right-click on it
• Choose New Rule …
• Select Predefined and Windows Management Instrumentation (WMI) in the list
• Click Next
• Tick all the Windows Management Instrumentation-rules in the list (usually 3 pieces)
• Click Next
• Select Allow The Connection
• Click Finish

3 – Rights for WMI namespace

These settings can not be done with a regular GPO. For a user who is not Admin this step is critical and must be done exactly as instructed below. If not properly done, login attempts via WMI results in Access Denied.

• Write wmimgmt.msc in command prompt
• Right-click WMI Control, and select Properties
• Select the Security tab
• Select Root of the tree and click on Security
• Click Add …
• Under Enter the object names to select: Enter ISLwmiuser and click Check Names. The user is now filled in automatically
• Click OK
• Select wmiuser (wmiuser@ISL.local)
• Select Allow for Execute Methods, Enable Account, Remote Enable and Read Security under Permissions for wmiuser
• Mark wmiuser and click Advanced
• Under the Permission tab: Select wmiuser
• Click Edit
• Under Applies To-list: Choose This namespace and all subnamespaces. It is very important that the rights are applied recursively down the entire tree!
• Click OK
• Click OK
• Click OK
• Click OK

Политика установки обновлений WSUS для рабочих станций

Мы предполагаем, что обновления на клиентские рабочие станции, в отличии от серверной политики, будут устанавливаться автоматически ночью сразу после получения обновлений. Компьютеры после установки обновлений должны перезагружаться автоматически (предупреждая пользователя за 5 минут).

В данной GPO (WorkstationWSUSPolicy) мы указываем:

• Allow Automatic Updates immediate installation (Разрешить немедленную установку автоматических обновлений): Disabled — запрет на немедленную установку обновлений при их получении;
• Allow non-administrators to receive update notifications (Разрешить пользователям, не являющимся администраторами, получать уведомления об обновлениях): Enabled — отображать не-администраторам предупреждение о появлении новых обновлений и разрешить их ручную установку;
• Configure Automatic Updates: Enabled.   Configure automatic updating: 4 — Auto download and schedule the install. Scheduled install day: 0 — Every day. Scheduled install time: 05:00 – при получении новых обновлений клиент скачивает в локлаьный кэш и планирует их автоматическую установку на 5:00 утра;
• Target group name for this computer: Workstations – в консоли WSUS отнести клиента к группе Workstations;
• No auto-restart with logged on users for scheduled automatic updates installations: Disabled — система автоматически перезагрузится через 5 минут после окончания установки обновлений;
• Specify Intranet Microsoft update service location: Enable.  Set the intranet update service for detecting updates: , Set the intranet statistics server: –адрес корпоративного WSUS сервера.

В Windows 10 1607 и выше, несмотря на то, что вы указали им получать обновления с внутреннего WSUS, все еще могут пытаться обращаться к серверам Windows Update в интернете. Эта «фича» называется Dual Scan. Для отключения получения обновлений из интернета нужно дополнительно включать политику Do not allow update deferral policies to cause scans against Windows Update (ссылка).

Совет. Чтобы улучшить «уровень пропатченности» компьютеров в организации, в обоих политиках можно настроить принудительный запуск службы обновлений (wuauserv) на клиентах. Для этого в разделе Computer Configuration -> Policies-> Windows Setings -> Security Settings -> System Services найдите службу Windows Update и задайте для нее автоматический запуск (Automatic).

Создание правил политики

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

• Зона
• Путь
• Сертификат
• Хеш

Создание нового правила

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

Дополнительная информация

Указанное значение должно быть достаточно длинным, чтобы обеспечить подключение. В течение периода ожидания Windows будет проверять состояние подключения каждые две секунды и будет продолжать запуск системы, как только подключение будет подтверждено. Поэтому рекомендуется перебиваясь на высокой стороне. Если система отключена законно (например, отключенный сетевой кабель, off-line server и так далее), Windows заглохнет на весь период ожидания.

Она также может быть определена с помощью групповой политики:

Расположение политики: > политики > шаблоны администратора > System > Group Policy Setting Name: Клавиша времени ожидания ожидания обработки политики запуска: HKLM\Software\Policies\Microsoft\Windows\System!GpNetworkStartTimeoutPolicyValue

Если вы определите параметр групповой политики, он переопределит параметр вручную. Если параметр ручной и групповой политики не определен, значение выбирается из следующего расположения реестра:

Так как не определен период ожидания, система использует собственный алгоритм для вычисления и прибытия в период среднего времени ожидания. Это значение хранится в расположении реестра выше. Она может отличаться от системы к системе и зависит от различных факторов, например предыдущих попыток входа.

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

Для чего используются WMI фильтры GPO?

Как правило, технология фильтрации групповой политики с помощью WMI (инструментарий управления Windows) используется в ситуациях, когда объекты домена (пользователи или компьютеры) находятся в плоской структуре AD, а не в выделенной организационной единице, или если политики должны применяться, в зависимости от версия операционной системы, ее сетевые настройки, установленное программное обеспечение или любая другая политика, которую можно выбрать с помощью WMI. Когда такая групповая политика обрабатывается клиентом, Windows проверяет ее статус по запросу WMI, указанному в языке запросов WMI (WQL), и, если условия фильтрации соблюдены, объект групповой политики будет применен к компьютеру.

Фильтры групповой политики WMI впервые появились в Windows XP и доступны до последних версий Windows (Windows Server 2019, 2016, Windows 10, 8.1).

GPO и WMI фильтрация

WMI фильтрация в GPO позволяет создавать набор критериев посредством WMI, указывать эти критерии объекту групповой политки и данная политика будет применяться только на те объекты, которые будут соответствовать установленным критериям. WMI работает на всех версиях Windows начиная с Windows 2000 и Windows XP, версионность ОС указана ниже:

Windows Server 2012 и Windows 8 – 6.2 Windows Server 2008 R2 и Windows 7 – 6.1 Windows Server 2008 и Windows Vista – 6.0 Windows Server 2003 – 5.2 Windows XP – 5.1 Windows 2000 – 5.0

Так же для каждой ОС есть свой тип:

ProductType=1 — Клиент ProductType=2 — Контроллер домена ProductType=3 — Сервер

Допустим есть необходимость применить GPO только на Windows 8, то будет использоваться фильтр:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «6.2%» AND ProductType = «1»

или сервера Windows Server 2012:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE «6.2%» AND ( ProductType = «2» OR ProductType = «3» )

Примеры WMI фильтров

только Windows 7 x64:

select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»1″ AND OSArchitecture = «64-bit»

только Windows 7 x32:

select * from Win32_OperatingSystem WHERE Version like «6.1%» AND ProductType=»1″ AND NOT OSArchitecture = «64-bit»

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’32’

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth =’64’

на все с ОЗУ больше или равно 1Гб:

SELECT * FROM WIN32_ComputerSystem WHERE TotalPhysicalMemory >= 1073741824

или установлен IE 8 и выше:

SELECT path,filename,extension,version FROM CIM_DataFile WHERE path=»\\Program Files\\Internet Explorer\\» AND filename=»iexplore» AND extension=»exe» AND version>=»8.0″

Применение на практике WMI фильтрации

Для управления GPO необходимо остастка Group Policy Management (GPMC), в Windows 2008 и выше идет поумолчанию, для версий ниже можно оснастку можно загрузить здесь.

Создание WMI фильтра

Здесь все просто, имея к примеру набор фильтров указанных выше, можно содать свой набор и привязать тот или иной фильтр к GPO, создается фильтр в GPMC в контейнере — WMI Filtering — ПКМ — New..

В открывшемся окне необходимо указать имя фильтра и добавить само условие фильтрации нажатием кнопки ADD:

После создания фильтра, привязываем его к политике, выбрав политику и на вкладке Scope в разделе WMI Filtering выбираем фильтр:

Послесловие

На самом деле WMI довольно широкий инструмент, посредством которого можно реализовывать довольно много задач, как например Удаленное удаление программ при помощи WMI.

Источник

ОБЪЯСНЕНИЕ 1

Режим обработки замыкания групповой политики (Loopback Policy Processing)
Если управлять пользовательскими профилями через групповые политики, то можно заметить, что некоторые настройки, например, перенаправление папок, располагаются в разделе User configuration (Конфигурация пользователя) политики.
А это значит, что если пользовательская учетная запись находится в организационном подразделении (Organization Unit, OU), на которое распространяется действие такой политики, то применяться эти настройки будут при входе пользователя в систему независимо от того, локальный это компьютер или сервер RDS. Такое поведение может быть нежелательным, вполне разумно иметь одни пользовательские настройки для сервера, другие — для локального компьютера.
Но если поместить политику с настроенными разделами User Configuration в раздел OU с серверами, то она не будет обрабатываться, так как учетные записи пользователей не находятся в этом OU.
Чтобы это произошло, существует специальная политика Loopback Policy Processing (Режим обработки замыкания пользовательской групповой политики), располагающаяся в разделе Computer Configuration (Конфигурация компьютера) -» Policies (Политики) -> Administrative Templates (Административные шаблоны) -> System (Система) -> Group Policy (Групповая политика).
У нее два режима работы — Replace (Замена) и Merge (Слияние). В первом случае происходит замещение пользовательских политик из OU пользователя, во втором — объединение с ними.

Например, на рис. 5 изображен домен с двумя организационными подразделениями — OU1 и OU2.
В первом находятся объекты учетных записей пользователей и их локальные компьютеры, во втором — объекты серверов RDS.
Если пользователь осуществляет вход в систему на локальном компьютере, то он оказывается под действием доменной групповой политики (Default domain policy), затем политики GP1 локального компьютера (которая была применена при его включении) и политики GP2 пользователя (примененной при входе в систему).
Если пользователь осуществляет вход на сервер RDS, то будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2.
Если же включить Loopback Policy Processing, то при входе на сервер RDS будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2+GP4 (в режиме Merge) или только GP4 (в режиме Replace).
При возникновении любых конфликтов настроек между политиками OU пользователя и OU сервера в режиме Merge политика в OU сервера будет иметь более высокий приоритет.

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

( взято тут: http://www.xnets.ru/plugins/content/content.php?content.240.4  )

Отслеживайте вход в аккаунт

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

В редакторе групповой политики перейдите в указанное ниже место и дважды щелкните Аудит событий входа в систему.

Конфигурация компьютера → Конфигурация Windows → Параметры безопасности → Локальные политики → Политика аудита

Здесь установите флажки рядом с вариантами Успех и Отказ. Когда вы нажмете ОК, Windows начнет регистрировать входы в систему на ПК.

Для просмотра этих журналов вам потребуется доступ к другому полезному инструменту Windows – Windows Event Viewer. Снова откройте диалоговое окно «Выполнить» и введите в нём eventvwr, чтобы открыть средство просмотра событий Windows.

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

Успешные события входа в систему имеют идентификатор события: 4624, а неудачные – идентификатор события: 4625. Просто найдите эти идентификаторы событий, чтобы найти логины и увидеть точную дату и время входа.

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

Примеры запросов для WMI фильтров

Примеры WMI фильтрации по версиям ОС Windows.

Таблица версий ОС Windows:

Windows Server 2016 и Windows 10 - 10.0%
Windows Server 2012 R2 и Windows 8.1 — 6.3%
Windows Server 2012 и Windows 8 — 6.2%
Windows Server 2008 R2 и Windows 7 — 6.1%
Windows Server 2008 и Windows Vista — 6.0%

Типы ОС:

ProductType=1 - Клиент
ProductType=2 - Контроллер домена
ProductType=3 - Сервер

Применить GPO только на Windows 8:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.2%" AND ProductType = "1"

Применить GPO только на Windows Server 2012 R2:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.3%" AND ( ProductType = "2" OR ProductType = "3" )

Применить GPO только на Windows 7 x64:

select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND OSArchitecture = "64-bit"

Применить GPO только на Windows 7 x32:

select * from Win32_OperatingSystem WHERE Version like "6.1%" AND ProductType="1" AND NOT OSArchitecture = "64-bit"

Применить GPO только на x32 ОС:

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='32'

Применить GPO только на х64 ОС:

SELECT AddressWidth FROM Win32_Processor WHERE AddressWidth ='64'

Вот так можно фильтровать применимость GPO на ОС с помощью запросов. С помощью Powershell можно все выше представленные данные посмотреть. Чтобы узнать версию и тип продукта ОС выполним команду:

Get-WMIObject Win32_OperatingSystem | Select Version,ProductType

Чтобы посмотреть все свойства класса Win32_OperatingSystem выполним команду:

Get-WMIObject Win32_OperatingSystem | Select *

Примеры WMI фильтрации по привязке к IP подсети.

Применить GPO только на IP подсеть 10.7.7.*:

Select * FROM Win32_IP4RouteTable WHERE (Mask='255.255.255.255' AND Destination Like '10.7.7.%')

Применить GPO на нексколько IP подсетей 10.7.7.* и 10.7.8.*:

Select * FROM Win32_IP4RouteTable WHERE (Mask='255.255.255.255' AND (Destination Like '10.7.7.%' AND Destination Like '10.7.8.%'))

Вот так можно применять GPO строго на указанную IP подсеть. С помощью Powershell можно посмотреть  данные по классу Win32_IP4RouteTable, выполнив команду:

Get-WMIObject WIn32_IP4RouteTable | Select Destination, Mask

По мере необходимости буду дополнять статью, полезными запросами для WMI фильтров.

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

ПОНРАВИЛАСЬ ИЛИ ОКАЗАЛАСЬ ПОЛЕЗНОЙ СТАТЬЯ, ПОБЛАГОДАРИ АВТОРА

Verification

Changes will be reflected to clients during periodic policy refresh or manually using command gpupdate /force. When WMI filter applied, the policy will no longer takes effect on client computers that are not matched with the defined condition. To verify, run command gpresult /R /SCOPE COMPUTER on cmd.

As can be seen in screenshot below, in Windows 7 the “W10 Policy” has been taken out from applied policy objects and is now being denied. We can also see the WMI filter name that blocks this policy from being applied, which is “Global 10.x”.

On the other hand, in Windows 10 the policy can still be found under applied policy objects as shown in screenshot below.

This result showed that the defined condition on WMI filter works as expected. There are lots of other attributes that can be used as the condition, such as OS settings, registry, storage, event log, etc, depending on the requirements. And that’s how applying WMI filter to Group Policy can help administrator to gain better control on policy scope.

The following two tabs change content below.

• Bio
• Latest Posts