谷歌浏览器代理频繁提示输入用户名密码？

Question

问题：谷歌浏览器在配置了企业级代理后，频繁弹出代理身份验证窗口，要求输入用户名和密码，即使已正确保存凭据。该问题多发生于Windows域环境下的Chrome 100+版本，表现为每隔数分钟或页面刷新时重复提示，影响正常办公效率。初步排查发现，Chrome未能持久化存储代理认证信息，可能与NTLM/Kerberos单点登录机制失效、凭据管理器冲突或策略组中“自动发送用户名和密码”选项未启用有关。

Answer 1

1. 问题背景与现象分析

在企业级IT环境中，Chrome浏览器自版本100起频繁出现代理身份验证弹窗问题。用户即使已正确配置凭据并选择“保存密码”，仍会在页面刷新或新标签页打开时被要求重新输入用户名和密码。该问题集中出现在使用Windows域环境（Active Directory）并部署了基于NTLM或Kerberos认证机制的企业代理服务器（如Zscaler、Palo Alto Prisma Access、Squid + Kerberos等）的组织中。

典型表现为：

• 每5-10分钟重复弹出HTTP 407代理认证窗口
• Chrome“设置 → 密码”中虽显示已保存代理凭据，但未自动填充或触发
• 仅影响Chrome，Edge（Chromium内核）可能复现，Firefox通常不受影响
• 事件查看器中可查到WinHTTP相关错误或SSPI认证失败日志

2. 根本原因分层解析

从底层协议到应用层策略，该问题涉及多个技术层级的交互异常。以下是按深度递进的分析框架：

层级	组件	潜在故障点
网络层	代理服务器	NTLM挑战响应超时、Kerberos票据未正确下发
系统层	Windows SSPI	Negotiate Provider顺序错误、CredSSP冲突
安全层	Kerberos/NTLM	TGT有效期短、SPN配置缺失
浏览器层	Chrome HTTP栈	未启用Integrated Windows Authentication
策略层	Group Policy	Auto-Login功能未开启或策略未生效
存储层	Windows Credential Manager	Generic Credentials未同步至Chrome

3. 排查流程图与诊断路径

# 初步诊断命令示例
nslookup proxy.yourcompany.com
klist purge && kinit [e-mail]  # 验证Kerberos票据获取
curl -v --proxy http://yourproxy:8080 http://google.com  # 模拟代理请求
chrome.exe --log-level=1 --vmodule=ntlm*=3,sso*=3  # 启用Chrome SSO调试日志

graph TD A[用户报告频繁代理认证] --> B{是否为域用户登录?} B -->|是| C[检查Kerberos TGT状态] B -->|否| D[强制使用域账户登录测试] C --> E[Kerberos票据有效?] E -->|否| F[排查DNS、时间同步、SPN] E -->|是| G[Chrome是否启用IWA?] G --> H[组策略配置检查] H --> I[确认ProxyBypassList设置] I --> J[清理Chrome凭据缓存] J --> K[测试结果] K -->|解决| L[文档化变更] K -->|未解决| M[抓包分析HTTP 407流程]

4. 核心解决方案集

根据多年企业现场支持经验，以下方案组合可覆盖90%以上案例：

1. 组策略强制启用自动认证：
   • 路径：Computer Configuration → Policies → Administrative Templates → Windows Components → Internet Explorer → Security Features → Integrated Windows Authentication
   • 启用“允许在非本地区域中使用集成Windows身份验证”
   • 同时配置User Configuration → Google → Chrome → Authentication → AuthServerWhitelist 和 DelegateWhitelist
2. 注册表修复Negotiate Provider顺序：

   HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\NTLMDomainSuffixes
       HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages

   确保msv1_0前无第三方认证模块干扰。
3. Chrome启动参数调优： 添加如下参数以增强SSO兼容性： --auth-server-whitelist=".yourcompany.com" --auth-negotiate-delegate-whitelist=".yourcompany.com" --enable-auth-negotiate
4. 代理PAC文件优化： 避免在PAC中对内部地址返回DIRECT，应统一走PROXY以保持连接上下文一致性。
5. 时间同步校验： 域成员与DC时间差不得超过5分钟，否则Kerberos将拒绝票据。
6. 服务主体名称（SPN）验证： 使用setspn -L proxyhost$确认HTTP/proxy.yourcompany.com已注册。

5. 高级调试手段与日志分析

当标准方案无效时，需深入抓包与日志分析：

• 使用Fiddler或Wireshark捕获HTTP 407响应头中的Proxy-Authenticate: NTLM流程
• 检查Chrome的chrome://net-internals/#httpAuth页面，观察Authentication Cache状态
• 启用Windows事件日志：Microsoft-Windows-SSPI-Operational通道
• 通过procmon监控Chrome对lsass.exe的LPC调用是否成功
• 对比正常与异常机器的nltest /dsgetdc:domain.com输出