nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
- SolarWinds Academy
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
- Goal Oriented AI
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

gMSA accounts for Windows polling mount point (With Least Privilege) access

NKSharma

Hi All,

While connecting the gMAs account with agentless monitoring with wmiRMonly +Kerbrose authentication: getting the below error ( SolarWinds.Net.WMI.Exceptions.WindowsConnectionException: Cannot retrieve data from 'Hostname' at namespace 'root\CIMV2' with query 'select Manufacturer,Version from Win32_OperatingSystem')

Question:

1.Has anyone encountered the above error code during configuration? Please let us know if you have experienced this issue and provide the steps or recommendations to resolve it.

2.For SolarWinds agentless monitoring, using a non-admin account with Least Privilege can be reliable, but it depends on what data you need to collect and whether the required permissions have been granted on the target servers.

ANy other information, suggestion related to gMSA?.

Thanks

Find more posts tagged with

sam

orion

Accepted answers

All comments

mr.castaneda

Hi NKSharma,

A few things typically cause that error (WindowsConnectionException: Cannot retrieve data... at namespace 'root\CIMV2') when polling over WinRM with Kerberos under least privilege:

1. WMI Namespace & Group Permissions on the Target

For a non-admin account to query root\CIMV2 via WinRM, the target server needs:

Group Memberships: The account must be in Remote Management Users (for WinRM access) and Performance Monitor Users.
WMI Namespace Security: Open wmimgmt.msc on the target node > right-click WMI Control (Local) > Properties > Security tab > select Root\CIMV2 > Security button. Ensure the account or group has both Enable Account and Remote Enable granted.
WinRM Listener Access: If you hardened WinRM, verify the account has read/execute permissions on the WinRM listener security descriptor (winrm configSDDL default).

2. Kerberos & Hostname Resolution

Kerberos over WinRM strictly relies on Service Principal Names (SPNs):

Make sure the node in SolarWinds is configured using its FQDN rather than an IP address or NetBIOS name. Kerberos authentication will fail to generate an HTTP/WSMAN ticket if the SPN cannot be matched to the target machine's AD computer account.
Verify reverse DNS resolves properly from your Polling Engine to the target.

3. A Note on gMSA with Agentless Polling

The SolarWinds Platform credential library expects a static username/password. Because Active Directory manages and rotates gMSA passwords automatically without exposing them, gMSAs can't be directly entered into the standard credential manager for agentless polling.
If you need to use gMSA or avoid the overhead of configuring remote DCOM/WMI permissions and firewall ports on every server, consider deploying the SolarWinds Agent on the target. The agent runs locally, bypasses remote RPC/WinRM hurdles, and works much better in locked-down least-privilege environments.

Quick Test

From the SolarWinds Polling Engine, open PowerShell and test the connection directly to see the exact OS-level failure:

Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName "target.domain.local" -SessionOption (New-CimSessionOption -Protocol Wsman)

If that fails outside of SolarWinds, it will pinpoint whether it’s an access denied (WMI rights) or authentication (Kerberos/SPN) issue.

Hope this points you in the right direction!

Lofstrand

Hi NKSharma

gMSA is a very good way of handling the account that is used while connecting to the monitored targets. But the required privileges are the same as with any other account. The permissions required does not change, just the way you enter the account credentials.

So, normally you will require administrative privileges on the account used to poll WMI information. There are ways of getting around admin privs, but they are not easy.

Lofstrand

AI generated answer? Well, nr 3 is wrong. gMSA can be used in the SolarWinds platform

mr.castaneda

Thanks for catching that, Lofstrand. You’re right—gMSA can be used with the SolarWinds Platform, including supported SAM monitors. My statement in point 3 was wrong, and I shouldn’t have suggested an agent was necessary to use it. I should have checked before posting. Sorry for the confusion, and thanks for the correction.

NKSharma

Thank you all for sharing the info. I also agree that Step 3 is not relevant to gMSA Kerberos authentication. The gMSA account is being used to poll data through WinRM only, with Kerberos authentication. ;)

NKSharma

Thanks for sharing the above details: -

Below are my finding while testing the gMSA account:-

