Windows Server Monitoring and Principle of Least Privilege

Last updated on 22 August, 2024

The purpose of this configuration is to run remote WMI functionality without administrator privileges. The query user must have adequate privileges for the device. Query user can be a domain user or a local user. The domain user can configure the setup centrally. However, the local user must configure the setup on each device separately. This configuration is done as follows:

  1. Adding user to groups
  2. Granting WMI Namespace security rights
  3. Granting Windows Service permissions

Adding User to Groups

After the user is created, you must add the user to the following groups:

  • Distributed COM Users – It provides permission to access and interact with the Distributed Component Object Model (DCOM) objects on a Windows system. It allows you to run applications that rely on DCOM for inter-process communication and access distributed services across a network.
  • Performance Monitoring Users – It provides permission to monitor and collect performance data on a Windows system. It allows you to run performance monitoring tools and gather system metrics.
  • Event Log Readers – It provides permission to read event logs on a Windows system. It allows you to monitor and analyse system events. It allows you to view and extract information from event logs, troubleshoot issues, and analyse systems.
  • Remote Management Users – It provides permission to remotely manage tasks on a Windows system. It allows you to run commands or scripts remotely and manage configurations. It allows you to utilise services such as, Windows Remote Management (WinRM) and PowerShell remoting.

Note: Adding user to the Remote Management Users group is required only for WinRM. Add user to this group only if the user intends to toggle between DCOM and WinRM.

Adding User to Groups in a Domain based Setup

  1. From an elevated PowerShell console or cmd.exe, type the command dsa to launch Active Directory Users and Computers. Alternatively, open dsa.msc from the Run window (Win+R).
  2. Under your domain, right-click Users and select New > User. A New Object – User dialog box is displayed.
  3. Enter a username in the User logon name field and select the Next button.
  4. Set the password and select OK.
  5. Double-click the newly created entry of this user. The <username> Properties dialog box is displayed.
  6. Select the Member Of tab and select the Add button. The Select Groups dialog box is displayed.
  7. Enter the names of the four groups in the Enter the object names to select (examples): field and then select OK.

    Under the Member Of tab you can observe that the user is added to the four groups.
  8. Select Apply and then select OK.

Adding User to Groups in a Non-domain or Local Setup

  1. From an elevated PowerShell console or cmd.exe, type the command lusrmgr to launch Local Users and Groups. Alternatively, you can open lusrmgr.msc from the Run window (Win+R).
  2. Right-click the User folder and select New User. A New User dialog box is displayed.
  3. Enter a username and password for the new user and select the Create button.
  4. Double-click the newly created entry of this user. The <username> Properties dialog box is displayed.
  5. Select the Member Of tab and select the Add button. The Select Groups dialog box is displayed.
  6. Enter names of the four groups in the Enter the object names to select (examples): field and then select OK.

    Under the Member Of tab you can observe that the user is added to the four groups.
  7. Select Apply and then select OK.

Granting WMI Namespace Security Rights

  1. From an elevated PowerShell console or cmd.exe, issue the command wmimgmt to launch the WMI Management Console. Alternatively, you can open wmimgmt.msc from the Run window (Win+R).
  2. Right-click WMI Control and select Properties.

    The WMI Control Properties dialog box is displayed.
  3. Under the Security tab, select the Root folder.
  4. Select the Security button. The Security for Root dialog box is displayed.
  5. Select the Add button.

    The Select Users, Computers, Service Accounts, or Groups dialog box is displayed.
  6. Enter the username in the Enter the object names to select (examples): field and then select OK.

    Under the Security tab you can observe that the user is added to the username list.
  7. Select the user and in the permissions for the selected user, under Allow, select the Enable AccountRemote Enable, and Read Security checkboxes.
  8. Select Apply and then select OK.

When we consider the principles of Least Privilege, the user gets only the following three permissions to the WMI Namespace. These permissions control access to the WMI namespaces, their associated classes, and instances.

  • Enable Account–Controls the ability to enable and disable the WMI provider ensuring that only the authorised entities can control its state.
  • Remote Enable–Governs whether remote systems can access and query the WMI provider on the local computer, thus preventing unauthorised remote access.
  • Read Security–Allows accounts to view security configurations of the WMI namespace, helps to audit, and ensures efficient management of security settings.

Granting Windows Service Permissions – SDDL Changes

