First published on TechNet on Apr 30, 2018 Hi everyone! Graeme Bray back with you today with a post around delegating WMI access to Domain Controllers. Continuing the tradition of security themed posts that we've had recently on AskPFEPlat, I thought I'd throw this one together for you.
This post originally came about after several customers asked how to remove users accounts from Domain Admins and the Administrators group in the domain. These accounts are needed to monitor the systems, so we needed to find a way to get them to read the instrumentation of the system with non-elevated privilege.
At this point, most admins understand the danger of having an excessive number of users/service accounts in Domain Admins (and other privileged groups). If not, I recommend reading the Pass-The-Hash guidance.
What most don't understand is that the Administrators group provides full control over the Domain Controllers and is just as critical of a group to keep users out of.
What's the appropriate use case for doing something like this? Typically, in the Domain Admins group, you'll see 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.
Some of the components of what we're doing in the step-by-step (below).
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.
Special thanks to Steve Lee for the Set-WMINamespaceSecurity script.
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.
All this being said, the goal is to limit how WMI can be accessed and limit whom in the target groups have the access to log into a DC. This works via scheduled task and will result in the addition of a set of users having the ability to query WMI without access to log into a Domain Controller.
Without further ado, here is a simplified, step-by-step process for delegating access to WMI.
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
The remainder of the scheduled task can be left default or customized for your specific environment.
Click <OK> 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 .
That's it! By doing each step (you did each, right?), you've delegated access to WMI. These accounts no longer have the ability to log into a DC to reboot the machine, or do other nefarious things.