Windows Authentication在Chrome中失效但Firefox可正常使用

核心触发原因 #

Chrome 110及以上版本收紧了Windows集成认证（NTLM/Kerberos）的适用范围，默认仅将无转发改写的同源内网URL识别为可信内网站点，经过负载均衡转发的掩码URL触发了Chrome的新限制，Firefox暂未执行同类规则收紧，因此可以正常使用：

• 负载均衡的反向代理改写导致浏览器识别的站点上下文与后端应用配置的认证上下文不匹配，Chrome默认拦截跨上下文的自动认证请求
• 未掩码URL属于内网直连，无转发改写，因此符合Chrome的认证规则

故障验证步骤 #

• 打开Chrome地址栏输入chrome://policy/，查看AuthServerAllowlist、AuthNegotiateDelegateAllowlist两个配置项是否包含你的掩码域名
• 访问掩码URL打开开发者工具「网络」标签，勾选「保留日志」后重试登录，查看认证请求的WWW-Authenticate响应头是否正常返回Negotiate/NTLM，是否存在异常跨域跳转

修复方案 #

临时验证方案 #

在Chrome快捷方式的目标字段后追加启动参数，重启浏览器后重试登录：

--auth-server-allowlist="你的掩码域名,*.你的根域名"

如果修改后可以正常登录，即可确认是Chrome认证白名单规则限制导致的问题

永久修复方案 #

客户端侧（域环境适用）

通过域组策略批量配置所有Chrome客户端的AuthServerAllowlist规则，将掩码域名加入认证允许列表即可

负载均衡侧

• 调整反向代理配置，保留请求的原始Host头透传给后端应用，不要改写为内网未掩码域名
• 确保WWW-Authenticate响应头由后端应用直接返回，不要被负载均衡拦截修改
• 启用负载均衡的会话保持配置，Windows认证需要绑定同一会话的所有请求到同一台后端节点，会话丢失也会触发Chrome的认证校验失败

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