Secure PowerShell Alert Actions in SolarWinds Using Least-Privilege Accounts

Running external scripts or programs from SolarWinds alerts can introduce security risks if executed under privileged accounts. This guide explains how to configure a low-privilege service account with minimal permissions to run PowerShell scripts securely. By following these steps, you ensure compliance with the principle of least privilege, reduce attack surface, and maintain operational efficiency without granting unnecessary administrative rights.

• Incorrect credentials: Username or password mismatch.
• Account lacks required rights:
  • Log on as a batch job on the SolarWinds server.
  • NTFS permissions on script path.
• Password expired or changed in Active Directory.
• Execution policy restrictions or script path issues.
• Domain authentication issues (Kerberos/NTLM).
• Service account too restricted (missing Remote Management Users, Distributed COM Users, WMI permissions).

To fix the “Test failed” error and securely run PowerShell alert actions using a non-admin account, the following steps:

1. Configure Minimal Permissions on Target Server

Executed a PowerShell script to:

• Add the service account to:
  • Remote Management Users (for WinRM access).
  • Distributed COM Users (for DCOM/WMI access).
• Grant Remote Enable permission on WMI namespace root\cimv2.

Script Used:

# Variables
$ServiceAccount = "Domain\ServiceAccount"

Write-Host "=== Adding $ServiceAccount to Local Groups ==="

# Add to Remote Management Users
net localgroup "Remote Management Users" $ServiceAccount /add

# Add to Distributed COM Users
net localgroup "Distributed COM Users" $ServiceAccount /add

Write-Host "=== Configuring WMI Permissions ==="

# Get WMI Security Settings
$namespace = "root\cimv2"
$account = $ServiceAccount

# Connect to WMI namespace
$wmiconfig = Get-WmiObject -Namespace "root\cimv2" -Class "__SystemSecurity"

# Create trustee object
$trustee = ([WMIClass]"\\.\root\cimv2:__NTLMUserAccount").CreateInstance()
$trustee.Domain = ($account.Split("\")[0])
$trustee.Name = ($account.Split("\")[1])
$trustee.Flavor = 0

# Create ACE (Access Control Entry)
$ace = ([WMIClass]"\\.\root\cimv2:__ACE").CreateInstance()
$ace.AccessMask = 2 # Remote Enable
$ace.AceType = 0
$ace.Trustee = $trustee

# Apply ACE
$sd = $wmiconfig.GetSecurityDescriptor().Descriptor
$sd.DACL += $ace
$wmiconfig.SetSecurityDescriptor($sd)

Write-Host "=== Verification ==="
Write-Host "Checking group memberships..."
net localgroup "Remote Management Users"
net localgroup "Distributed COM Users"

Write-Host "WMI permissions applied for $ServiceAccount"

This script performs the following:

• Adds the account to Remote Management Users and Distributed COM Users local groups (enables WinRM and DCOM access).

• Grants Remote Enable permission on the WMI namespace root\cimv2.

• Ensures the account has only the minimal required privileges — no administrative rights.

2. Enable PowerShell Remoting

PowerShell Remoting (WinRM) must be enabled on the target server to allow remote script execution.
Run the following command in an elevated PowerShell session on the target machine:

Enable-PSRemoting -Force

This ensures the WinRM service is configured, started, and allowed through the Windows Firewall.
You can verify connectivity using:
 

Test-WsMan <TargetServerName>

3. On the SolarWinds Application Server

Updated the PowerShell execution policy to allow locally created scripts to run:

Set-ExecutionPolicy RemoteSigned

4. Validation

After completing the above steps, the PowerShell script executed successfully when triggered from the alert action using a non-admin account. Logs were generated correctly at the defined path.

Simulated: