0

We have created a small windows program that downloads files from internet websites. It works fines on most PCs. In one specific customer situation, the program fails. It is able to download files if the program is run as a regular user or administrator but not as Local System. The program is part of a windows service and therefore has to run as local System. The problematic PC is part of a domain. I have read that Local System is an anonymous account and does not have network access privileges. Could that be the problem even when accessing files on the internet?

user2442193
  • 1
  • 2
  • 1
    If the account has been restricted from using internet services,it can't download files at any cost unless it is granted the permission! – Am_I_Helpful Sep 06 '14 at 04:00
  • Thanks. How can we do that? – user2442193 Sep 06 '14 at 04:07
  • By changing the permissions for local account and granting it network services permission! – Am_I_Helpful Sep 06 '14 at 04:08
  • The local system account can access the network in the same way the network service account can, i.e., it can authenticate to other machines in the domain using the computer's account. That doesn't necessarily mean it has access to the internet. Internet access is determined not by Windows but by the network administrators - how you would give the program access depends entirely on how the network is configured, there is no single standard. For example, you might have to use a proxy server. – Harry Johnston Sep 06 '14 at 04:50
  • Your comment is right on. What is puzzling is that we have two PCs physically next to each other and in the same OU - One is able to access the internet and the other is not. If the network did not give internet access to anonymous users (local system), I would expect both PCs to be blocked from the internet. No? Is internet access granted to specific computers? – user2442193 Sep 06 '14 at 15:30
  • In the simplest scenarios, direct internet access is granted or denied based only on the IP address of the computer and/or the destination URL. If your software opens a TCP connection explicitly (e.g., using the `socket` and `connect` functions) then that's the only access control method that would work. If your software uses Windows HTTP support (e.g., using WinHTTP, WinINet, or the .NET equivalents) then access control could alternatively be based on the user account, or in this case the computer account. It might be that one computer account has been given access and the other hasn't. – Harry Johnston Sep 06 '14 at 21:05
  • The bottom line is that there are too many possible configurations for guesswork to be any use. You need to be talking to your customer's network administrators to find out what sort of access control they are using. – Harry Johnston Sep 06 '14 at 21:07

2 Answers2

0

Note that this is supposed to be a comment, not an answer, I just can't comment yet.
To get more insight on the problem, one could create a cmd with the same rights as your service. By default, that would be Local System. I suppose it'd work with PowerShell as well, but I'm unclear about the implications.

sc create debugcmd binpath= "cmd /K start" type= own type= interact
sc start debugcmd

The last command will give you an error message, similar to The service did not respond to the start or control request in a timely fashion. which can be safely ignored.
This snippet will create a shell in session 0 (see Session 0 isolation), but since we declared the service interactive, you can access it. From there on you can start your diagnosis.

Word of caution here: Each and every call you make in that cmd will have Local System permissions. When you start another application, or in other ways invoke a child process, it'll inherit those permissions.

Remember to remove the service when you're done, as it poses a substantial security risk:

sc delete debugcmd
Niklas
  • 3
  • 2
  • Thanks for the comment. I have been using psexec -i -s cmd.exe which I believe does creates a cmd running as local system. http://stackoverflow.com/questions/77528/how-do-you-run-cmd-exe-under-the-local-system-account – user2442193 Sep 06 '14 at 14:58
  • Declaring a service interactive doesn't automatically exempt it from session 0 isolation. There is a backwards compatibility feature that may allow it to work as desired, but it is off by default in Windows 7; to enable it, start the Interactive Services Detection service. This feature might not be present in later versions of Windows. At any rate, `psexec` provides a simpler solution. – Harry Johnston Sep 06 '14 at 20:55
0

This is a MS bug. I have implemented the solution recommended by MSDN and it works great. This is the original code:

   var filePath = "https://someurlhere";
   var xsl = new ActiveXObject("Msxml2.DOMDocument.3.0");
   xsl.async = false;
   xsl.validateOnParse = false;
   xsl.load(filePath);

The load method may fail if the DOMDocument loads an XML file over HTTP when MSXML is operating in a server-side or client-side multi-core environment.

The fix is to add the statement below under the xsl.async = false;

   xsl.setProperty("ServerHTTPRequest", true);

For more details, you can go here: http://support.microsoft.com/kb/281142

Thanks to everyone and Remy Lebeau in particular for their help.

user2442193
  • 1
  • 2