.NET5 Windows身份验证API发布至IIS10后访问受保护端点弹出无效登录框问题

核心故障根因 #

你遇到的“弹登录框、输入正确凭据也无法通过”的场景，基本都是配置链路的某一环没打通，和代码本身的[Authorize]、服务注册逻辑关系不大——毕竟IIS Express下能正常跑，说明代码逻辑是通的，问题全在生产IIS的环境配置上。

具体排查步骤 #

1. 先核对web.config的配置覆盖问题 #

VS发布应用的时候会自动生成默认web.config，经常会把Windows身份验证的关键配置覆盖丢失，重点检查两处：

• 定位到system.web节点，确认是否存在 <authentication mode="Windows" /> 配置。如果这里显示的是<authentication mode="None"/>，哪怕IIS层面开了Windows身份验证，应用层面也会走匿名访问逻辑，直接触发401要求重新登录
• 定位到aspNetCore节点，确认是否配置了 forwardWindowsAuthToken="true"。这个属性默认是关闭的，没开的话IIS完成Windows身份验证后，不会把身份令牌转发给后面跑在Kestrel上的应用，相当于应用收不到已经验证通过的用户信息，自然会反复要求登录

2. 调整Windows身份验证的提供程序与扩展保护配置 #

你当前已经配置了Negotiate提供程序，这部分是最容易出问题的环节：

• 打开IIS管理器对应站点的「Windows身份验证」模块，点击右侧的「高级设置」，把扩展保护的选项从默认的「接受」改成「关闭」。这是IIS10上HTTPS站点最常见的坑：开启扩展保护后，系统会校验请求的通道绑定令牌，如果HTTPS站点的证书和绑定逻辑不匹配，会直接拒绝所有通过Negotiate传递的凭据，哪怕输入正确账号密码也无法通过校验
• 调整提供程序顺序：把Negotiate放在提供程序列表的第一位，NTLM放在第二位，避免IIS优先走不兼容的认证流程
• 如果你的站点绑定了主机名而非IP/localhost访问，先临时禁用Negotiate下的Kerberos子项，仅保留NTLM认证做测试。Kerberos认证要求给应用池的运行账号注册对应的SPN记录，没配的话Negotiate流程会直接卡死，表现就是反复弹登录框，无论输什么凭据都通不过。如果测试通过，再去补对应的SPN配置，恢复Kerberos支持

3. 应用池与站点的基础配置核对 #

• 确认应用池的托管管道模式为「集成」，经典模式下Windows身份验证的令牌无法正常传到应用层
• 确认应用池没有开启「匿名身份验证」的强制覆盖，匿名认证开启的优先级高于Windows认证，会导致凭据传递链路被截断
• 确认站点的HTTPS绑定没有配置SNI冲突，否则Negotiate的认证握手会在HTTPS层就被中断

4. 排除浏览器端的拦截问题 #

• 确认访问站点的地址是浏览器默认支持自动传递Windows凭据的范围（本地内网、受信任站点列表），如果用公网域名或外网IP访问，浏览器默认不会自动传递域凭据，会弹出登录框
• 临时用内核模式的IE/Edge内网模式测试访问，排除浏览器扩展、安全策略对认证流程的拦截

需要补充的排查信息 #

如果按以上步骤调整后还是有问题，需要补充以下信息才能进一步定位：

• 应用的技术栈是ASP.NET Framework还是ASP.NET Core，对应版本是多少
• 应用池的运行账号是内置的ApplicationPoolIdentity，还是自定义的本地账号/域账号
• 访问站点时用的是服务器IP、localhost还是配置了DNS的主机名，客户端是否和服务器在同一个AD域内
• 开启IIS的失败请求跟踪，复现1次401错误，记录日志里的具体失败原因（是通道绑定校验失败、SPN不匹配，还是令牌转发失败）

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