Chrome策略AuthServerWhitelist与AuthNegotiateDelegateWhitelist的区别是什么？

我之前在搞内网Windows身份验证的自动化脚本时，也踩过一模一样的坑——单独配AuthServerWhitelist完全没反应，必须把AuthNegotiateDelegateWhitelist也加上，Chrome才会自动走Kerberos/NTLM认证。这俩策略看着像双胞胎，但其实分工完全不同，给你掰扯清楚：

核心功能差异 #

1. AuthServerWhitelist：凭证自动提交的信任列表 #

• 这个策略的核心是授权Chrome对特定服务器自动使用当前用户的Windows凭证，不用用户手动输账号密码。
• 你可以把它理解成Chrome的"信任白名单"：只有在这个列表里的服务器，Chrome才会主动发起身份验证请求，而不是弹出登录框。

2. AuthNegotiateDelegateWhitelist：凭证委托的授权列表 #

• 这个策略管的是**凭证委托（delegation）**场景：当你访问的服务器需要Chrome把你的凭证转交给另一个后端服务时（比如内网的反向代理、SSO网关），只有在这个列表里的服务器，Chrome才允许这种"转交"行为。
• 简单说，它控制的是"能不能把凭证传递给下游服务"，而不是"能不能用凭证登录当前服务器"。

为什么你单独配置AuthServerWhitelist无效？ #

你的内网登录场景大概率是这种情况：

你访问的前端登录页所在的服务器，本身并不直接验证凭证，而是需要把你的Windows凭证委托给后端的AD域控或者SSO认证服务。这时候：

• AuthServerWhitelist只告诉Chrome"可以给前端服务器用凭证"，但前端要把凭证传给后端，这就需要AuthNegotiateDelegateWhitelist授权这个委托动作。
• 没配后者的话，Chrome会拒绝把凭证传递给下游，导致认证失败，看起来就像是AuthServerWhitelist没生效一样。

配置小建议 #

• 如果是直接访问需要身份验证的后端服务（没有中间代理/网关），单独配置AuthServerWhitelist就足够。
• 如果是通过代理、SSO网关这类中间层访问内网服务，必须同时配置两个策略，一般把中间层和后端服务的域名规则（比如*.your-intranet-domain.com）都加到两个列表里就行。

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