I have a simple scenario. There's an application on ServerA that runs under the built-in Network Service account. It needs to read and write files on a folder share on ServerB. What permissions do I need to set on the folder share on ServerB?

I can get it to work by opening the security dialog of the share, adding a new security user, clicking "Object Types" and making sure "Computers" is checked, and then adding ServerA with read/write access. By doing this, what accounts are gaining access to the share? Only Network Service? All local accounts on ServerA? What should I be doing to grant ServerA's Network Service account access to ServerB's share?

Note:
I know this is similar to this question. However, in my scenario ServerA and ServerB are in the same domain.

3 Answers
3

The "Share Permissions" can be "Everyone / Full Control"-- only the NTFS permissions really matter. (Cue religious arguments from people who have an unhealthy attachment to "Share Permissions" here...)

In the NTFS permissions on the folder on ServerB you could get by with either "DOMAIN\ServerA - Modify" or "DOMAIN\ServerA - Write", depending on whether it needed to be able to modify existing files or not. (Modify is really the preferred because your application may re-open a file after it creates it to write further-- Modify gives it that right, but Write does not.)

Only the "SYSTEM" and "Network Service" contexts on ServerA will have access, assuming you name "DOMAIN\ServerA" in the permission. Local user accounts on the ServerA computer are different from the "DOMAIN\ServerA" context (and would have to be named individually if you somehow did want to grant them access).

As an aside: Server computer roles change. You may want to create a group in the AD for this role, put ServerA into that group, and grant the group rights. If you ever change ServerA's role and replace it with, say, ServerC, you need only change the group memberships and you never need to touch the folder permission again. A lot of admins think about this kind of thing for users being named in permissions, but they forget that "computers are people too" and their roles sometimes change. Minimizing your work in the future (and your ability to make mistakes) is what being efficient in this game is all about...

You can't actaully grant local accounts on one computer access to resources on another computer.
–
pipTheGeekJul 15 '09 at 17:33

3

@pip: But you can create a local resource with the same username and password on the remote machine, then grant that account the required access. The end result is the same.
–
John RennieJul 15 '09 at 17:41

8

Network Service is an exception. It does map across as the computer account. In Windows 2000, the System account did the same.
–
K. Brian KelleyJul 15 '09 at 19:39

This does not seem possible exactly as described in Windows Server 2008+. I can't add the server as 'domain\server' but I can (if I include computers from the "Entire Directory") as just 'server'. Also, once added the server is listed 'server$'.
–
Kenny EvittFeb 14 '13 at 18:08

The network service account of a computer will map to another trusted computer as the computer name account. For instance, If you are running as the Network Service account on ServerA in MyDomain, that should map as MyDomain\ServerA$ (yes, the dollar sign is necessary). You see this quite a bit when you have IIS apps running as the Network Service account connecting to a SQL Server on a different server, such as a scaled out installation of SSRS or Microsoft CRM.

I agree with Evan. However, I believe the ideal solution, if security is a real concern for you, would be to create a user account specifically for that application / service to run as, and grant that account the necessary permissions to the shared folder. This way, you can be sure that only that application / service is accessing the share. This may be overkill though.