如何让IIS无需特定用户账户访问DFS文件？

核心场景回顾 #

基于MySQL的老旧ASP.NET站点部署在Windows Server 2022 IIS，文档存储在域环境DFS中；DFS权限仅能通过IT提供商的Web界面配置，无法本地修改。当前使用个人域账户作为应用池标识和站点特定用户，存在密码同步麻烦、安全风险高的问题。

1. 如何无需使用个人账户实现访问？ #

核心思路是用域级服务账户或服务器计算机账户替代个人账户：

• 专用域服务账户：创建一个仅用于该站点的域账户，禁用交互式登录权限，通过IT提供商的Web界面给这个账户分配DFS的必要权限（读/写根据需求），然后将应用池标识设为该账户，站点身份设为“应用池标识”。
• 服务器计算机账户：域内的服务器本身有一个计算机账户（格式为DOMAIN\ServerName$），联系IT提供商给这个账户配置DFS权限，然后使用ApplicationPoolIdentity作为应用池标识，站点身份设为“应用池标识”即可。

2. 若能给承载网站的计算机授予DFS权限，是否可改用传递认证和内置ApplicationPoolIdentity？ #

完全可以。当应用池使用ApplicationPoolIdentity时，访问网络资源（如DFS）会自动使用服务器的计算机账户（DOMAIN\ServerName$）进行身份验证。只要给这个计算机账户配置了DFS的对应权限，配合域内的Kerberos认证（默认域环境已支持），就能实现无个人账户的访问，无需手动指定特定用户。

3. 启用传递认证且应用程序池为内置ApplicationPoolIdentity时，使用的是哪个账户？给IIS_IUSRS组授予DFS权限是否可行？ #

• 访问网络资源时，ApplicationPoolIdentity实际使用的是服务器的计算机账户（DOMAIN\ServerName$），而非IIS_IUSRS组的成员。ApplicationPoolIdentity在本地访问时用IIS AppPool\AppPoolName这个本地账户，但跨机器访问网络资源时，会自动切换为计算机账户，因为本地账户无法跨域验证。
• 给IIS_IUSRS组授予DFS权限不可行。IIS_IUSRS是服务器本地组，仅在当前服务器内有效，DFS服务器无法识别其他机器的本地组身份，跨机器访问时不会使用这个组的权限。

4. IIS_IUSRS组是否为计算机专属？是否需给serverHostname\IIS_IUSRS授予DFS权限？ #

• IIS_IUSRS是每台IIS服务器专属的本地组，仅存在于当前服务器，其他服务器（包括DFS服务器）无法识别这个组的身份。
• 不需要给serverHostname\IIS_IUSRS配置DFS权限，因为跨机器访问时，这个本地组的身份无法被DFS服务器验证，完全不会生效。

原理说明 #

域环境下IIS应用池访问网络资源的身份规则：

• 内置账户（ApplicationPoolIdentity、NetworkService）访问本地资源时，使用自身的本地身份；访问网络资源时，会自动使用服务器的计算机账户，因为本地身份无法跨域进行身份验证。
• 传递认证（Kerberos）的作用是让服务器能以自身计算机账户的身份，安全地访问域内其他资源，前提是目标资源信任该计算机账户的权限。

最优方案 #

1. 联系IT提供商，通过他们的Web界面，给承载站点的服务器计算机账户（DOMAIN\ServerName$）分配DFS的必要权限（如读取、写入）。
2. 修改IIS站点及虚拟目录的身份设置为应用池标识（取消“特定用户”配置）。
3. 将应用程序池的标识设置为ApplicationPoolIdentity（相比NetworkService，它是每个应用池隔离的专用身份，安全性更高）。
4. 确认域内Kerberos配置正常（默认域环境已启用，无需额外操作，若出现权限问题可检查SPN注册）。

个人账户使用风险确认 #

使用个人账户的风险完全合理，具体包括：

• 服务中断风险：域账户密码定期过期，每次都需要同步修改应用池和站点的密码，操作繁琐且容易遗漏导致服务无法访问。
• 扩大攻击面：个人账户通常拥有更多域内权限，一旦站点被入侵，攻击者可利用该账户的权限访问更多域内资源，引发更大安全事故。
• 人员变动风险：若账户所有者离职，需立即更换账户，否则会导致服务中断，且可能存在权限泄露的隐患。

内容的提问来源于stack exchange，提问作者MILO