Documentation Index

Fetch the complete documentation index at: https://docs.fortifiedwisdom.com/llms.txt

Use this file to discover all available pages before exploring further.

Windows Collection Requirements

Prev Next

To collect Windows metrics (WMI and Performance Counters), a Windows account is required, preferably an Active Directory (AD) account. If a SQL account is used for collection, WMI and Performance metrics will not be collected, and costing information cannot be calculated. WISdom does not support splitting credentials for the same instance and host (e.g., SQL Auth for the SQL instance and a Windows account for WMI).

Permissions Required on Windows Targets

The collection account requires specific permissions on every Windows server it monitors.

Least Privilege Configuration (Recommended)

Modern Windows operating systems require explicit group memberships and WMI namespace permissions for remote data collection. Configure the following on each monitored Windows server:

Group Memberships

Assign all three groups locally on each monitored server via Computer Management › Local Users and Groups › Groups.

Group Purpose
Performance Monitor Users Required to collect Performance Counter data
Distributed COM Users Enables remote activation of COM objects for WMI collection
Remote Management Users Allows remote management tasks for monitoring

WMI Namespace Security (root\CIMV2)

Explicit WMI namespace permissions are required in addition to group memberships. Follow these steps on each monitored server:

  1. Open wmimgmt.msc.
  2. Right-click WMI Control (Local) and select Properties.
  3. Click the Security tab.
  4. Expand Root, select CIMV2, then click Security.
  5. Click Add, then choose one of the following paths to add permissions for the selected account:
    • Remote Management Users group or local WISdom Service Account — In the Locations dialog, select the local computer, then add the group or the local account.
    • Domain WISdom Service Account — In the Locations dialog, select Entire Directory or the specific domain (for example, fortified.com), then add the WISdom Service Account. Use this path for domain accounts or gMSAs.
  6. Under Allow, check Enable Account and Remote Enable, then click OK.
Migrating from Local Administrator Access

In older versions of Windows Server, adding the collection account to the Local Administrators group was the standard approach and implicitly granted all required WMI, DCOM, and Performance Counter permissions. Microsoft's current security guidance discourages broad Local Administrator access. The least-privilege configuration above is the recommended approach for all new deployments and should be used when hardening existing environments.

Local Administrator Membership Alone Is Not Sufficient

On newer Windows Server and Windows client releases, an account can hold Local Administrator rights and still fail to collect WMI and Performance Counter data remotely, returning an Access Denied error (0x80070005). The explicit group memberships and WMI namespace permissions above are required regardless of Local Administrator status.

This behavior is caused by a User Account Control (UAC) feature known as Remote UAC (Remote Restrictions). When UAC is active, Windows strips elevated privileges from any account authenticating over a network or remote logon, issuing a filtered, non-elevated access token instead. Because remote WMI and Performance Counter queries require administrative-level DCOM/WMI permissions, the connection is rejected even though the account is a local administrator.

Service Start/Stop Permissions (Watchdog and Data Collector)

The collection account must be able to stop and start the Fortified WISdom Watchdog service (FortifiedWISdomWatchdog) and the Fortified WISdom Data Collector service (FortifiedWISdomDataCollector). By default, only accounts with Local Administrator rights can start or stop a service, and that holds true even when the account attempting the action is the same account the service runs as. A non-administrator service account cannot start or stop a service, including its own, without being granted these rights explicitly.

To avoid adding the collection account to Local Administrators, grant Start and Stop permissions directly on each service by editing its SDDL (Service Security Descriptor Definition Language) security descriptor. Repeat the steps below for both the Watchdog and Data Collector services.

  1. Open an elevated Command Prompt. Command Prompt has proven more reliable than PowerShell for this step.
  2. Retrieve the service's current security descriptor:
    sc.exe sdshow FortifiedWISdomWatchdog
    
    This returns an SDDL string similar to:
    D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
    
  3. Get the SID for the collection account. In PowerShell:
    $account = New-Object System.Security.Principal.NTAccount("DOMAIN\UserName")
    $sid = $account.Translate([System.Security.Principal.SecurityIdentifier])
    $sid.Value
    
    Use MachineName\UserName for a local account, or DomainName\UserName for a domain account.
  4. Build a new access entry granting the account Query Config, Query Status, Start, Stop, and User-Defined Control rights on the service:
    (A;;CCLCRPWPCR;;;<SID>)
    
    Replace <SID> with the value from step 3.
  5. Insert the new entry into the SDDL string from step 2, immediately after D: and before the existing entries, then apply it:
    sc sdset FortifiedWISdomWatchdog "D:(A;;CCLCRPWPCR;;;<SID>)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"
    
    Always use the SDDL string returned in step 2 for the specific server, rather than copying the example above verbatim, then insert the new entry the same way.
  6. Repeat steps 1 through 5 for the Data Collector service, using FortifiedWISdomDataCollector in place of FortifiedWISdomWatchdog.
Reading the Access Entry

Each letter pair in the access string maps to a specific service right: CC (query configuration), LC (query status), RP (start), WP (stop), and CR (user-defined control). The entry above grants the minimum set of rights the collection account needs to control the service without full Local Administrator access.

Testing and Troubleshooting Windows Connectivity (Basic)

The ability of the collection account to connect to target Windows hosts may be tested with the following methods. The collection account credentials must either be passed via a script or the application must be run under the collection account.

Perfmon

Perfmon is available on all Windows machines but must be run as the collection account.

  1. Locate the perfmon program, typically: C:\WINDOWS\system32
  2. [SHIFT]-right-click the application and select "Run as Different User"
  3. Run Performance Monitor, click the green + sign, and enter \ServerName\ to connect to the target host.
  4. Add a counter to confirm it is successfully added and displayed.

WBEMtest

This utility is installed on all Windows machines and can be found in C:\Windows\System32\wbem.

  1. Run WBEMtest as the collection account: [SHIFT]-right-click and select "Run as Different User"
  2. Click the [Connect] button.
  3. Enter \ServerName\root\cimv2 in the Namespace field.
  4. Click [Connect].
  5. Select the [Query] button to open a WQL query window.
  6. Enter the query: select * from Win32_Process
  7. Click [Apply]. The list of processes running on the host will be displayed if successful.

PowerShell

Either powershell.exe or powershell_ise.exe may be used. Executables are typically found in C:\WINDOWS\system32\WindowsPowerShell\v1.0.

Run the executable as the collection account, or pass the Windows account credentials via the script. Then run:

Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem" -ComputerName <ComputerName>