这是个非常典型的IIS传递身份验证配置踩坑场景，咱们一步步拆解问题根源和修复方法：

核心问题：传递身份验证的身份流转逻辑错配 #

你当前用的DefaultAppPool默认身份是ApplicationPoolIdentity，这个身份在访问远程UNC共享时，并不会传递当前访问用户的AD凭据，而是用Web服务器的机器账户（格式为DOMAIN\你的Web服务器名$）去尝试访问共享文件夹。如果这个机器账户没有共享文件夹的权限，就会反复弹出凭据框，哪怕你输入的用户凭据本身有权限也没用。

而你切换到“特定用户”能正常访问，是因为IIS直接用这个指定账户的权限去访问共享，完全绕过了当前访问用户的身份验证，自然不会有弹窗，但也失去了AD组权限控制的作用——这相当于所有用户都共享这个特定账户的权限，显然不符合你的需求。

修复步骤：让传递身份验证真正生效 #

要实现“仅允许有权限的AD组用户访问共享文件”，你需要正确配置Kerberos委派和应用池设置：

1. 调整应用程序池身份（可选但推荐） #

把DefaultAppPool的身份从默认的ApplicationPoolIdentity改成一个域服务账户（比如DOMAIN\IIS_Service_Acct），这个账户不需要共享文件夹的权限，但需要被允许委派用户身份。

操作路径：IIS管理器 -> 应用程序池 -> 右键DefaultAppPool -> 高级设置 -> 进程模型 -> 标识 -> 选择“自定义账户”并输入域服务账户信息。

2. 配置Kerberos约束委派（关键！） #

传递身份验证跨机器访问共享时，必须依赖Kerberos委派（NTLM无法跨机器传递用户身份），步骤如下：

• 打开AD用户和计算机控制台，找到你的Web服务器的计算机对象
• 右键属性 -> 切换到「委派」标签页
• 选择「信任此计算机来委派指定的服务」，点击「添加」
• 在弹出的窗口中点击「用户或计算机」，找到你的文件服务器，选择后点击「确定」
• 在可用服务中找到cifs（这是文件共享的核心服务），选中后点击「确定」完成配置

3. 修正虚拟目录与身份验证设置 #

• 确保虚拟目录的物理路径是双反斜杠开头的UNC路径：\\servername\Folder（你之前写的\servername\folder是单斜杠，这会被识别为本地路径，也是潜在问题）
• 虚拟目录的物理路径凭据保持「应用程序用户（传递身份验证）」，登录类型建议改成「Kerberos」（如果域环境支持），避免用ClearText带来的安全风险
• 在站点和子站点的Windows身份验证设置中，确保启用了**Negotiate（Kerberos）**和NTLM，并且把Negotiate移到优先级最高的位置

4. 验证AD组权限 #

最后确认共享文件夹的NTFS权限和共享权限中，目标AD组拥有「读取」权限，并且没有拒绝权限覆盖允许权限。

总结 #

你之前的配置错误在于忽略了Kerberos委派的要求，导致传递身份验证无法正确流转用户的AD凭据，只能反复弹窗请求权限。按照上面的步骤配置后，就能实现“仅允许有权限的AD组用户下载文件”的需求，同时保持身份验证的正确性。

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