网络服务帐户访问文件夹共享

网络服务帐户访问文件夹共享

我有一个简单的场景。ServerA 上有一个在内置网络服务帐户下运行的应用程序。它需要读取和写入 ServerB 上的文件夹共享上的文件。我需要在 ServerB 上的文件夹共享上设置什么权限?

我可以打开共享的安全对话框,添加新的安全用户,单击“对象类型”并确保选中“计算机”,然后添加具有读/写访问权限的 ServerA,从而使其正常工作。通过这样做,哪些帐户可以访问共享?仅网络服务?ServerA 上的所有本地帐户?什么应该我该怎么做才能授予 ServerA 的网络服务帐户访问 ServerB 共享的权限?

笔记:
我知道这类似于这个问题。但是,在我的场景中,ServerA 和 ServerB 位于同一个域中。

答案1

“共享权限”可以是“所有人/完全控制”——只有 NTFS 权限才真正重要。(此处提示那些对“共享权限”有不健康依恋的人的宗教论点……)

在 ServerB 上的文件夹的 NTFS 权限中,您可以使用“DOMAIN\ServerA - 修改”或“DOMAIN\ServerA - 写入”来获取权限,具体取决于是否需要能够修改现有文件。(修改确实是首选,因为您的应用程序可能会在创建文件后重新打开文件以进行进一步写入 - 修改赋予它该权限,但写入不赋予它该权限。)

假设您在权限中命名“DOMAIN\ServerA”,则只有 ServerA 上的“SYSTEM”和“Network Service”上下文才具有访问权限。ServerA 计算机上的本地用户帐户与“DOMAIN\ServerA”上下文不同(如果您确实想授予他们访问权限,则必须单独命名)。

另外:服务器计算机角色会发生变化。您可能希望在 AD 中为此角色创建一个组,将 ServerA 放入该组,并授予该组权限。如果您更改了 ServerA 的角色并将其替换为 ServerC,则只需更改组成员身份,而不必再触及文件夹权限。许多管理员考虑过将用户命名为权限,但他们忘记了“计算机也是人”,他们的角色有时会发生变化。在这场游戏中,效率的关键在于尽量减少您未来的工作量(以及犯错的能力)...

答案2

计算机的网络服务帐户将作为计算机名称帐户映射到另一台受信任的计算机。例如,如果您在 MyDomain 中的 ServerA 上以网络服务帐户身份运行,则应映射为 MyDomain\ServerA$(是的,美元符号是必需的)。当您让 IIS 应用程序以网络服务帐户身份运行并连接到另一台服务器上的 SQL Server(例如 SSRS 或 Microsoft CRM 的扩展安装)时,您会经常看到这种情况。

答案3

我同意 Evan 的观点。但是,我认为,如果您真的担心安全性,那么理想的解决方案是专门为该应用程序/服务创建一个用户帐户,并授予该帐户访问共享文件夹的必要权限。这样,您就可以确保只有该应用程序/服务可以访问共享。不过,这可能有点过头了。

相关内容