Category: Group Policy

Fix Remote Group Policy Modelling Delegation

willjessiamLeave a comment

Recently I was trying to delegate Group Policy Modelling in an AD Domain so that we could remotely query RSoP data from a management server with RSAT installed. I had assumed this was as simple as granting a user or group the ‘Generate Resultant Set of Policy (Planning)’ permission from the AD Delegation Wizard.

When I tested granting this to my group, I was not able to model RSoP data using the Group Policy Management Console. So went digging and worked through this in my lab to come to an understanding of the issue.

After some trial and error, I realised the Windows Component Object model (COM) governs remote access to domain controllers which is required for remotely accessing Group Policy Modelling.

By default, the following groups have security limits set to allow:
Everyone: Local Launch, Local Activation
Administrators: Local Launch, Local Activation, Remote Launch, Remote Activation
Performance Log Users: Local Launch, Local Activation, Remote Launch, Remote Activation
Distributed COM Users: Local Launch, Local Activation, Remote Launch, Remote Activation

I tried adding my test user to the builtin ‘Distributed COM Users‘ group and wallah! I was able to use Group Policy Modelling remotely.

Group Description: Members are allowed to launch, activate and use Distributed COM objects on this machine.

Unless a user is a member of one of the above groups with Remote Activation set to ‘allow’, then they will be instantly denied when they try to do Group Policy Modelling remotely.

I have confirmed this by logging into a member server with RSAT installed, as a Domain Admin user, then on a domain controller, unticking ‘allow’ for the Administrators group for Remote Activation on properties of the ‘Component Services\Computers\My Computer’ object on the ‘COM Security’ tab in ‘edit limits’:

In this state, a Domain Admin is unable to invoke Group Policy Modelling remotely. If I re-tick remote activation (default state) then the Domain Admin can perform Group Policy Modelling remotely.

But what happens if you have multiple domain controllers? You don’t want to have to set this individually on every domain controller, and also set it on any new domain controllers that may be added later. A colleague and I were discussing this, and he managed to find a Windows Server 2003 article that is still relevant, and available on the Wayback machine, albeit long gone from the public internet.

https://web.archive.org/web/20140501014941/http:/support.microsoft.com/kb/914047

As you can see, Microsoft call out this exact issue, and also provide a solution for deploying the access to multiple domain controllers. Even better, it makes it straight forward to create your own delegation group and apply it to all domain controllers:

Once the GPO has been set, the setting cannot be controlled from Component Services, so ensure you capture current settings and ensure anything non-default is also added to your policy.

Hopefully this helps someone! Thanks for reading.

Mitigating CVE-2022-30190 via Group Policy Preference Registry Keys

willjessiamLeave a comment

On 31 May 2022, Microsoft disclosed a remote code execution vulnerability in MSDT, the Microsoft Support Diagnostic Tool. This vulnerability, CVE-2022-30190, can be exploited by sending a URL to a vulnerable system. Successful exploitation allows an attacker to install programs, view or change data, or create new accounts in line with the victim’s user permissions. There are a number of proof of concept videos getting around including one that is a bit scary that uses the file previewer in Windows to trigger the vuln. As of 1/6/22 there is no patch from Microsoft.

There are two things you can do to mitigate the vulnerability:

  1. Remove the ability for ms-msdt: URL’s to be executed
  2. Disable troubleshooting tools via group policy

Non-mitigated functionality

First, let’s see what happens before the mitigation:

Launch the troubleshooter

Or run a troubleshooter app from the start menu

The troublershooter tool runs as expected

Remove ms-msdt functionality

To remove ms-msdt URL functionality, we need the URL to not associate with the %SystemRoot%\system32\msdt.exe binary, this is achieved by deleting the ms-msdt URL handler key from the registry.

Here is the key we are talking about

Since this will be patched at some point, we want a way to be able to revert the change so I captured the default keys and added these to their own collection and targeted them at a computer that doesn’t exist (targeting will be removed once we want the original keys restored):

Original reg keys

In table form for easy viewing / copying:

HiveKeyValue NameTypeValue Data
HKEY_CLASSES_ROOTms-msdtnone (default)REG_SZURL:ms-msdt
HKEY_CLASSES_ROOTms-msdtURL ProtocolREG_SZ
HKEY_CLASSES_ROOTms-msdtEditFlagsREG_DWORD00200000 (hex)
HKEY_CLASSES_ROOTms-msdt\shellnone (default)REG_SZ
HKEY_CLASSES_ROOTms-msdt\shell\opennone (default)REG_SZ
HKEY_CLASSES_ROOTms-msdt\shell\open\commandnone (default)REG_EXPAND_SZ“%SystemRoot%\system32\msdt.exe” %1

Targeting ‘enable-ms-msdt’ collection to a non existent computer for quick restore of keys once vuln is patched

I then created a collection with the root ms-msdt key that we will be deleting:

ms-msdt key to be deleted

Disable troubleshooting tools

To disable the troubleshooting tools, the following reg key was also deployed: (see link)

EnableDiagnostics reg key to be deployed

Mitigated functionality

Launch the troubleshooter

The URL no longer has a handler to execute

Or run a troubleshooter app from the start menu

Troubleshooter can’t execute as it has been restricted by GPO

Reverting the changes

To revert the changes, all we have to do now is remove the targeting from the enable-ms-msdt collection, delete the collection that is deleting the ms-msdt key and set the EnableDiagnostics reg key to binary 1 which enables users to run troubleshooters again. In my experience the troubleshooters are pretty useless anyway so maybe I’ll leave this disabled.

Thanks for reading.