Network Service account accessing a folder share

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.

Solution 1:

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

Solution 2:

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.

Solution 3:

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.