Problem when running Windows Service in Local System account

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have a problem with our OnlineBackupService.exe. This is a Windows Service
which is built in .Net 1.1 and basically grabs files from the file system and
will try to upload them using WebServices.

The service is installed by default using LocalSystem account. The exact
problem is that sometimes this service is not allowed to resolve the target
webservice. This results in the following exception:

Could not resolve remote DNS or hostname.

It seems in some cases that the LocalSystem account can not use
internet-based webservices, but not always. I would like to know:
1. How I can make sure that the LocalSystem account can access a webservice
2. If there is an alternative approach to this problem, in which I
accomplish to be able to access the complete file system and upload this to a
webservice.

Thanks ahead,

rvangeldrop
 
* rvangeldrop wrote, On 30-7-2007 11:06:
Hello,

I have a problem with our OnlineBackupService.exe. This is a Windows Service
which is built in .Net 1.1 and basically grabs files from the file system and
will try to upload them using WebServices.

The service is installed by default using LocalSystem account. The exact
problem is that sometimes this service is not allowed to resolve the target
webservice. This results in the following exception:

Could not resolve remote DNS or hostname.

It seems in some cases that the LocalSystem account can not use
internet-based webservices, but not always. I would like to know:
1. How I can make sure that the LocalSystem account can access a webservice
2. If there is an alternative approach to this problem, in which I
accomplish to be able to access the complete file system and upload this to a
webservice.
Click to expand...

This almost definitely not an issue with user rights. The fact that it
cannot find or resolve the hostname for the webservice indicates a
network/infrastructure problem. It can be that the connection is down, a
firewall is playing tricks or the DNS server is not responding (or
cannot resolve the hostname because it cannot reach the DNS server that
is hosting the domain name).

You could try if the problem goes away if you connect to the webservice
on its IP address instead of it's fqn.

There is another possible cause: When the system tries to leave too many
connections half-open, windows will temporarily deny new outbound
connections. This will result in an event in the eventlog with Event ID
4226. Though this is a long shot.

Jesse
 
Hello Jesse,

If it is not a matter of rights and security, how would you explain the
following:

- If I change the Windows Service the run as a local administrator
everything works fine
-If I change back to let the Windows Service run as LocalSystem the problem
reappears

Somehow the local administrator can resolve a hostname which the LocalSystem
can not?
 
* rvangeldrop wrote, On 30-7-2007 12:10:
Hello Jesse,

If it is not a matter of rights and security, how would you explain the
following:
Click to expand...

The keyword is in ...sometimes... in your original post. If it was
security the service would *never* resolve the hostname. But it most of
the times does, indicating a different cause. Can you reproduce the
error on other systems as well? Have you tried running under a different
user than LocalSystem (which is about the highest there is). Have you
tried with Anti-Virus disabled or if there is an application firewall,
try disabling that. It could be that some worm prevention could mistake
your service for a worm. (I've seen McAfee do this several times before).

Jesse
 
Hello Jesse,

Following up on your mail:
sometimes: means 'on some systems'. The behaviour on a system that is
showing this problem is very consistent. It will never work when running
OnlineBackupService.exe as LocalSystem. Also, changing this to a local
Administrator always resolved the problem.

Your remark about a firewall or anti-virus engine blocking access might be
plausible too, but how does this software distinct its behaviour on the
user-context processes are running in?

I was also thinking of other causes:
- Local security settings are overruled by tighter domain security settings?
- Some LocalSystem profiles miss a certain flag allowing them to resolve
domain names?

Kind regards,

rvangeldrop
 
* rvangeldrop wrote, On 30-7-2007 14:20:
Hello Jesse,

Following up on your mail:
sometimes: means 'on some systems'. The behaviour on a system that is
showing this problem is very consistent. It will never work when running
OnlineBackupService.exe as LocalSystem. Also, changing this to a local
Administrator always resolved the problem.
Click to expand...

Ahh ok ,that is more clear. What's the difference between those systems
is what you'd be looking for.

A clear view on the different user accounts and their security privs can
be located here:

Your remark about a firewall or anti-virus engine blocking access might be
plausible too, but how does this software distinct its behaviour on the
user-context processes are running in?
Click to expand...

Some do.
 
* rvangeldrop wrote, On 30-7-2007 14:20:
Hello Jesse,

Following up on your mail:
sometimes: means 'on some systems'. The behaviour on a system that is
showing this problem is very consistent. It will never work when running
OnlineBackupService.exe as LocalSystem. Also, changing this to a local
Administrator always resolved the problem.
Click to expand...

have a look at:
http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/sspgch02.mspx

it has a topic on the differences ion privs between the different local
account types.

Are these other systems under your control? Part of a domain? Do they
have a security policy enforced, firewalls installed, do they use a
proxy server (in which case you need to specify the proxy server in your
settings), do they have advanced anti-virus solutions installed?
Your remark about a firewall or anti-virus engine blocking access might be
plausible too, but how does this software distinct its behaviour on the
user-context processes are running in?
Click to expand...

Some do.
I was also thinking of other causes:
- Local security settings are overruled by tighter domain security settings?
- Some LocalSystem profiles miss a certain flag allowing them to resolve
domain names?
Click to expand...


One thing I'd check is if the user has a proxy server configured for the
Admin account. This will be picked up automatically for your application
if it's running as admin. But you'd have to configure the WebClient in
the Framework in code or in the application's config file/registry in
order to let the LocalSystem account make use of the proxy server. This
might be the most logical issue causing your problems.

Jesse
 
Hi Jesse,

I think you got me on the right track, because I reviewed the total
exception once more and found this:
nner exception:
The underlying connection was closed: Unable to connect to the remote server.
at System.Net.HttpWebRequest.CheckFinalStatus()
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)

This is indeed due to hte proxy-server not being configured for local
system. One of the machines that was showing the behaviour is one of our
office test servers, which is behind an ISA using firewall client.

This will bring me to a new challenge: preferably I want the user not to
enter his proxy settings. Can I load them from the Admin-account when the
application is installed and then store them?
 
* rvangeldrop wrote, On 31-7-2007 9:10:
Hi Jesse,

I think you got me on the right track, because I reviewed the total
exception once more and found this:
nner exception:
The underlying connection was closed: Unable to connect to the remote server.
at System.Net.HttpWebRequest.CheckFinalStatus()
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)

This is indeed due to hte proxy-server not being configured for local
system. One of the machines that was showing the behaviour is one of our
office test servers, which is behind an ISA using firewall client.

This will bring me to a new challenge: preferably I want the user not to
enter his proxy settings. Can I load them from the Admin-account when the
application is installed and then store them?
Click to expand...

Officially. no as far as I can tell you cannot. You could ofcourse go
into the registry for the users account (but which one to take) and
fetch the settings from there, but there is a big chance you need more
than the portnumber and host of the proxy. ISA usually requires
authentication as well, so you'll also need to mimic the user/pass of
the admin account.

As far as I can see you have two real options here: Either let them
configure the ISA server to allow the computer account in the domain
(LocalSystem resolves to Domainname\computername$ under activedirectory)
to access the proxy. Or you can configure the proxy in the app.config.

Jesse
 
Hi Jesse,

Could the problem be also so simple that the LocalSystem does not know the
DNS server and gateway?

Kind regards,

rvangeldrop
 
Back
Top