Is there a means to better secure WMI with PRTG? Everything seems to indicate that the correct/supported method is to ensure that the PRTG monitoring user/service account is a member of Domain Admins. While this does in fact work for us, having an account with Domain Admin priveledges in use either by IT or by users/developers who are monitoring their software on our servers, seems excessive and unsecure. Can we not create a PRTG_SERVICE account, provide it rights to remotely read WMI (as we only need to read performance counters, CPU load, disk space, but no need to change/write - essentially, SNMP but with the WMI interface), and ensuring that the PRTG_SERVICE account is NOT a member of Local Administrators on the server or Domain Admins?
PRTG and WMI Security
Votes:
1
Best Answer
Votes:
0
This should be possible, of course, although it is probably not too easy to achieve. Did you read the MSDN article http://msdn.microsoft.com/en-us/library/aa393266%28v=VS.85%29.aspx about this topic?
However, please bear in mind that setting up specific restrictions on DCOM and WMI might result in WMI sensors ceasing to function with very vague error messages and unpredictable and unsupportable phenomenons.
A good idea would be to test this limited account using our WMI tester, before setting it up in PRTG.
Kind regards,
- Volker
11 Replies
Votes:
0
Hello,
you can of course try this, and to our knowledge some customer seem to do so already. However some (or most) thing related to DCOM and WMI (in order to do it successfully) seem to require nearly full permissions of a Domain Admin.
Best Regards.
Votes:
0
I am/have been trying to do this. I'm trying to determine if there is an already known way to perform this task. It seems risky to have a domain admin level account login to multiple servers every 1-5 minutes for monitoring. How would one be able to audit this? If the PRTG account was compromized, it would be very hard to identify the intrusion through security logs, as the PRTG account would be shown as logging in potentially hundreds of times per day. It would be far more beneficial to have a restrictied rights account used for WMI read only, that could have limited/no other rights on the network.
Votes:
0
This should be possible, of course, although it is probably not too easy to achieve. Did you read the MSDN article http://msdn.microsoft.com/en-us/library/aa393266%28v=VS.85%29.aspx about this topic?
However, please bear in mind that setting up specific restrictions on DCOM and WMI might result in WMI sensors ceasing to function with very vague error messages and unpredictable and unsupportable phenomenons.
A good idea would be to test this limited account using our WMI tester, before setting it up in PRTG.
Kind regards,
- Volker
Votes:
0
Our company would also like to use limited users for monitoring wmi. I already tried by editing wmi and dcom but didn't work. Did someone already accomplished this?
Votes:
0
Some people have gotten it working with a non-domain account by following these steps. Number 3, in particular, is missing from a lot of similar lists: http://infrasightlabs.com/setting-wmi-access-ad-gpo
Votes:
6
Hey Folks,
This is a late reply to this topic, but I was having similar issues where I wanted the PRTG credentials to be able to work, but not have domain admin privileges. As this is the top topic in google when I searched for this problem initially I thought I would provide my solution is case anyone else comes across this post! What I found to work was to apply these to my PRTG credentialed user:
1. First of all, follow the instructions here: http://www.infrasightlabs.com/setting-wmi-access-ad-gpo With regard to firewall rules, I've had success in adding a Remote Service Management exception for both RPC-EPMAP and NP-In, but that may be because I'm working on a hardened system. Also, I've heard that the NetLogon exception helps too, but have not activated it in my case.
2. Using Restricted Groups in Group Policy, add the user to both the Distributed COM Users and Performance Monitor Users groups so that they are a part of those groups on all the local machines. (If using an AD group instead of a single user in Restricted Groups, you will have to manually add the user to the two aforementioned groups on the Domain Controller(s) as for some reason it doesn't like adding custom AD groups into the Builtin groups.)
I'm unsure about the need for the Performance Monitor User group addition above as I am only using WMI in PRTG. However, hopefully this should cover all bases so that you get a working system and then you can wind back settings as you see fit.
Hope this helps!
Votes:
0
Thank you for sharing your insights, Trevor. Regarding Performance Counters, it depends on the particular sensor. There are "hybrids" like Windows CPU Load Sensor that use Performance Counters and fall back to WMI if necessary. There is also a setting for those hybrids at device level (section "Windows Compatibility Options"), where you can restrict them to "WMI only".
Kind regards,
Erhard
Votes:
0
I still think this is not good enough. Security is difficult, but that is no reason not to use best practises.
The problem with your "solution" is that domain admin credentials are stored somewhere in PRTG. They should not be readable to anyone but...... as security get's more attention day by day, wouldn't it be great that even IF someone manages to retreive these credentials, he (or she) can only monitor. If this shit hit's the proverbial fan, wouldn't it be nice that you could tell the world, "We encourage our clients to use a restricted account, we help them implementing this. The only clients at risk are those using domain admin account.
I hope you reconsider
Votes:
0
Hello Leeuwendaal,
As far as PRTG is concerned passwords are not stored in plain text, they are encrpted, so in case someone would get a hold of your PRTG configuration file, it's not like all passwords are suddenly known to the attacker.
If we were aware of other ways to get it to work, we would tell you, we're not happy with that fact either, but please consider that this whole WMI/DCOM/RPC "black hole" is coming from Microsoft and it is what it is, it's not like we can somehow change the ways it works.
Kind regards,
Erhard
Votes:
0
We are evaluating PRTG for Windows monitoring and the fact that we should use a domain admin privilege is a no-go for us. Also the fact, that Microsoft is deprecating SNMP is very bad for the PRTG built in sensors. What im currently try is to create a restricted PowerShell SessionConfiguration (JEA) on the device to access with a non privileged account. Kind regards, Mario
Votes:
2
No, it's not up to PRTG to dictate what sort of an account you need to logging in with WMI. I too thought it was a deal breaker until I got it working on one of my networks which is super restricted. No Domain Admin needed at all for the service account. In fact, Domain Admin shouldn't even be on anything except your Domain Controllers.
Your JIA attempt may be a good option too. There is an immense amount of info on the internet for getting WMI remotely working.
Add comment