none
Can you connect to WMI remotely using a local user account?

    Question

  • Greetings!

    I'm trying to use SolarWinds Network Performance Monitor on my network and I'm running into an issue setting up the monitors themselves. We have about twenty or so standalone virtual servers that reside in a DMZ and we want to use NPM to monitor these servers. The monitors can use SNMP, ICMP and WMI, but WMI doesn't seem to work on these standalone servers.

    I've been running WMI Tester and I receive the x80070005, access is denied error when I try to connect. I've checked the permissions in DCOM and the local account has the proper rights, but everything I'm reading keeps referencing using Domain accounts.

    So my question is, can I use WMI remotely with a local account? To clarify, I'm using WMI from one server (Server 2012, joined to a Domain) to remotely monitor a standalone (non-Domain joined) server (Server 2003) using local accounts on the 2003 server. Is this even possible?


    Brian Brehart Network Administrator SurePayroll, Inc.

    Thursday, January 2, 2014 3:50 PM

Answers

  • I'm trying to use SolarWinds Network Performance Monitor

    Definitely posting in the Network Performance Monitor on SolarWinds' Thwack community would be helpful also. I see that you have, and that much of this information I'm posting here has already been explored there.

    WMI doesn't seem to work on these standalone servers.

    WMI is blocked, by default, on all Windows Server systems by the Windows Firewall. If the Windows Firewall is enabled, you'll need to enable the three "Windows Management Instrumentation" rules on the servers. But more importantly, since these machines are in the DMZ, it's quite probable that your corporate firewall (LAN<>DMZ) is blocking this functionality. In order to use WMI you need to have access for the RPC Endpoint Mapper (135) as well as WMI (variable port range, by default 1024-5000), and in most cases that's not going to fly for traffic going inbound to the DMZ. Another option is to deploy a Remote Poller in the DMZ, which will keep all RPC/WMI traffic local to the DMZ LAN, and then you just need a few ports open from the RP to the NPM server to allow the RP to push that data back to the NPM server.

    I've been running WMI Tester and I receive the x80070005, access is denied error when I try to connect.

    In addition to port access, the account being used to authenticate the WMI session must have ADMINISTRATOR privileges on the target system. Since you do not have domain membership for these systems, you'll need to either use the local Administrator account, or (recommended) create an alternate local account and make it a member of the local Administrators group. (Hint: It's also helpful to configure that local account on each system with the same complex passphrase, so that you only need to define ONE stored credential in the NPM server for all of your DMZ systems.)

    In addition to the account itself, there are also Local Security Policy settings that can interfere with the ability to authenticate remote accounts for WMI. In Security Settings \ Local Policies \ Security Options check these settings.

    • Network access: Do not allow storage of passwords and credentails for network authentication must be DISABLED.
    • Network access: Sharing and security model for local accounts must be set to CLASSIC.

    Typically we see these settings configured via Group Policy, but since these are standalone non-domain member systems, and virtual machines, it's possible these settings were 'cloned'.

    I've checked the permissions in DCOM and the local account has the proper rights, but everything I'm reading keeps referencing using Domain accounts.

    There is no requirement to use a domain account to access WMI. I'd be interested in what you're reading that says such things.

    So my question is, can I use WMI remotely with a local account?

    Absolutely!

    To clarify, I'm using WMI from one server (Server 2012, joined to a Domain) to remotely monitor a standalone (non-Domain joined) server (Server 2003) using local accounts on the 2003 server. Is this even possible?

    Most certainly.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, January 2, 2014 10:41 PM

All replies

  • I'm trying to use SolarWinds Network Performance Monitor

    Definitely posting in the Network Performance Monitor on SolarWinds' Thwack community would be helpful also. I see that you have, and that much of this information I'm posting here has already been explored there.

    WMI doesn't seem to work on these standalone servers.

    WMI is blocked, by default, on all Windows Server systems by the Windows Firewall. If the Windows Firewall is enabled, you'll need to enable the three "Windows Management Instrumentation" rules on the servers. But more importantly, since these machines are in the DMZ, it's quite probable that your corporate firewall (LAN<>DMZ) is blocking this functionality. In order to use WMI you need to have access for the RPC Endpoint Mapper (135) as well as WMI (variable port range, by default 1024-5000), and in most cases that's not going to fly for traffic going inbound to the DMZ. Another option is to deploy a Remote Poller in the DMZ, which will keep all RPC/WMI traffic local to the DMZ LAN, and then you just need a few ports open from the RP to the NPM server to allow the RP to push that data back to the NPM server.

    I've been running WMI Tester and I receive the x80070005, access is denied error when I try to connect.

    In addition to port access, the account being used to authenticate the WMI session must have ADMINISTRATOR privileges on the target system. Since you do not have domain membership for these systems, you'll need to either use the local Administrator account, or (recommended) create an alternate local account and make it a member of the local Administrators group. (Hint: It's also helpful to configure that local account on each system with the same complex passphrase, so that you only need to define ONE stored credential in the NPM server for all of your DMZ systems.)

    In addition to the account itself, there are also Local Security Policy settings that can interfere with the ability to authenticate remote accounts for WMI. In Security Settings \ Local Policies \ Security Options check these settings.

    • Network access: Do not allow storage of passwords and credentails for network authentication must be DISABLED.
    • Network access: Sharing and security model for local accounts must be set to CLASSIC.

    Typically we see these settings configured via Group Policy, but since these are standalone non-domain member systems, and virtual machines, it's possible these settings were 'cloned'.

    I've checked the permissions in DCOM and the local account has the proper rights, but everything I'm reading keeps referencing using Domain accounts.

    There is no requirement to use a domain account to access WMI. I'd be interested in what you're reading that says such things.

    So my question is, can I use WMI remotely with a local account?

    Absolutely!

    To clarify, I'm using WMI from one server (Server 2012, joined to a Domain) to remotely monitor a standalone (non-Domain joined) server (Server 2003) using local accounts on the 2003 server. Is this even possible?

    Most certainly.


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Thursday, January 2, 2014 10:41 PM
  • All of these things were the issue. Thanks for all your help!

    Brian Brehart Network Administrator SurePayroll, Inc.

    Wednesday, January 22, 2014 3:08 PM