Delegate WMI Access to Domain Controllers

[Server Man]

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.

Source: Securing Active Directory Administrative Groups and Accounts

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).

Set-WMINamespaceSecurity

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.

1. Create a group, such as AD – Remote WMI Access
2. Add appropriate users to this group
3. Add the AD – Remote WMI Access group to BuiltinDistributed COM Users
4. Download Script
   • TechNet Set WMI Namespace Security on a system
5. Create a new Group Policy object, such as “Domain Controller – Delegate WMI Access”
6. 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:scriptsSet-WMINamespaceSecurity.ps1
   • 
   • Click <OK> to close.
7. 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 AuthoritySystem.
   • 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:
     1. Program/script: PowerShell.exe
     2. Add Arguments: -file C:ScriptsSet-WMINamespaceSecurity.ps1 -namespace root/cimv2 -account “surfaceAD – Remote WMI Access” -operation Add -permissions Enable
   • 
   • On the Actions tab, create a second action as follows:
     1. Program/script: PowerShell.exe
     2. Add Arguments: -file C:ScriptsSet-WMINamespaceSecurity.ps1 -namespace root/cimv2 -account “surfaceAD – Remote WMI Access” -operation Add -permissions RemoteAccess
     3. 
   • On the Action tab, create a third and final action as follows:
     1. Program/Script: PowerShell.exe
     2. 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 <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.

Until next time!
-Graeme Bray

Pertinent Links:

Distributed COM Users: Default local groups

Continue reading...