Local Admin permissions - why?

It says right in the manual, "Only a credential that has administrator rights on the target server has the necessary permissions to access the target server’s WMI services."

In the same place you can find extremely detailed instructions on how to avoid putting a user account in the Local Administrator's group, and at the end of the article a "Your Mileage May Vary" disclaimer. It's academic...moot really. The information only provided as a "technical discussion" of what you'd need to do if you didn't want to put an account in the Local Administrator's group.

But my workplace has begun to develop a healthy paranoia of having any extra accounts in the Local Administrator's group, and have begun an investigation into it which would make Tomás de Torquemada ask, "Is this really necessary?"

So without further ado, the questions: Why is it so necessary to have an account in the Local Administrator's group? I know that it's needed for WMI polling, for Windows Performance Counters, and all the Windows Templates, but WHY must it be an account in the Local Administrator's group?

Can anyone here recommend a way that I can still get WMI polling and Performance Counters from Windows without that? Or, I'm CERTAIN that I can't be the only one using Solarwinds who's higher-ups get titchy at this sort of thing, can anyone recommend anything to me that would allow me to still use these accounts without sacrificing security?

I seem to recall reading something somewhere that would allow reading Windows Performance Counters or polling WMI over SNMP, has anyone ever had any luck with that?

Thanks in advance for anything...ANYTHING...which would shed light, here.

Find more posts tagged with

sam

Local Administrator

permissions

WMI

Accepted answers

All comments

mesverrum

This article explains the process.

https://support.solarwinds.com/SuccessCenter/s/article/How-to-create-a-non-administrator-user-for-SAM-polling

I've done it before, the first few steps are pretty simple to do and setting the services permissions seemed to be optional in most cases for me. It does become one of those things where every time you turn on a new SW feature then it becomes hit or miss if you are going to need to mess with permissions again. Since SW support doesn't want to spend all day chasing your permissions they just work under the model where you start with admin and if you want to tighten it up more then it's on you to figure out what might break.

The most popular alternative to avoid all that is to just use the agent, which runs under the local system accounts and has all the permission it needs without needing to create an account for it to use.

silverbacksays

Local Admin is quite often 'the default' when you need to be 100% certain of the reliability of any action initiated by said account. Monitoring reliability is generally pretty important, hence SWI recommend the use of an account with these privileges is used when WMI is the polling method. While you could get around with lesser privileges, SWI will not support you if you have problems. They'll simply say:

This Is The Way

As @mesverrum mentioned, the most popular option is to use Orion Agents. Not only do these only require admin privileges at the point of installation, there are many other benefits, including end-to-end encryption and the caching of monitoring history for up to and hour should connectivity the assigned polling engine be lost. Also, each Agent can be 'upgraded' via additional plug-ins, providing them with additional functionality such as acting as a NetPath Probe.

marcrobinson

A big part of the issue with WMI has to do with how security was setup in wmi and windows. You can script/gpo a response to permit non-admin accounts to grab data. But you will need to account for variations in operating systems. 2008 and 2016 will require subtle tweaks for example. If you want event logs, that is another permission, and services will require separate ones. I looked into this, and it can be done, but you really need to spend time on it.

It can be done, but you need everyone to agree to do it. Otherwise a service account with local admin is the way to do this. Agents are not free of difficulties, and they have their own sprawl now. The problem is that 'every' (yeah I am generalizing) solution wants to install an agent... Most of them are redundant in one or more capacities. And some have different .net requirements. Then you ideally need to monitor the agent(s) for functionality. Agents (generalizing again - yes I have some examples) have been removed to restore a system to proper function. Agents are not the panacea either.

I would love to hear from thwacksters on how you are dealing with agent sprawl, agent requirements and agent interactions,including the redundancy from some (orion, appoptics, sccm/intune, snow, new relic, dynatrace, etc.) Or am I alone in noticing issues with agent sprawl and interactions?

mesverrum

I'd agree, i personally do everything I can to avoid agents, but its the low effort answer when security teams start kicking up noise about account permissions. Windows data collection is mess, in a perfect world there would be some form of a read only role that effectively gave you access to all the information on and about a server without also being the same set of permissions that allow you to install software and mess with configuration in ways that gets the Sec team breathing down own necks. MS never has treated it as a priority to address because they just work under the assumption that you're running sccm and windows defender and that's the end of the story (ha).