Configure Kerberos for WMI authentication in the SolarWinds Platform
You can use Kerberos protocol for WMI authentication with the following exceptions.
- In 2022.4, Kerberos protocol is supported in the SolarWinds Platform except for polling from SAM and VMAN.
- In 2023.1, Kerberos support was extended to include SAM polling. VMAN Hyper-V polling remains unsupported.
- Configure Kerberos on the domain
- Step 1: Disable NTLM and configure SPN
- Step 2: Configure the DNS server in the Domain Controller
- Step 3: Configure trust settings between different Active Directory forests
- Step 4: Configure WinRM listener on the polling engine and on the target machine (optional)
- Configure the SolarWinds Platform to use Kerberos
- Step 1: Configure polling settings
- Step 2: Configure Cortex
- Step 3: Add WMI credentials in the correct format
- Verify that SolarWinds Platform is working with Kerberos
- Show More
Configure Kerberos on the domain
- Step 1: Disable NTLM and configure SPN
- Step 2: Configure the DNS server in the Domain Controller
- Step 3: Configure trust settings between different Active Directory forests
- Step 4: Configure WinRM listener on the polling engine and on the target machine (optional)
Step 1: Disable NTLM and configure SPN
Manually
-
Disable NTLM in the domain.
Open the Group Policies Editor, go to Security Options (Computer Configuration > Policies > Windows Settings > Security Settings > Security Options), and make sure the following policies are set to Deny all.
- Network security: Restrict NTLM: Incoming NTLM traffic
- Network security: Restrict NTLM: NTLM authentication in this domain
- Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers
-
Configure SPN using a CMD command.
Open the Command prompt and run the following command. Replace
<hostname>
with the hostname of the current server.setspn -Q */<hostname>
Using a script
Run the following PowerShell script on every machine in the domain to accomplish both restricting NTLM and setting SPN in one step.
# Restricting NTLM traffic on the machine
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0" -Name "RestrictReceivingNTLMTraffic" -Value 2
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0" -Name "RestrictSendingNTLMTraffic" -Value 2
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\Netlogon\Parameters" -Name "RestrictNTLMInDomain" -Value 7
# Getting hostname of divice and configuring SPN
$computerName = $env:computername
setspn -Q */$computerName
Step 2: Configure the DNS server in the Domain Controller
The Forward Lookup Zones and Reverse Lookup Zones should be configured to make Kerberos work.
Step 3: Configure trust settings between different Active Directory forests
If any nodes are in domains in different AD forests, you need to configure trust between these forests to be able to poll theses nodes.
-
Configure Conditional Forwarders on each AD domain controller at first.
-
Go to Server Manager > Tools > DNS.
-
In DNS Manager, go to the Conditional Forwarder menu and select New Conditional Forwarder.
-
In New Conditional Forwarder menu, enter DNS Domain and IP Address of the Domain Controller which is in another forest.
-
Perform steps a-c on the other Domain Controller.
-
-
Configure trust between AD domains.
-
Go to Server Manager > Tools > Active Directory Domains and Trusts.
-
Select domain and go to Properties.
-
In Properties menu go to Trusts tab and click New Trust.
-
Enter domain name and click Next.
-
Select Forest trust and click Next.
-
Select Two-way and click Next.
-
Select Both this domain and the specified domain and click Next.
-
Enter user name and password for the specified domain and click Next.
-
Select Forest-wide authentication and click Next
-
Review the trust settings and Click Next.
-
Review the Trust Creation Complete screen and Click Next.
-
Select Yes, confirm the outgoing trust and click Next.
-
Select Yes, confirm the incoming trust and click Next.
-
Click Finish.
-
Now you should see added trusts on both Domain Controllers.
Step 4: Configure WinRM listener on the polling engine and on the target machine (optional)
If you want to run Kerberos for WinRM polling, you need to configure a WinRM listnener on the polling engine and on the target machine.
-
On the target machine (the device you want to monitor via WinRM), run the following script.
winrm set winrm/config/service/Auth @{Kerberos="true"}
-
Run the following script on the polling engine server
winrm set winrm/config/client/Auth @{Kerberos="true"}
-
Verify that the listener was configured correctly by checking the output of the following command:
winrm get winrm/config
Configure the SolarWinds Platform to use Kerberos
To use Kerberos, the following requirements must be met:
- DNS: Both Reverse and Forward lookup zones must be configured.
- SPN must be registered.
- Credentials must be in the correct form.
Step 1: Configure polling settings
The following steps are applied globally, for all nodes. To adjust polling settings for individual devices, edit the device and adjust the options in WinRM settings. See Edit node properties.
-
In SolarWinds Platform Web Console, click Settings > All Settings, and then click Polling Settings.
-
Scroll down to Windows Connection and specify the connection mode:
-
WinRmPreferred - the default option. First, polling is attempted via WinRM. If WinRM connection cannot be established, polling falls back to WMI over DCOM.
-
WinOnly - connect only via WMI over DCOM.
-
WinRmOnly - connect only via WinRM.
Review the pros and cons of the connection modes:
Feature WimRMOnly WinRmPreferred WmiOnly Description
Uses WinRM (Windows Remote Management) exclusively for remote management. Uses WMI (Windows Management Instrumentation) exclusively for management.
Uses WinRM when available; falls back to WMI if WinRM is not available.
Primary Protocol
WS-Management (SOAP-based)
WinRM preferred, WMI as fallback
DCOM (Distributed Component Object Model)
Remote Access
Designed for remote access over HTTP/HTTPS.
Tries to use HTTP/HTTPS, falls back to DCOM for WMI.
Designed for remote access over DCOM only.
Performance
Optimized for remote communication with lower overhead.
Offers flexibility but may introduce latency when falling back to WMI.
Higher latency and resource usage due to DCOM overhead.
Firewall Friendly
Works well across firewalls with ports 5985 (HTTP) and 5986 (HTTPS).
Works across firewalls if WinRM is used; DCOM fallback may require additional open ports.
Often blocked by firewalls due to random ports used by DCOM.
Use Case
Best for environments with properly configured WinRM (modern remote management).
Useful in mixed environments with partial WinRM configuration. Best for legacy environments that rely solely on WMI.
Authentication
Supports Kerberos, NTLM, and certificate-based authentication.
Uses WinRM authentication (Kerberos, NTLM) when available; falls back to WMI authentication.
Relies on Kerberos, NTLM, or Basic authentication for WMI.
Security
More secure due to encryption over HTTP/HTTPS.
Secure if using WinRM; less secure during WMI fallback.
Less secure due to lack of encryption and reliance on DCOM.
Example Scenario
Managing remote servers in a modern, firewall-restricted network.
Managing systems in a mixed environment with both WinRM and legacy WMI.
Legacy systems where only WMI is available or supported.
-
-
Set the default authentication mode for WMI.
This mode is forcing the use of Kerberos. SolarWinds Platform will always try to resolve the IP address and hostname and find the FQDN.
If the SolarWinds Platform fails to create a connection using the Kerberos authentication protocol a connection error will be logged and you can see it in the SolarWinds Platform Web Console.
This mode tries to connect using Kerberos first. If the SolarWinds Platform fails to create a connection using the Kerberos authentication protocol, a connection error will be logged and SolarWinds Platform will try to connect using NTLM and IP address.
This mode uses NTLM.
-
Select the authentication mechanism to be used for WinRM.
-
Default - Typically uses NTLM if the node's address is not in Fully Qualified Domain Name (FQDN) format. Depending on the system's configuration, it may fall back to Negotiate, which can use Kerberos in domain environments.
-
Digest - uses a challenge-response mechanism where the password is hashed and not sent over the network in plain text.
-
Negotiate - automatically selects between Kerberos (if available) and NTLM, depending on the environment.
-
Basic - sends the user name and password over the network in plain text unless encrypted with HTTPS.
-
Kerberos - a highly secure ticket-based authentication protocol used in Active Directory environments for mutual authentication.
-
NtlmDomain - uses NTLM for challenge-response authentication.
-
CredSSP (Credential Security Support Provider) - allows the delegation of credentials from the client to the server, enabling single sign-on (SSO) and remote authentication.
For details, see Authentication for Remote Connections in Microsoft documentation.
-
-
Submit the changes. The new setting will be applied within a few minutes.
Step 2: Configure Cortex
-
Open the File Explorer and go to the Orion Installation Folder.
-
Open the
SolarWinds.Cortex.appsettings.json
file.Default location:
C:\Program Files\SolarWinds\Orion\SolarWinds.Cortex.appsettings.json
-
In the file, find the
WmiConfig
section and modify theWmiAuthenticationMode
property. Make sure the value corresponds with the required WMI authentication:KerberosStrict
KerberosPreferred
Default
-
Save the changes and Restart Cortex using the SolarWinds Platform Service Manager.
Step 3: Add WMI credentials in the correct format
To make Kerberos Authentication work, you have to use a domain level account. In addition, in SolarWinds Platform you have to enter credentials in strict form:
-
<FullDomainName>\<Username>
-
<Username>@<FullDomainName>
Verify that SolarWinds Platform is working with Kerberos
Verify WMI nodes data is polled and Real-Time polling is working correctly. The SNMP nodes are not affected by the changes.
Verify that the connection is working for SolarWinds Platform
-
In the SolarWinds Platform Web Console, click Settings > Manage Nodes, and select a WMI-polled node.
-
Click Edit Properties and scroll down to the Polling Method section.
-
Click Test to test the credentials. The test should be successful.
Verify connection is working for Cortex
-
In the SolarWinds Platform Web Console, click Settings > Manage Nodes, and click a WMI-polled node.
-
On the Node Details view, click Performance Analyzer in the Management widget.
-
Make sure that Historical Data is presented.
-
Make sure that Real-Time polling works.
Troubleshooting
- Cannot resolve IP address to FQDN in logs
- The RPC server is unavailable
- Cannot pass the credentials test for the remote agent deployment
- Cannot deploy the agent or WPM Player using the remote installer
- Real time polling/Cortex metrics don't work on WMI nodes
- Adding an Exchange node to HCO with Kerberos authorization enabled results in a timeout
Cannot resolve IP address to FQDN in logs
Kerberos requires providing FQDN to establish a connection between two machines. To address this issue, add all machines including the domain controller to Forward/Reverse lookup zones on the DNS server.
The RPC server is unavailable
This is a generic error that might indicate the following issues.
Incorrect credentials
- Make sure you specified credentials in the correct format.
- Make sure the password is correct.
- Check the permissions for your Windows user.
WMI Service is turned off on the target machine
- See RPC Quick Fixes in Windows Server Troubleshooting: RPC server is unavailable (© 2022 Microsoft, available at https://msdn.microsoft.com, obtained on November 14, 2022.)
- Make sure the Winmgmt service is running. In the Windows Task Manager, go to Services and search for WinMgmt.
Invalid namespace error
Verify that the namespace exists on the target machine using the WBEMTEST application in Windows.
- On the target machine, enter WBEMTEST on start menu.
- Now on the Windows Management Instrumentation Tester window, click Connect...
- Enter the namespace to the Namespace section and click Connect.
- If the name doesn't exist, an Invalid namespace error will open.
A missing namespace indicates that some components/applications like IIS/SQL/DNS/DHCP were not installed properly. Fix the installation of components.
Cannot pass the credentials test for the remote agent deployment
Use hostname instead of the IP Address. Kerberos is forcing the usage of hostname instead of the IP address. Not being able to resolve an IP address to the hostname indicates an incorrect configuration of your DNS server.
Cannot deploy the agent or WPM Player using the remote installer
The agent/WPM Player deployment never ends or you see errors during the deployment.
- The remote installer uses port 4091, make sure the port is open.
- Use the hostname instead of IP address.
- Deploy the agent/WPM Player on the target machine manually and then add it using the SolarWinds Platform Web Console.
Real time polling/Cortex metrics don't work on WMI nodes
When you click Start RealTime Polling, no data is showing or historical data is missing for some metrics.
To resolve the issue, complete steps in Step 2: Configure Cortex and wait for Cortext to start using the updated settings values.
Adding an Exchange node to HCO with Kerberos authorization enabled results in a timeout
If adding an Exchange node takes too long or results in a timeout, use the following workarounds.
Add Node wizard
Do not use WMI to poll the Exchange node. In the Add Node wizard, select an alternative polling method.
- Select ICMP as the polling method and assign the Exchange AppInsight manually. See Configure AppInsight for Exchange on nodes.
- Use SolarWinds Platform Agent polling.
See Add a single node for monitoring to the SolarWinds Platform.
Network Discovery
Avoid discovering Exchange 2016 nodes via WMI. Before you start a discovery, add Exchange nodes manually using ICMP or SolarWinds Platform Agent polling. See Discover your network for the SolarWinds Platform with the Discovery Wizard.
The scripts are not supported under any SolarWinds support program or service. The scripts are provided AS IS without warranty of any kind. SolarWinds further disclaims all warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The risk arising out of the use or performance of the scripts and documentation stays with you. In no event shall SolarWinds or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the scripts or documentation.