WMI and the WBEMTEST
I’ll try and keep this post short, as I have many things to catch up on, and this just happened to be one of those things I haven’t done in a while and had to do today for some newer servers that have been configured.
Now since I hadn’t blogged about this myself I went out to the interests to give me a good reminder on how to accomplish this. My first hit was, Sysops… and I usually really like this site…. well till i read this…
“Access denied should be self-explanatory. The credentials you use must have administrator rights.”
Ughhhhh I’m sorry what did you just say? No I don’t think so, WMI maybe, by default, restricted, but it doesn’t require such drastic permissions to utilize.
My second find was a lot nicer, in particular telling you how to manage those permissions, without ahem need administrator access lol.
So lets follow along shall we! so much for short..
First order of busy-nas is creating a user:
Of course WMI being Windows Management Interface, means I’m making obviously a windows domain user. Nothing special, especially no admin.. 😛
Again, nothing special here. Alright now I need two servers, well I guess in this case the server being monitored is sort of like a client… ugh anyway…
I guess fo r now I’ll just login to my exchange server and wmi query another server to test out first off… mhmm all I have besides that are core servers, oh boy ok… I think I’m going to need to spin up a new testing server one second…
OK all basic settings…
remove floppy boot into EUFI:
Boot system… attach disc from local host…
lets find us some windows erver 2016…. bug CD-ROM stuck “connecting”…
Close vSphere, reopen console, try again…
always loved this trick over uploading a ISO to a datastore….
Ahh modern Windows still giving off that great nostalgic feel.. 😀
yada yada, setup, vmware tools, and join domain, you get the jist of it.
Ping and the Firewall
First order of Business Ping and the Firewall!
Ahh yes connectivity verified (I knew it was good cause I joined the system to the domain, but I like ping… just nothing like a good ICMP) good thing that m is not a u….
Anyway time to run WBEMTEST, bet the first attempt fails cause the firewall again…. hour glass… and (not responding) yeah…. sounds like a stupid firewall…
What?! no way RPC error… lol I totally saw this coming cause again a default server installation doesn’t allow these connections through the firewall by default.
This is a bit old, but lets see if it still works…
Amazing it worked… but yes this was just to verify connectivity through the firewall… so…
WBEMTEST Testing WMI with Least Privileges
OK now that we verified connectivity to the wmi stack with wbemtest using our admin account, lets do it again as a normal domain user. Just to validate these credentials were OK as a standard user i logged into a normal workstation with it, if you want to protect this even further you’d use GPOs to disallow this account local logon. Anyway…
What?! Access denied… lol again expected.. now instead of granting this account admin access, which is overkill, lets grant it the basic enable and remote access on the WMI object… so back on the server we want to be monitored via WMI…
Hope that was easy enough to follow without even saying anything.. anyway lets try that connection again…
Try 2, Scale-able
Mhmmm access still denied… lets see here
This is how I normally do it for a monitoring account anyway cause it usually needs more permissions when mointoring a server so lets try it that way… revert the direct permissions… and grant performance group access…
Now lets add wmi reader account to the dcom groujps and the performance monitor group and reboot the server…
Server rebooting, back up, and lets test that connection again on wbemtest!
and….
Bazzaaaaaa! An account thats not a admin anywhere with permissions needed to monitor your server with WMI! Use these accounts on software such as PRTG, Splunk, Zenoss, etc etc.
Hope everyone enjoyed this tutorial on WMI configuration and testing. 😀