1

I've done some extensive research on this and I've tried every suggestion I have seen. I am troubleshooting an application that runs a "scheduler" service to periodically export *.txt files to a network share. I've changed the service to launch as a network service, and gave the network service account full NTFS access and share access. Both machines are on the same domain, and I am using the UNC path as input for the export function. I've also given the network service account some extra permissions under the Local Security Policy such as "Take ownership of files".

The application is running on Windows Server 2008 R2 and exporting to a box also running Server 2008 R2. These permissions I mentioned above were mirrored on both machines. Does anyone have any extra suggestions I might want to try?

1
  • I know this doesn't answer your question, so I won't put it as an answer, but I personally think you should do this using a custom service account anyway. Create a domain user with a long complex password and give it the required rights. It's far more auditable and controllable
    – Dan
    Jan 7, 2012 at 18:32

2 Answers 2

2

If I understand what you've done correctly, on the network share you've granted write access to NT AUTHORITY\NETWORK SERVICE. This is a local account only and granting this user write access on a folder/share will not allow remote computers to write to the folder.

When a service running as NETWORK SERVICE goes across the network, the source username is the computers Active Directory object (i.e SOURCECOMPUTERNAME$). To allow your source computer to write to a share on the destination machine, you need to grant write access to SOURCECOMPUTERNAME$ (the computer object). The other permissions you granted are superfluous and should be removed.

1

NETWORK SERVICE is a locally defined user account, which is not recognized as a valid when coming from a remote computer thanks to SID filtering. As a result of this, while you can define the permissions on shares and such, that ACL is only valid on the local computer, which is the only place where NETWORK SERVICE is trusted. All remote connections from someone claiming to be NETWORK SERVICE are going to be denied (which is what you're seeing).

You'll need to do what Dan suggested and create and use a domain user account for this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .