WMI Polling and Account access

 By default, remote WMI access requires admin privileges on the target machine.  You can change the permissions to allow non-admin users the ability to query WMI
 

From msdn2.microsoft.com/.../aa393266(VS.85).aspx:

“Allowing Users Access to a Specific WMI Namespace

You can allow or disallow users access to a specific WMI namespace by setting the "Remote Enable" permission in the WMI Control for a namespace. If a user tries to connect to a namespace they are not allowed access to, they will receive error 0x80041003. By default, this permission is enabled only for administrators. An administrator can enable remote access to specific WMI namespaces for a nonadministrator user.”

Understood...but what "user" are people using in their WMI credentials? Security doesn't like us to create users with Admin privileges that are not 'humans'. There is also the issues of password expirations every X number of days for nonadminstrator users that will have to be dealt with.

I also am interested in how you guys are physically configuring the remote computer for WMI access? In other words, are you logging into each server seperately and configuring WMI persmissions on a namespace for access my a remote user (the remote user being Orion APM?).

 Is there a Best Practices paper or thread out there?

This is all new to me. Any enlightenment would help. Thanks!

 I spent the last two days trying to sort out the DCOM and WMI permissions for a non-admin user. Today I gave it up and convinced our admin to give me a service account and set it up as an administrator on boxes that we'll be pulling WMI data from. It's not the most elegant solution, but it did start working immediately.

We set up Group Policy so our service account does not have actual logon rights to any machine. That at least mitigates some of the risk. Maybe you can reach a compromise with your security team.

If anyone finds the way to make a non-admin account work for this I'd be very interested to see it.

i am in pretty much the same boat here.  seperate server team and seperate security team.  since we fall under PCI, and the servers i am targeting are the most sensitive, i need to try and get this working as well.  my server admin gave me this link but so far it isnt working with my proxy ping script.  i get the error Microsoft VBScript runtime error: Permission denied: 'GetObject' .  on my test server i added the user to manage the entire wmi namespace with subs and the same user is a local admin on the orion server.

any help would be great.  i'd think this would be a big deal as security is a big concern.

http://www.microsoft.com/technet/scriptcenter/resources/wmifaq.mspx#EABAC

quick update.  my server admin told me to add the user cred i am using to the Distributed Com Users local group.  i did this and the script runs fine from the orion/apm command line logged in as that user

still get the same error on the apm using the exact same credentials that worked above.  any ideas?

if anyone is interested - got it.  had to set credentials with fqdn and it works great.

non admin account,  proxy ping

I just got this going in our environment. I wanted to use a domain account as the credentials for WMI monitors on all servers in our domain. Here's what I did (I verified this works on Windows 2003 and 2008 servers):

1.) Open WMI Control Properties (Computer Managament|Services and Applications|WMI Control)

2.) In the security tab, select the Root namespace, and press the Security button.

3.) Click the Advanced button in the Security for Root window.

4.) In the Advanced Security Settings for Root window, click the Add button.

5.) In the Select User, Computer, or Group dialog, enter the name of the account you'd like to use and click the OK button when done.

6.) In the Permission Entry for Root window, ensure that Apply to: This namespace and subnamespaces is selected, and under Permissions allow, Execute Methods, Enable Account, and Remote Enable. Click the OK button when complete.

7.) Click OK to close all windows.

Half way there!

8.) Add your account to the following groups: Distributed COM Users, and Performance Monitor Users.

9.) Test your WMI monitor / query from within Orion. I had to use credentials of the form DOMAIN\accountname, as opposed to accountname@domain for this to work.

Congratulations. WMI monitors should work without using an Administrator account.

Hope this helps!

I've tried the configuration approach described here and it does not appear to work in my environment.

The Performance Counter Monitor, Process Monitor-SNMP and Process Monitor-WMI all appear to work when Browsing for Components although processes are available by SNMP anyway so I'm not sure what access the Process Monitor-WMI is actually using.

The Windows Service Monitor and WMI Monitor do not work when Browsing for Components with the Windows Service Monitor giving an "Error - Generic Failure" and the WMI Monitor just providing no results.

Our Security people do not want to provide global Admin rights by use of Domain Admins and we have many hundreds of servers where WMI access is necessary so I do not really want to do anything server by server. Preference would be for reduced level of access to WMI and the server.

Does anyone have any more ideas on the WMI Access side of things?

Tim didd you get this resolved ?

Thanks for the details. Easy to follow but still not working on my system. I even granted the account domain admins and Exchange View-Only Administrators.

I granted more exchange permissions and tested again.

Looking more at the errors the issue is the Windows PowerShell Monitor. Will search more along those lines. For others having a the same issue I have included the error details.

Status of Database Copies

Output:      ==============================================

Message: ERROR: Please check target server and credentials (should be domain\user). [IPADDRESS] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic..Exception

#Additional error details:

CategoryInfo:  OpenError: (:) [], PSRemotingTransportException

ErrorDetails:  [IP ADDRESS] Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.

FullyQualifiedErrorId:  PSSessionStateBroken

InvocationInfo:  System.Management.Automation.InvocationInfo

#End error details

DAG Health 1

Output:      ==============================================

# Going to try to open existing Mutex...

# Failed to open an existing Mutex. Error details: 

System.Management.Automation.MethodInvocationException

Exception calling "OpenExisting" with "1" argument(s): "No handle of the given name exists."

# Assuming that Mutex doesn't exist, going to create new one...

# Created new Mutex...

# We've opened existed Mutex, so let's wait to grab it...

# Going to execute Test-ReplicationHealth cmd-let. Attempt: 1.

# Failed to execute Test-ReplicationHealth. Error details: 

System.Management.Automation.ParameterBindingException

Missing an argument for parameter 'Credential'. Specify a parameter of type 'System.Management.Automation.PSCredential' and try again.

# Going to execute Test-ReplicationHealth cmd-let. Attempt: 2.

# Failed to execute Test-ReplicationHealth. Error details: 

System.Management.Automation.ParameterBindingException

Missing an argument for parameter 'Credential'. Specify a parameter of type 'System.Management.Automation.PSCredential' and try again.

# Going to execute Test-ReplicationHealth cmd-let. Attempt: 3.

# Failed to execute Test-ReplicationHealth. Error details: 

System.Management.Automation.ParameterBindingException

Missing an argument for parameter 'Credential'. Specify a parameter of type 'System.Management.Automation.PSCredential' and try again.

# Going to execute Test-ReplicationHealth cmd-let. Attempt: 4.

# Failed to execute Test-ReplicationHealth. Error details: 

System.Management.Automation.ParameterBindingException

Missing an argument for parameter 'Credential'. Specify a parameter of type 'System.Management.Automation.PSCredential' and try again.

# Going to execute Test-ReplicationHealth cmd-let. Attempt: 5.

# Failed to execute Test-ReplicationHealth. Error details: 

System.Management.Automation.ParameterBindingException

Missing an argument for parameter 'Credential'. Specify a parameter of type 'System.Management.Automation.PSCredential' and try again.

# Cleanup section - going to release our Mutex...

Message: Can't execute Test-ReplicationHealth snap-in within specified attempts count. Spent 5 attempts.

DAG Health 2