Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
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

Microsoft Credential Guard Not Compatible with Many SolarWinds Modules - IT WILL BREAK YO POLLING

We were required to enable credential guard as part as a security vulnerability/STIG requirement and noted it breaks polling. SolarWinds support will not help you since they deem it as a "3rd party tool"

Once cred guard is enabled on your polling engines, NTLM polling no longer works, you must use Kerberos Strict authentication. Kerberos is not compatible with several SolarWinds modules.

Behavior i noticed after enabling it was that polling engine polling completion % dropped signifagently and bounced around between 16-80%. I forced WMI authentication to user Kerberos strict per cred guard requirements, and the polling completion % went back to 100%, however, i then noticed WMI authentication was failing at the device level on multiple domains (not all). I was working through ensuring i had everything configured properly for keberos requirements to resolve it, then noted SolarWinds documentation that states Kerberos isn't supported in several modules.

Thought i would share what i found because nobody has posted anything online about this.

I'm sure if you don't use the specific modules in which Kerberos is not supported you may be able to get your system compatible with cred guard but in there are some pre-requisites needed.

Sources

Find more posts tagged with

Microsoft Credential Guard

Comments

marcrobinson

You mentioned the three unmentionable letters.... W M I... I suspect that the long term answer may be another unmentionable (for some of us) - Agents. Mitigating wmi can be problematic, and it sounds like your organization went with that approach. The basic alternatives, but they require a wee bit of work - creating and deploying policies/scripts to use a limited (non-admin) service account for wmi or agents. There are some threads on limiting the WMI, but no official support. A lot of the problem lies with Microsoft as WMI security tends to change with server versions and potentially security patches too. Other items that can help (also more work) - firewall rules allowing wmi to the polling servers, changing passwords and service accounts routinely, and utilizing the windows firewalls also. Agents start looking attractive at this point.

I suspect that some of the others around here that work in the ISP/MSP realm can provide more thoughts too. Thank you for posting this as it will serve as a warning of things to come. I do not see less security, but more, and not all of it will be painless.