Re-blog frοm Source
It is always good to remember that the Administrators group provides full control over the Domain Controllers and is just as critical of a group to keep users out of.
In the Domain Admins group, we all have seen accounts for monitoring, PowerShell queries, etc. Those typically only need WMI access to pull information to monitor/audit. By following the theory of least privilege, it allows you to still give access needed to watch your infrastructure, without potentially compromising access.
Set-WMINamespaceSecurity (thanks to Steve Lee for the script)
This script will automate the addition of delegation of the group (or user) that you want to the Root/Cimv2 WMI Namespace on the remote machine.
You can do this manually by opening wmimgmt.msc and modifying the security on the Root/cimv2 namespace. The script will automatically ensure that inheriting is turned on for all sub-classes in this namespace.
Distributed COM Users
The Distributed COM Users group is a built-in group that allows the start, activation, and use of COM objects. Care should be taken and you should monitor this group to ensure that only users are added when you trust that account.
So here is a Step-by-Step guide.
- Create a group, such as AD – Remote WMI Access
- Add appropriate users to this group
- Add the AD – Remote WMI Access group to Builtin\Distributed COM Users
- Download Script
- Create a new Group Policy object, such as “Domain Controller – Delegate WMI Access”
- Create file via Group Policy Preferences
- Go to Computer Configuration -> Preferences -> Windows Settings
- Click Files
- Right Click and select New File
- Select Source File (Set-WMINamespaceSecurity.ps1) file path
- Select Destination File, such as C:\scripts\Set-WMINamespaceSecurity.ps1
- Click to close.
- Create Scheduled Tasks via Group Policy Preferences
- While the “Domain Controller – Delegate WMI Access” policy is open, navigate to Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks
- Right click and select New -> New Scheduled Task (At least Windows 7)
- Set the name appropriately, such as Set WMI Namespace Security
- Configure the security options task to run as NT Authority\System.
- Configure the task to Run whether user is logged on or not and to Run with highest privileges.
- On the Triggers tab, ensure that Begin the task: is set to At task creation/modification.
- Feel free to customize this task as desired. Our goal was to run this once on every DC, but not more than once.
- On the Actions tab, create a new action as follows:
- Program/script: PowerShell.exe
- Add Arguments: -file C:\Scripts\Set-WMINamespaceSecurity.ps1 -namespace root/cimv2 -account “surface\AD – Remote WMI Access” -operation Add -permissions Enable
- On the Actions tab, create a second action as follows:
- Program/script: PowerShell.exe
- Add Arguments: -file C:\Scripts\Set-WMINamespaceSecurity.ps1 -namespace root/cimv2 -account “surface\AD – Remote WMI Access” -operation Add -permissions RemoteAccess
- On the Action tab, create a third and final action as follows:
- Program/Script: PowerShell.exe
- Add Arguments: -ExecutionPolicy Bypass -command “Restart-Service winmgmt -force”
- The remainder of the scheduled task can be left default or customized for your specific environment.
- Click to close this scheduled task.
Should you want to not restart the WMI Service, do not create the third Action.
The scheduled task must be created this way due to the way that multiple values are being passed to the “Permissions” property. An error will occur with PowerShell when passed as “Enabled,RemoteAccess”.
Wait 5 minutes for group policy to refresh on the Domain Controllers and the script will have been copied, the tasks will run, and WMI security will be updated.
If you try to do a remote shutdown via WMI, you get an error “Privilege not held.” This is due to the fact that you don’t have the “Shut down this system” User Rights Assignment.