Windows Server域环境下为SYSTEM账户授予网络文件夹写入权限的问题

我之前刚好碰到过几乎一模一样的坑，当时折腾了好半天才搞明白LocalSystem账户访问网络资源的身份逻辑——你找不到地方给SYSTEM加权限是正常的，因为它在访问域内网络共享时，根本不是以本地SYSTEM账户的身份，而是用Web服务器的机器账户去访问！

下面给你捋清楚解决步骤：

核心原理 #

LocalSystem是本地系统账户，当它访问域内的网络资源时，会自动以DOMAIN\你的服务器名$格式的机器账户身份去请求权限（注意末尾的美元符号，这是域内机器账户的标识）。所以你要找的不是本地的SYSTEM，而是Web服务器对应的机器账户。

具体操作步骤 #

1. 确认机器账户名称：先记下你的Web服务器全名（比如服务器叫WEB-SRV01，域是CORP，那机器账户就是CORP\WEB-SRV01$）。
2. 设置共享权限：
   • 到存放网络文件夹的目标服务器上，右键共享文件夹 → 属性 → 「共享」标签页 → 高级共享 → 点击「权限」按钮。
   • 添加刚才的机器账户，给它分配「更改」和「读取」权限（要写入的话，「更改」权限就足够了）。
3. 设置NTFS权限：
   • 切换到「安全」标签页，同样添加机器账户，授予「写入」「修改」等必要权限（NTFS权限是底层权限，必须和共享权限配合生效）。
4. 验证权限是否生效：
   • 可以在Web服务器上用psexec -s cmd.exe命令（需要先下载PsTools工具）打开一个以LocalSystem身份运行的命令行窗口。
   • 在这个窗口里尝试访问网络共享：net use \\目标服务器\共享名，然后创建一个测试文件，看看是否还会报错。

备选方案 #

如果觉得机器账户的权限设置太绕，也可以考虑把应用池的身份改成一个专门的域服务账户：

• 创建一个域用户（比如CORP\WebExcelService），给这个账户分配网络文件夹的读写权限，同时确保它有IIS应用池运行所需的本地权限。
• 把应用池的「进程模型」→「身份」改成这个域用户，这样权限排查会更直观，不过你需要确保Interop在这个账户下也能正常运行（可能需要配置Office的DCOM权限之类的，这也是Interop的老问题了）。

备注：内容来源于stack exchange，提问作者Koops128