By default, the UpGuard Windows service runs using the Local System user. The Local System user on the server hosting the UpGuard service will not have any permissions on remote systems, so creating an UpGuard service user is required.
The sections below outline the bare minimum level of access the service user will need to use WinRM and to be able to scan most of a remote Windows node successfully. In order to completely scan a Windows node, the service user will need to be a local or domain administrator. CIS scanning also requires local or domain administrator permission.
The below steps will need to be performed by an administrative user.
Give the service user security descriptor access
The following command can be run in a PowerShell command prompt to give the service user WinRM execute/invoke permissions:
Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI
In the popup that appears, ensure that the service user is added with the
Click Yes in the following dialog box to restart the WinRM (Microsoft.Powershell) service.
Adding the service user to the root\cimv2 namespace
- For Windows 2008, open Server Manager and expand Configuration. For Windows 2012, open Server Manager click Tools and then click Computer Management. Then expand Services and Applications.
- Right click on WMI Control and click Properties.
Click the Advanced tab and confirm that the default namespace for scripting is “root\cimv2”.
- Once confirmed, click the Security tab and expand the Root namespace.
Click the CIMV2 namespace and click Security.
Add the service account and under Permissions for Service Account check the Remote Enable (Allow) checkbox. Click Apply and OK.
Adding the service user to Service Control Manager
- Click Start, Run, type “cmd” and then click OK.
- Type the following command at the command prompt, and then press enter:
sc sdset SCMANAGER D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
Deploying service user permissions to target nodes
Using the script available here, the simplest way to deploy the permissions described in this article is via a Group Policy enforced script. This can be realized through several mechanisms:
- As a logon script: the script will be run and the settings applied as soon as an administrator logs into the target machine.
- As a scheduled task that runs once, immediately: the script will be run via a scheduled task, which will be subsequently deleted on completion. The task is created as soon as the Group Policy is applied.
- As a recurring scheduled task: the script will be run continuously as long as the Group Policy is in place. This can be useful in environments containing ephemeral nodes that may undergo drastic changes on a frequent basis.
- As a boot script: The script will be executed when the machine is restarted after application of the Group Policy.
Information regarding the setup of any of these methods can be found here.
Alternatively, any existing orchestration tools that can leverage PowerShell scripts should be able to deploy the script to similar effect, as long as they execute in a sufficiently elevated context.