Forum Discussion

Mike_Moniz's avatar
Mike_Moniz
Icon for Professor rankProfessor
4 years ago

How WMI, DCOM, RPC and UAC effect access to remote Window Systems for Monitoring

...or how to get LogicMonitor pass WMI/DCOM Access Denied Messages

I've been dealing with monitoring some systems that are either not joined to the domain or where the LM service account is not allowed to be a domain admin. There are guides from LM and more general online posts for various workarounds but not always describing what exactly these changes are doing and which parts are really needed for your needs. So I put together this post on my notes. Please review the comments on this post for any corrections and comments. Note that I don't work for LogicMonitor so this is based on my understanding, research and testing. Please let me know if you see any mistakes or misunderstand anything. -Mike

How LogicMonitor monitors basic Windows systems

LogicMonitor uses WMI and WinRM ("Get-CIM*") requests to monitor Window Servers, with WMI being the most used. WMI requests over the network use DCOM technology which communicates over RPC on the network. To make WMI queries over the network, you need to have permissions within DCOM/RPC and WMI. Access to DCOM is controlled by dcomcnfg.exe and WMI access is controlled by Computer Management > Services and Applications > WMI Control. WinRM access is simply controlled by being in the Remote Management Users group.

User Account Control (UAC)

To complicate things further, UAC (User Account Control) is applied on both local and remote network access. UAC is designed to de-elevate any administrator user so they get normal user permissions. You can effectively think of it as removes your user from the Administrators group on-the-fly for your request.

When working locally with UAC on, you can regain full administrator privileges by using "Run as Administrator" or disable UAC notifications in the control panel. Disabling UAC notifications will have the shell auto-elevate for you. Setting the UAC slider in Control Panel to "never notify" will not disable UAC but just remove the notification and auto-escalate locally. The slider does NOT affect remote UAC use and it will still apply in full force.

The effect of UAC on remote connections will also depend on if the remote server is joined to a domain or not. When a server is joined to a domain, any local administrator (which includes domain admins) making remote calls will run with full administrators privileges. Basically, UAC will not affect remote network access on domains.

When a remote server is not joined to a domain, just a workgroup, then UAC takes full effect on remote access for all local administrators except the built-in "Administrator" account. So if you use a dedicated monitoring account (as suggested) that is a member of the local Administrators group, UAC will effectively remove administrators group access from the monitoring account remote access. There isn't a way to "Run as Administrator" with WMI remote requests.

UAC's Effect on DCOM and WMI

By Default, recent Windows versions provide the following permissions (simplified for our purposes):

* Remote DCOM: Administrators, Performance Log Users, Distributed COM Users

* Remote WMI: Administrators

So by default Windows only allows those with administrators privileges to access WMI remotely. If you are a normal user you will be blocked by DCOM before you get to WMI. But if you were part of the Performance Log Users or Distributed Com Users, you would get past DCOM.

When remote UAC is in effect, UAC will remove your Administrators permissions as mentioned above. This causes you to be blocked by DCOM anyway unless you are also part of those two groups. Doesn't matter if you are part of the local Administrators group.

There are two ways you can allow access:

1) Fully disable UAC by setting the EnableLUA registry value to 0 and reboot. This will fully disable UAC in Windows. This would stop UAC from removing administrator privileges, allowing access to anything that allows access to administrators. If you want to have full administrator access for monitoring I would suggest this option.

2) First modify WMI Control to allow your actual account to remotely query WMI. Then either add the account to the Performance Log Users or Distributed COM Users group, or modify DCOM permissions directly to allow your actual account to get remote access. Just assume you are not joined to the local Administrators group in this case. You will have more limited access to monitoring including LM DataSource "Files Services" and Windows Services monitoring not working (without the workaround talked about later).

DCOM/RPC Ports

Standard remote WMI queries use RPC to connect and RPC uses a mess of ports. First, the Collector would connect to the remote system over TCP 135. The remote system would then pick a high port and ask the Collector to use this new high port for future communications. The high port depends on the OS but current Windows uses ports 49152 thru 65535. If there is a firewall/router between the Collector the remote system and it's not RPC/WMI-aware (being statefull is not enough), you need to open all of those ports between the two. There is a way to modify Windows to limit the IP range but it would be global on that server.

WinRM/PSRemote Access

