Remote Monitoring Account Hints

The most common problem when trying to monitor remote server resources (disks, PerfMon counters, running services, Event Log, etc.) is getting the remote server to allow access to the resources. Windows security won't simply fulfill any requested access issued by any random machine on the network (imagine the chaos!). A token representing the user making the request is sent along with the request. The remote server checks the token against an access control list which protects the target resource and determines whether to allow access or not.

Background

So which user is making the request?

Go to the Services control panel applet (under Administrative Tools), and open the properties for any service. You will see a Log On tab. This tab controls which user account is used to launch the service. All services run as some user. A special user account named Local System is often used which has full access to the local machine, but no access outside the machine. In addition, you can right-click on a computer in the Console and select "Set Login Credentials" to set computer-specific credentials to use when monitoring that computer.

If no computer-specific credentials are entered, then all requests are made as the user which is listed on the Log On tab (also shown in Settings). In the examples below, we assume that there are no computer-specific credentials.

Consider the scenario where machine "OPS" is running a service (like the Power Admin monitoring service) and wants to look at the Event Log on machine "SERVER". If the service is running as Local System, the Event Log request would contain a token referring to user "OPS\Local System". The problem is, machine SERVER doesn't know anything about "OPS\Local System". For all it knows, that account might be a simple guest account. Access will be denied.

What solutions exist?
There are two basic ways to get around this problem, and they both involve getting the request on OPS to run as a user which SERVER will recognize.

Solution 1

This solution requires using domain accounts. Imagine that the machines OPS and SERVER are both in a domain named DOMAIN. The domain could then have a user created named "Inspect" for example. The service on OPS should then have it's Log On user set to DOMAIN\Inspect. On SERVER, you would grant access to any resources that should be monitored to user DOMAIN\Inspect (or as a shortcut, make DOMAIN\Inspect part of the local Administrators group). When Server Monitor tries to monitor the Event Log on SERVER for example, a token representing DOMAIN\Inspect will be passed with the request. SERVER will recognize the token and allow access according to the rights granted to DOMAIN\Inspect.

Solution 2

If the main monitoring service is NOT running as Local System (or in other words, as a domain account or a local account), then you can specify server-specific credentials to be used. This allows you to specify a specific account (a local account on the target server, or a domain account to use when accessing the server). In the example below, the SERVER is accessed using a local account named SvcCheck. SvcCheck's credentials were entered for SERVER by right-clicking on SERVER and choosing Type & Credentials > Set Windows Credentials.

Solution 3

This solution can be used if you want the monitoring service to use a local account, and you want that same account to automatically be used when accessing remote servers, without specifying a specific username and password for each remote server.

The solution is to use synchronized username and passwords on the two machines. You can create a user account named "Inspect" on OPS with password "baseball". Then go to SERVER and create a user account named "Inspect" with password "baseball". When user "Inspect" runs the service on OPS, and sends a request to SERVER, the token turns out to contain not just the username, but a hashed form of the password as well. When SERVER receives the request, it checks its local user database and finds a matching user, hashes the local password and finds that they match. It then allows the request as though it had originated from the local user "Inspect". Any access to resources granted to the local user "Inspect" on SERVER can be accessed remotely from the similar user "Inspect" on machine OPS. The downside to this solution is it requires all monitored machines to have synchronized usernames and passwords. This doesn't work for "Local System" because Local System is a special operating system account tied to the local computer (and you can't set Local System's password).

NOTE: Starting with Windows XP a security policy was introduced that causes incoming local credentials (from a remote host) to be assigned Guest user rights. That won't help. You'll need to set the policy back to Classic mode. Microsoft documents this here: [1]. This can be corrected by switching to Classic file sharing, or by going to Administrative Tools > Local Security Policy > Security Settings > Local Policies > Security Options. Look for "Network Access:Sharing and Security model for local accounts" and set it to "Classic".

---

IMPORTANT NOTE: The solutions above discuss changing which user the monitoring service runs as. You can also set the login credentials on each individual server from within the Console. Right click the server and you'll see the Set Login Credentials option. You can choose to communicate with the server as the user running the service, or pick a specific username/password for that server.

Is there any other way?
There is an additional alternative: Install the monitoring product on the remote server. It can then run as Local System and look just at the server itself. Power Admin monitoring products install quickly, and the Easy Configuration feature makes it simple to copy a monitoring configuration from one machine to another.