Phase 1: We have synchronized the gMSA account AD) to SolarWinds server. --- tested and completed successfully.

Phase 2: We have tried to connect the client machine to SolarWinds with gMAS account with non-admin user. ---- tested failed and not successful. We suspect that the issue is related to Kerberos authentication failing between SolarWinds and the target devices.

Phase 3: We worked with the AD team and performed additional testing between the client machine and SolarWinds using the gMSA account with local administrator privileges. The gMSA account functioned as expected, and the client machine successfully polled data to SolarWinds. -----tested and completed successfully with winRMonly+ Kerberos authentication.

Whenever we are testing the Traget Machine with below configuration and re-validate the required settings for a non-admin user (Least Privilege model). However, the WinRM/WMI test is failing.

Below step recommended in SolarWinds Documentation step by step in target machine

Non-Admin User

For non-admin users, complete these steps:

Run the following script:
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI -Force
$GMSA = "<domain>\<username>$"
# Minimum required
Add-LocalGroupMember -Group "Remote Management Users" -Member $GMSA
Add-LocalGroupMember -Group "Performance Monitor Users" -Member $GMSA
Example:
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI -Force
$GMSA = 'Domain\GMSA_account$'
Add-LocalGroupMember -Group 'Remote Management Users' -Member $GMSA

 Add-LocalGroupMember -Group 'Performance Monitor Users' -Member $GMSA

Run the following script which will open permission menu:
winrm configSDDL default
wmimgmt

Add the <username>$ that was created earlier and configure permissions. Check “Allow” for Read(Get,Enumerate,Subscribe) and Execute(Invoke), and if you need modules that modify, check Write(Put,Delete,Create).

Run the following script that will open WmiMgmt menu:
Right click on WMI Control (Local) and go to Properties.
Go to Security tab and click on “Security“ button that will open Security for Root menu.
Add “Remote Management Users” group and click on Advanced button.
In new dialog select “Remote Management Users” and click Edit.
In the Applies to dropdown select 'This namespace and subnamespaces'.
In the Permissions section check the following boxes:
- Execute Methods
- Enable Account
- Remote Enable
Click OK to save.
Run the following script:
$rmSid = (New-Object System.Security.Principal.NTAccount("BUILTIN","Remote Management Users")).Translate([System.Security.Principal.SecurityIdentifier]).Value
$currentSDDL = (Get-Item WSMan:\localhost\Service\RootSDDL).Value
$newSDDL = $currentSDDL -replace "D:P", "D:P(A;;GR;;;$rmSid)"
Set-Item WSMan:\localhost\Service\RootSDDL -Value $newSDDL -Force
Restart-Service WinRM

Test is failed.

Error Log: [STP SmartThreadPool Thread #1362] ERROR SolarWinds.Orion.Pollers.Framework.WMI.WindowsConnectionHelper - (null) ValidateWmiNode encountered a
WmiException while validating Wmi node
SolarWinds.Net.WMI.Exceptions.WindowsConnectionException: Cannot retrieve data from 'Traget Machine ip address/hostname ' at namespace 'root\CIMV2' with query 'select Manufacturer,Version from Win32_OperatingSystem'

Any suggestion and recommendation if missing any permission or configs in target machine. it would be great help. Thank you

mr.castaneda

Hi NKSharma, thanks for sharing the detailed testing. The fact that the same gMSA works with local admin rights points more toward a permissions issue on the target than a general Kerberos failure, although that error alone doesn’t confirm the cause or identify which permission is missing.

A couple of things worth checking:

Permissions on root\CIMV2 itself: Confirm that the “Remote Management Users” permissions applied at Root actually inherited into CIMV2, including Enable Account, Remote Enable, and Execute Methods.
The resulting WinRM permissions: The RootSDDL script only inserts the permission entry if the existing descriptor contains the exact text D:P. Check the value afterward to make sure it actually changed, and verify the gMSA’s Read/Execute access.

If those checks don’t resolve it, please submit an online Support Case or call Technical Support at +1-866-530-8040, option 3, or +1-512-682-9300. Include your SolarWinds Platform/SAM and target Windows Server versions, as well as diagnostics and test results so Support can investigate without repeating the work you’ve already done.