IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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.
*Note* – The remaining part of this article talks about delegating access to the Root/CIMv2 namespace. Any other classes that you need access to would need to delegated as well. There may be caveats (Win32_Service) that can’t be queried without additional effort. This is not a comprehensive list of classes that work/don’t work, so testing based on your specific use cases should be done.
- 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
- 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 <OK> 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 <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!