A few LogicMonitor DataSources use WinRM (PSRemote) instead of WMI, like the DHCP Server DataSources. This uses the WS-Man (Web Services for Management) protocol on TCP 5985 and 5986 instead of RPC. WinRM has its own set of permissions needed.

So to include WinRM in our previous simplified default permissions list:

* Remote WinRM/PSRemote: Administrators, Remote Management Users

* Remote DCOM: Administrators, Performance Log Users, Distributed COM Users

* Remote WMI: Administrators

By default Windows only allows those with administrators privileges to access WinRM remotely. If you are a normal user (or UAC makes you into a regular user) you will be blocked by WinRM first before you get to DCOM or WMI. From what I can tell, using WinRM still requires access to WMI and DCOM. I have not experimented with this much.

To allow access to WinRM you would add the user to the "Remote Management Users" group. As far as I know, there isn't a management console to control WinRM permissions and the user group is the official method to provide access without having Administrators access.

Windows Services Access

Monitoring Windows Services as non-admin (or with UAC removing admin) is especially tricky.

By Default, recent Windows versions provide the following permissions to look at the Windows Services Controller (simplified for our purposes):

* Authenticated users: Query Service Config

* Interactive: Service Config + Service Status + Start Services + Read SACL

* Service: Service Config + Service Status + Start Services + Read SACL

* System: Service Config + Service Status + Start Services + Stop Services + Read SACL

* Administrators: All Access

* All Application Packages: Query Service Config

You can add the following ACL to the existing SDDL string to give a LogicMonitor Service Account read access to most services:

'(A;;CCLCRPRC;;;SID_HERE)

A = Access Allowed

CCLCRPRC = CC: Query Service Config

                    = LC: Query Service Status

                    = RP: Start Services

                    = RC: Read security ACLs

SID_HERE = Replace with the SID of the LogicMonitor Service Account

I found that RP and RC permissions are required for the WMI request to work

Each service can also have its own overriding ACL, so providing access to Windows Services Controller might not be enough. I avoid this workaround if I can. I kinda consider it a limitation of non-admin access and I'm hesitant about playing with per-service ACLs personally.

Possible Fixes or Workaround Steps

How to fully disable UAC:

  1. 1. Run the following single command in PowerShell (run as administrator) then reboot the server
New-ItemProperty -Path HKLM:Software\Microsoft\Windows\CurrentVersion\policies\system -Name EnableLUA -PropertyType DWord -Value 0 -Force

How to Modify WMI:

  1. 1. Computer Management > Services and Applications > WMI Control
  2. 2. Right-click and choose properties > Security tab
  3. 3. Choose Root then Security button
  4. 4. Add the local LogicMonitor service account and check the boxes for Allow Execute Methods and Remote Enable.
  5. 5. Click Advanced button > choose the service account > Edit
  6. 6. Change Applied to into "This namespace and subnamespaces".
  7. 7. Click OK on all the windows.
  8. 8. Restart the Windows Management Instrumentation service (and its dependencies).

How to gain DCOM Access (suggested method):

  1. 1. Add local LogicMonitor service account to the "Performance Log Users" group.

Note that adding the user to "Performance Monitor Users" will not provide DCOM access by default.

