问题
I have an executable that is started by a windows service, this program will be run on a customers machine and will need to connect to a remote share to perform a particular task. This share is specified by the customer via a UI, so we do not know this in advance meaning it can't be "hard-coded", or the share mapped in advance.
Previously we required the customer to log on to their machine and run the executable on log-on , but we have always wanted to allow our program to run within a service and not require a log-in, primarily to make it easier for the customer and prevent any accidental log-outs shutting down our software. So this also means we don't know what local user accounts exist on a customers machine, so we have to start the service using the local system account.
We now have, as mentioned above, a wrapper service to start the executable and perform various tasks. This appears to work fine in most cases and accesses the underlying network fine - our software's purpose mainly involves capturing packets etc.
However, when the software tries to connect to a windows share (UNC name) it cannot connect. Whereas if the executable was started manually it connects fine.
The suggestions I have generally seen to resolve these kind of issues appear to all say use a user account as the system account cannot access network shares, but in our case this isn't possible. Is there any other way we could get this to work?
Edit: I forgot to mention that this application could (and most commonly will be) run on Win2K not XP, and I think I'm right in saying that the Local Network account is not available before XP?
回答1:
If you can change your windows service so that it runs under the Network Service account, then your executable will be able to access network shares (this is one reason why the Network Service account was created).
The Local System and Local Service accounts do not have any network credentials, and thus can't be authenticated on the network. This is by design.
Edit: IIRC, the Network Service account was introduced in Server 2003, and added to one of the XP service packs.
If you cannot rely on the Network Service account being available, then you might consider creating a dedicated domain account, storing the account's credentials somewhere, reading them from inside your service, then loging in and impersonating that user prior to accessing the network share. Alternatively, the windows service could run as the dedicated account directly, in which case it would require the "logon as a service" privilege.
回答2:
When you have a service that runs under NT AUTHORITY\LOCALSYSTEM (which is the name of the service account), it appears as the DOMAINNAME\COMPUTERNAME$ (note the $ sign) account to the rest of the network. That is, it appears as the COMPUTER's account in Active directory. Just grant your file and share permissions to DOMAINNAME\COMPUTERNAME$ and you should be good.
回答3:
Why can't you use another account? There is a network service account built into Windows, specifically for services that need network access.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not disabled, a user can replace that exe with (for example) cmd.exe. The next time the service tries to start your exe, voilà: A command shell with system rights!
来源：https://stackoverflow.com/questions/249928/executable-started-by-a-windows-service-using-the-local-system-account-cannot-ac