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