Security permissions for remote shared folders

1. In a workgroup there is no central repository of users, so you have to manually duplicate the accounts on each workstation (or server in your case)
2. In a workgroup, LocalSystem accesses the network as Anonymous.

You should have the service run as a different account. Create an account with the same name/password on both machines, grant share permissions to the Service account and set the service to run as that rather than LocalSystem: start > run : services.msc right click the service and go to properties. Change the logon to the user account you created.

If that doesn't work, you can configure the receiving folder to accept writes from Anonymous, but not read/execute. that would make the folder work like a drop box.

To answer your question about "security" and "share" permissions, no they are not the same. Security is NTFS permissions ... that's permission to access the file system. Share permissions is permission to access that resource across the network. The most restrictive of the two wins, so if you set Everyone to Full Control in security settings but Everyone to Read Only in share, you will get Full Control if you access the resource locally, but only read access if you try to use it from another computer.

The Local System account has no permission to access network resources. You will need to either have it run a process which can make the connection using suitable credentials or run the service under another account, which will still need to use suitable credentials to access the remote resource.

You are likely on a domain. I would recommend using domain accounts if you are. Pass-through authentication is possible, as mentioned already, but it's meant for a workgroup only, or if you're really restricted in what your domain admin will give you (although that suggests that you're doing something that your network admin won't support).

Here's how you can check if you're on a domain.

• Click Start. Right-click My Computer and click Properties
• Click the Computer Name tab
• You can kind of tell from this screen, but click Change
• See if Member of is Domain or Workgroup.

If it's Workgroup, then use the pass-through authentication mentioned already. (exact same username/password on both machines)

However, if it's in a domain, what I recommend is that you ask your domain admin for a service account that you can use here. Don't use your own account since password changes and such will cause your service to break.

In the Add dialog box, there is a Locations... button. Click on that and make sure that your domain is selected (if you're going down the domain path). That will give you access to domain users.

In either case (Workgroup or Domain), update your service account on A that you're using so that it uses that account, rather than using Local System.

Grant the new account only what permissions it needs to the Share and to the Security tab (NTFS permissions). I wouldn't grant Everyone access to either the Share or NTFS, since that opens up your computer to anyone on the domain.

Note: sometimes it's fine to test using the Everyone group to remove permissions as an issue during testing, but be sure to tighten the final configuration. That should be temporary only.

Update: Based on discussion in the comments, here's an example of a TeamCity config that's based on a working config of mine.

<property name="source.root" value="D:\svn\trunk\admin"/>
<property name="staging.directory" value="\\B\Shared.Folder.Name"/>
<property name="directory.to.upload" value="${source.root}\ControlPanel"/>

<target name="network.deploy">
<echo message="-------- NETWORK.DEPLOY ---------------"/>
    <copy todir="${staging.directory}" verbose="true">
        <fileset basedir="${directory.to.upload}">
            <include name="**/*"/>
            <exclude name="**/*.vb"/>
        </fileset>
    </copy>
</target>

You should be able to do this by creating the same local user on each system. Exact same username, exact same password. Then run your service using those credentials. Also set the NTFS ACLs as you were and give the local account on each system access, as well as in the share permissions.