- 09 Apr 2024
- 7 Minutes to read
- Print
- DarkLight
- PDF
Create a Non-administrator Windows Service Account For Netreo
- Updated on 09 Apr 2024
- 7 Minutes to read
- Print
- DarkLight
- PDF
In certain environments, it might be necessary to use non-privileged users for monitoring of remote Windows servers rather than a user that is a member of the local Administrator group on the target system.
See Windows Device Monitoring and Management for more information about using Windows service accounts for Netreo.
WinRM
Create the service account
First, you will need to create the Active Directory service account that you wish to use to monitor your Windows servers. It is imperative this account be used only for Netreo management and is not shared with any other applications or users.
Put the newly created user into the following domain groups:
- Domain Users
- Performance Log Users
- Performance Monitor Users
- Distributed COM Users
- Remote Management Users
Configuration of the monitored system
Verify WinRM service is running and its configuration
WinRM is installed by default in all supported Windows machines.
In Services, ensure that the Windows Remote Management service on the remote target is running, and that it is set to start automatically.
You can use the following command to verify the state of the WinRM service.
Get-Service -Name "Windows Remote Management (WS-Management)"
Verify WinRM configuration
To verify that WinRM is configured properly, use the following commands.
winrm quickconfig
Verify the WinRM configuration attributes.
winrm get winrm/config
The correct attributes for the WinRM client and Service in Response should be as shown below.
PS C:\Users\svc_admin> winrm get winrm/config
Config
MaxEnvelopeSizekb = 500
MaxTimeoutms = 60000
MaxBatchItems = 32000
MaxProviderRequests = 4294967295
Client
NetworkDelayms = 5000
URLPrefix = wsman
AllowUnencrypted = true
Auth
Basic = true
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
DefaultPorts
HTTP = 5985
HTTPS = 5986
TrustedHosts = *
Service
RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;DA)(A;;GR;;;IU)(A;;GA;;;S-1-5-21-3025375906-3933201271-
2378447025-1104)(A;;GA;;;S-1-5-21-3025375906-3933201271-2378447025-1106)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
MaxConcurrentOperations = 4294967295
MaxConcurrentOperationsPerUser = 1500
EnumerationTimeoutms = 240000
MaxConnections = 300
MaxPacketRetrievalTimeSeconds = 120
AllowUnencrypted = true
Auth
Basic = true
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
DefaultPorts
HTTP = 5985
HTTPS = 5986
IPv4Filter = *
IPv6Filter = *
EnableCompatibilityHttpListener = true
EnableCompatibilityHttpsListener = true
CertificateThumbprint
AllowRemoteAccess = true
Winrs
AllowRemoteShellAccess = true
IdleTimeout = 7200000
MaxConcurrentUsers = 2147483647
MaxShellRunTime = 2147483647
MaxProcessesPerShell = 2147483647
MaxMemoryPerShellMB = 2147483647
MaxShellsPerUser = 2147483647
Configure WinRM listener
There are two types of WinRM listeners that can be configured:
- HTTP Listener
- HTTPS Listener
HTTP Listener
The HTTP Listener uses TCP/5985 for communication.
- To configure HTTP listener use the command shown below.
New-WSManInstance -ResourceURI "winrm/config/Listener" -SelectorSet @{Address="*";Transport="HTTP";Port="5985";IPv4Filter="*";IPv6Filter= "*"}
- Then create a firewall rule to allow the HTTP listener.
# Add a new firewall rule $port=5985 netsh advfirewall firewall add rule name="Windows Remote Management (HTTP-In)" dir=in action=allow protocol=TCP localport=$port
HTTPS Listener
The HTTPS Listener uses TCP/5986 for communication.
Before configuring this listener, it is necessary to create a self-signed certificate and get its thumbprint. To create a self-signed certificate either the makecert
command or the New-SelfSignedCertificate
PowerShell commandlet can be used.
- Open a PowerShell window in Administrator mode and run the following command.
New-SelfSignedCertificate -DnsName "<YOUR_DNS_NAME>" -CertStoreLocation Cert:\LocalMachine\My
- This command will create a new self-signed certificate and output the certificate thumbprint as seen below.
PS C:\Users\Administrator> New-SelfSignedCertificate -DnsName "<<Server_FQDN>>" -CertStoreLocation Cert:\LocalMachine\My PSParentPath: Microsoft.PowerShell.Security\ Certificate::LocalMachine\My Thumbprint Subject ---------- ------- 9A70C85BE9BBC5D96DC3EE683A7573995EFB296B CN=<<Server_FQDN>>
- Copy the thumbprint (the number string under "Thumbprint") to the clipboard and run the following command (pasting the thumbprint into the appropriate location) to register the HTTPS listener in WinRM.
winrm create winrm/config/Listener?Address=*+Transport=HTTPS '@{Hostname="<YOUR_DNS_NAME>"; CertificateThumbprint="<COPIED_CERTIFICATE_THUMBPRINT>"}'
- This will produce output similar to the example below.
- Then create a firewall rule to allow the HTTPS listener.
# Add a new firewall rule port=5986 netsh advfirewall firewall add rule name="Windows Remote Management (HTTPS-In)" dir=in action=allow protocol=TCP localport=$port
Commands to set the WinRM client/service attributes
Enable HTTP Compatibility Listener
Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener -Value true
Enable HTTPS Compatibility Listener
Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener -Value true
Allow Unencrypted Service Calls
Set-Item WSMan:\localhost\Service\AllowUnencrypted -Value true
Allow Remote WinRM Access to Service
Set-Item WSMan:\localhost\Service\AllowRemoteAccess -Value true
Enable "Basic" Auth to WinRM Service
Set-Item WSMan:\localhost\Service\Auth\Basic -Value true
Allow Unencrypted Client Calls
Set-Item WSMan:\localhost\Client\AllowUnencrypted -Value true
Enable "Basic" Auth to WinRM Client
Set-Item WSMan:\localhost\Client\Auth\Basic -Value true
Enable PS-Remoting
This is critical for allowing external applications and users to interact with the server using WinRM.
Enable PS-Remoting
Assign the service account
Put the non-admin domain service account in the following local groups of the server.
Remote Management Users
net localgroup "Remote Management Users" /add <serviceaccount>
Performance Monitor Users
net localgroup "Performance Monitor Users" /add <serviceaccount>
Performance Log Users
net localgroup "Performance log users" /add <serviceaccount>
Distributed COM Users
net localgroup "Distributed COM Users" /add <serviceaccount>
Add SDDL permissions
Add the proper SDDL permissions to the service account so it can access the WinRM service.
- Execute the below command in PowerShell using Administrator mode.
winrm configSDDL default
- Add the service account <serviceaccount> and configure permissions.
- Check under "Allow" for:
- Read(Get,Enumerate,Subscribe)
- Execute(Invoke)
- Click the Advanced button to validate the permissions.
- Check under "Allow" for:
Configure WMI namespace permissions
Configure permissions for the service account to access WMI namespaces.
- Execute the below command in PowerShell using Administrator mode.
wmimgmt
- Right-click on WMI Control (Local) and select Properties.
- Select the “Security” tab.
- Select the “root” namespace.
- Click the Security button.
- Add the service account “svc_nonadmin” and allow it the following permissions:
- Execute Methods
- Enable Account
- Enable Account
- Click the Advanced button and validate that the permission for the “svc_nonadmin” service account is set to Allow for This
namespace and subnamespaces.
- Select the “Security” tab.
Query access
Allow the user to access service control manager queries.
Open a command prompt in “Administrator” mode and enter the following commands.
sc sdset SCMANAGER D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)
(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t
REG_DWORD /d 1 /f
WMI
Create the service account
First, you will need to create the service account that you wish to use to monitor your Windows servers. It is imperative this account be used only for Netreo management and is not shared with any other applications or users.
Put the newly created user into the following domain groups:
- Depending on your version of Windows Server:
- For Windows Server versions prior to 2019 put the user in Performance Log Users
- For Windows Server 2019 and later put the user in Performance Monitor
- For all Windows Server versions also put the user in Distributed COM Users
Configuration of the monitored system
Enable WMI access
You must now make sure that the Distributed COM Users group actually has permissions to access WMI.
In Windows, launch the Active Directory Users and Computers tool, select WMI Access from the list and open its properties. On the Member Of tab add the Distributed COM Users group to the list.
Configure DCOM security
Now, you must configure DCOM security for the group.
- Run Component Services from the Windows Start Menu by selecting Start > Administrative Tools > Component Services.
- Once it opens, expand Console Root, then Computers, and finally My Computer. Right-click on My Computer and select Properties.
- In the dialog that appears select the COM Security tab.
- In the Access Permissions section select Edit Limits.
- Select the Distributed COM Users group and ensure that all items under Allow are checked.
- Once you've reviewed the settings for Distributed COM Users, select OK to save your changes and be returned back to the COM Security tab.
- In the Launch and Activation Permissions section select Edit Limits.
- You are presented with a list of groups and permissions. Select the Distributed COM Users group and ensure that all items under Allow are checked.
- Select OK to save your changes.
- Exit the Component Services utility.
Configure WMI namespace security
Next, set WMI namespace security so that the Distributed COM Users group has access to WMI objects.
- Go to the Windows Start menu select Run. In the window that opens, in the Open: field type
wmimgmt.msc
and select OK. - Once it opens, right-click on WMI Control (Local) and select Properties.
- In the properties panel select the Security tab.
- Select Security at the bottom right of the window. This edits the security settings for the root WMI namespace.
- You now see a window that has the security settings for WMI for this machine. Select Advanced.
- You now see the advanced security settings for this WMI namespace. Add the Netreo service user account to the list and give at least the following Allow permissions (make sure that these permissions apply to this namespace and all the namespaces under it by selecting This namespace and sub-namespaces in the dropdown box above the permissions list window.):
- Execute Methods
- Enable Account
- Remote Enable
- Read Security
- Select OK to save the new permissions.
- Select OK again to exit out of the Advanced Security Settings for Root panel.
- Select OK again to exit the security properties.
Enable access to the Win32_Services object
You'll also have to enable access to the Win32_Services object. The simplest way to do this is via the command prompt.
- Right-click on the Windows CMD menu entry and select Run as Administrator.
- Paste in the following commands:
sc sdset SCMANAGER D:(A;;CCLCRPRC;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD) reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
The change should take effect immediately.
UAC Issues
It appears UAC needs to be disabled for these types of remote WMI queries to work.
With UAC running, an administrator account actually has two security tokens, a normal user token and an administrator token (which is only activated when you pass the UAC prompt).
Unfortunately, remote requests that come in over the network get the normal user token for the administrator; and since there is no way to handle a UAC prompt remotely, the token can't be elevated to the true-administrator security token.
See this Microsoft article for information on how to disable UAC: https://docs.microsoft.com/en-US/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction.