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
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.
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.
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.
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:
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.