IIS 10中域账号作为应用池标识的权限问题及疑惑

我来帮你梳理清楚这个问题的核心逻辑和你遇到的疑点：

1. 域账号作为应用池标识的核心规则 #

你之前的判断是完全正确的：域账号不需要在IIS服务器上创建本地用户。只要这个账号在公司域环境（活动目录）中存在，并且拥有目标网络资源的访问权限，IIS应用池以它为标识运行时，就能通过域身份验证正常访问共享文件夹。你后来把域账号重新添加到共享文件夹权限后功能恢复，也直接验证了这一点——本地是否存在该用户不影响域身份的权限校验。

2. 关于“删除本地管理员后初期可用，后来失效”的原因 #

这大概率是系统或IIS的权限缓存导致的。刚删除本地用户时，系统还保留着之前的权限会话缓存，应用池可以暂时沿用缓存的权限访问共享资源；等缓存过期、应用池重启或者服务器刷新权限后，就会触发真实的权限校验，这时候因为共享文件夹里的域账号权限已经丢失，就出现了访问失败的情况。

3. 共享文件夹中域账号权限消失的可能原因 #

结合你提到的操作流程，有两种常见可能：

• 权限继承关联：如果之前共享文件夹的权限是通过本地管理员组间接赋予的（比如本地管理员组拥有共享访问权，而你的域账号属于这个组），那么当你把域账号从本地管理员组移除后，它通过组继承的共享权限也就随之消失了。
• 操作误触：在移除服务器本地用户的过程中，可能不小心误操作了共享文件夹的权限配置，导致域账号被直接从权限列表中删除。

4. 后续安全合规的配置建议 #

• 不需要把这个域账号重新添加到服务器本地用户列表里，更不要给它本地管理员权限（你担心的appcmd能查看密码的风险是合理的，高权限账号作为应用池标识会带来不必要的安全隐患）。
• 直接在网络共享文件夹的权限设置中，给域账号my-company/custom_app_pool_identity配置必要的最小权限（比如仅读取、列出目录内容，根据业务需求调整），确保权限是直接赋予该账号，而非通过高权限组继承，这样既安全又能保证功能正常。

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