To change the permissions of Service Control Manager (SCManager) and the Win32_services, follow these steps:

  1. To retrieve the Service ID (SID) of the LogicMonitor user, run the following command in PowerShell.
    [wmi] "win32_useraccount.domain='<domainName>',name='<userName>'"
  2. To get the SDDL of the SCManager, run the following command in PowerShell.
    sc.exe sdshow SCMANAGER
    Sample of the retrieved SDDL
    D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
  3. Create a string to append to the parent SDDL. You must replace it with the actual SID of the LogicMonitor user.
    Syntax : (A;;LCRPRCLOCC;;;$UserSID)
    Example: (A;;LCRPRCLOCC;;;S-1-5-21-265800110-2195697097-2714329818-1112)
  4. Append the string next to the (A;;CCLCRPRC;;;IU) string.
    D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;LCRPRCLOCC;;;S-1-5-21-265800110-2195697097-2714329818-1112)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
  5. Set the new SDDL as the security descriptor of the SCManager.
    sc sdset scmanager “D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;LCRPRCLOCC;;;S-1-5-21-265800110-2195697097-2714329818-1112)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"

Example

To change the Win32_services to another service such as AppMgmt service, you must perform all the steps given for changing permissions of the SCManager. You must ensure to replace SCManager with the <serviceName>of the Windows serviceFor example, the following command displays the security descriptor of the AppMgmt service.

sc.exe sdshow AppMgmt

You can either create your own ACLs or copy the segment from the SDDL that ends with Interactive Users (IU) that is, (A;;CCLCRPRC;;;IU). For more information on creating ACLs, see ACE Strings.

Automating Non-admin Configuration

Instead of manually performing the configuration steps, you can run a PowerShell script Windows_NonAdmin_Config.ps1 to automate the non-admin configuration process. This script is available from EA Collector 35.400 onwards. 

Note:

  • The script is bundled with the Windows collector installer.
  • After installing the collector, go to \LogicMonitor\Agent\bin.
  • The path has the Windows_NonAdmin_Config.ps1 script. You must copy and paste the script to individual domain devices.
  • The Windows_NonAdmin_Config.ps1 script works for both the domain and non-domain setups.
  • You can can check the detailed logs at %appdata%\LogicMonitor\Logs location.

To automate the non-admin configuration process, do the following:

  1. Open a PowerShell session as administrator, and change the path to the script location \LogicMonitor\Agent\bin.
  2. For the domain based setup, to run the script, pass the UserName parameter in the DomainName\UserName format.
.\Windows_NonAdmin_Config -add -UserName logicmonitor\DomainUser101

For the non-domain setup, use the following format.

.\Windows_NonAdmin_Config -add -UserName DomainUser101

Rolling back to Administrator User

To roll back to admin configuration, follow these steps:

  1. Open a PowerShell session as non-admin, and go to the script location \LogicMonitor\Agent\bin.
  2. For the domain based setup, run the following script:
.\Windows_NonAdmin_Config -remove -UserName logicmonitor\QueryUser101

For the non-domain based setup, run the following script:

.\Windows_NonAdmin_Config -remove -UserName QueryUser101

Migrating Admin to Non-admin User for Collector Service Account

The step elaborated in this support article convert the Windows user to non-admin and give it necessary rights to query data.

During collector installation if you have used Collector Service Account credentials then the collector is running under the admin user. You can convert the admin user to non-admin user using the Windows_NonAdmin_Config.ps1 script. For example, if your collector username is LogicMonitor, use the following command to convert it to non-admin. You can add the domain name if it is a domain based setup.

.\Windows_NonAdmin_Config -add -UserName LogicMonitor

Automating Script Execution through GPO

To automate script execution through GPO, you must create a GPO policy and add tasks to the GPO policy. You must then restart the domain machine.

Creating GPO Policy

  1. Navigate to Server Manager > Tools > Group Policy Management.
  2. Right-click the domain you want to use and select Create a GPO in this domain, and Link it here…
  3. Enter a name for the new GPO policy and then select OK. Note that the Source Starter GPO will remain (none).
  4. Right-click the newly created GPO policy and select Edit to add tasks.

Adding Tasks to GPO Policy

  1. In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Scripts (Startup / Shutdown) and select Startup.

    A Startup Properties dialogue box is displayed.
  2. Under the Scripts tab, select Add.

    An Add a Script dialogue is displayed.
  3. On the Add a Script dialogue, enter the following details.
    1. In the Script Name field, browse for the PowerShell.exe path. Typically, the path is C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe
      Note: If the path differs, browse for the specific folder where you have placed the Powershell.exe.
    2. In the Script Parameters field, enter the following parameters for the script.
      -Noninteractive -ExecutionPolicy Bypass -Noprofile -file \\<IP_Address_of_DC>\netlogon\Windows_NonAdmin_Config.ps1 -add -UserName logicmonitor\DomainUser01
  4. Select OK and then select Apply.

Restarting Domain Machine

  1. Open PowerShell terminal and run gpupdate/force.
  2. Once the user policy is successfully updated, restart the domain machines.
In This Article