我有一个简单的场景。ServerA 上有一个在内置网络服务帐户下运行的应用程序。它需要在 ServerB 上的文件夹共享上读取和写入文件。我需要在 ServerB 上的文件夹共享上设置什么权限？
我可以通过打开共享的安全对话框，添加新的安全用户，单击“对象类型”并确保选中“计算机”，然后添加具有读/写访问权限的 ServerA 来使其工作。通过这样做，哪些帐户可以访问共享？只有网络服务？ServerA 上的所有本地帐户？我应该怎么做才能授予 ServerA 的网络服务帐户对 ServerB 共享的访问权限？
注意：
我知道这类似于这个问题。但是，在我的场景中，ServerA 和 ServerB 位于同一个域中。
“共享权限”可以是“所有人/完全控制”——只有 NTFS 权限才是真正重要的。（提示那些对“共享权限”有不健康依恋的人的宗教论点......）
在 ServerB 上文件夹的 NTFS 权限中，您可以使用“DOMAIN\ServerA - Modify”或“DOMAIN\ServerA - Write”，具体取决于它是否需要能够修改现有文件。（Modify 确实是首选，因为您的应用程序可能会在创建文件后重新打开文件以进一步写入 - Modify 赋予它该权利，但 Write 没有。）
假设您在权限中命名为“DOMAIN\ServerA”，则只有 ServerA 上的“SYSTEM”和“Network Service”上下文可以访问。ServerA 计算机上的本地用户帐户与“DOMAIN\ServerA”上下文不同（如果您确实想授予他们访问权限，则必须单独命名）。
顺便说一句：服务器计算机角色发生变化。您可能希望在 AD 中为此角色创建一个组，将 ServerA 放入该组，并授予该组权限。如果您曾经更改 ServerA 的角色并将其替换为 ServerC，您只需更改组成员身份，您就无需再次触及文件夹权限。很多管理员都在考虑这种以权限命名的用户，但他们忘记了“计算机也是人”，他们的角色有时会发生变化。尽量减少你未来的工作（以及你犯错的能力）是这场比赛中高效的全部意义所在......
一台计算机的网络服务帐户将映射到另一台受信任的计算机作为计算机名称帐户。例如，如果您在 MyDomain 中作为 ServerA 上的网络服务帐户运行，则应映射为 MyDomain\ServerA$（是的，美元符号是必需的）。当您将 IIS 应用程序作为连接到不同服务器上的 SQL Server 的网络服务帐户运行时，您会看到很多情况，例如 SSRS 或 Microsoft CRM 的横向安装。
我同意埃文。但是，如果您真正关心安全性，我相信理想的解决方案是创建一个专门为该应用程序/服务运行的用户帐户，并授予该帐户对共享文件夹的必要权限。这样，您可以确定只有该应用程序/服务正在访问共享。不过，这可能有点矫枉过正。