How to gain WinRM Access:

  1. 1. Add local LogicMonitor service account to the "Remote Management Users" group.
  • SeanHill's avatar
    SeanHill
    4 years ago
    On 10/5/2021 at 11:49 PM, Mike Moniz said:

    Windows Services Access

    Hi Mike I have a couple of queries, are you able to elaborate on the process we need to apply to "Windows Services Access" and have you applied these steps yourself successfully, I have tried and unable to discover the "Standard Services"

    Please advise.

  • Barb's avatar
    Barb
    Icon for Advisor rankAdvisor
    3 years ago

    Hi I have also been having issues in some environments getting windows services and did some work with Microsoft on this. Basically if you set the below you will get most services.

    Add (A;;CCLCRPRC;;;AU) on scmanager just infront of 'D:'

    Add (A;;CCLCSWLOCRRC;;;AU) on individual services just infront of 'D:'

    If you get access denied on any of them it is because the admin account doesn't have right to modify permission for this service. Its a bit of a process to use an account that does have access, but i have the instructions in an email from MS if interested.

  • Mike_Moniz's avatar
    Mike_Moniz
    Icon for Professor rankProfessor
    3 years ago
    9 hours ago, Barb said:

    If you get access denied on any of them it is because the admin account doesn't have right to modify permission for this service. Its a bit of a process to use an account that does have access, but i have the instructions in an email from MS if interested.

    If you don't mind, please do. It would be useful for any others that might need to do that. (https://xkcd.com/979/)

  • Barb's avatar
    Barb
    Icon for Advisor rankAdvisor
    3 years ago

    For the access denied error, I think it’s because the admin account doesn’t have right to modify permission for this service. Let’s take WdNisSvc as example. Except (A;;CCLCSWLOCRRC;;;AU) we added, original permission of this service on your machine should be like below:

    D:(A;;CCLCSWRPLOCRRC;;;BU)(A;;CCLCSWRPLOCRRC;;;SY)(A;;CCLCSWRPLOCRRC;;;BA)(A;;CCLCSWRPLOCRRC;;;IU)(A;;CCLCSWRPLOCRRC;;;SU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

    As we can see, neither built-in administrators (BA) nor local system account (SY) has privilege to modify service permissions, so we’ll get access denied error when trying to change its permission even in elevated cmd. I also tested with system account in lab and got the same error.

    I suppose S-1-5-80-1913148863-3492339771-4165695881-2087618961-4109116736 should have permission, but I haven’t managed to launch cmd using this account successfully in lab. Based on my test, seems TrustedInstaller also has permission to make this change. So if we do need change permission for this service, we can try launch cmd as TrustedInstller to run the “sc sdset” command, which we may need resort to some third party apps. Below I’ll share one of the possible approaches that I tested in my lab:

    1.       Open PowerShell as administrator and run below commands to import Ntprocess module:

    PackageManagement\Get-PackageProvider -Name NuGet -Force

    Install-Module -Name NtObjectManager -Confirm:$False -Force

    Please note: I got below error when trying to import the module, and work around it by turn off Real-time protection from Windows Security > Virus & threat protection settings.

    6f2f6639742e862964e7c5d91293166b.png

    2.       Then run below commands to start PowerShell with TrustedInstller privilege:

    Start-Service TrustedInstaller

    $p = Get-NtProcess -Name TrustedInstaller.exe

    New-Win32Process powershell.exe -CreationFlags NewConsole -ParentProcess $p

    1. In the new PowerShell window opened, type cmd to switch to cmd, then run the command and see how it works.

     

    In short, different services may have different permission settings. In order to change permission for a specific service, we need run command with an account that has permission to make this change.

  • Barb's avatar
    Barb
    Icon for Advisor rankAdvisor
    3 years ago

    I also asked the question about adding duplicate permissions on the AU and response is below;

     

    Regarding duplicate permission mentioned earlier, based on the information I got, if several ACEs apply to one user/group, the access rights granted by each ACE accumulate. For example, if one ACE grants read access to Authenticated Users group, another ACE grants write permission to same group, then member of this group can have both read and write access. Adding (A;;CCLCSWLOCRRC;;;AU) should enable AU group to have both original and newly added permissions (duplicate or not). That is why I say we just add additional permissions and we suppose it won’t cause issue.

  • Mike_Moniz's avatar
    Mike_Moniz
    Icon for Professor rankProfessor
    4 years ago

    I have not needed to apply custom ACLs to services personally, so I have only done it a little bit with a test setup. For common situations like Domain Controllers where you can't just create local users, I've offered to install the Collector directly on the domain controller using Local System and only have it monitor itself.

    In my testing for this post I used the built-in SC.exe command via CLI but there are several ways to do, like how described at https://www.winhelponline.com/blog/view-edit-service-permissions-windows/. Reviewing my notes here are some websites that was useful for understanding the SDDL syntax but you might want to use one of the GUI tools unless you want to script/automate it:

    If you do figure out a good process for customizing SACLs for monitoring, I would be interested in it! Thanks.

  • Kris_Jankiewicz's avatar
    Kris_Jankiewicz
    Icon for Neophyte rankNeophyte
    3 years ago

    I was banging my head against the wall for several hours trying to get a Windows Machine to be monitored via WMI without local admin permissions. I spent hours trying to get it to work and even though classes would be enumerated the data returned would be null. I almost gave up but then added a vanilla domain user account to the built-in Local Windows group "Performance Monitor Users", not "Performance Log Users" and all worked perfectly. No need to play around with DCOM or WMI permissions at all. It just worked.