浏览器经过企业代理访问内部系统，弹出登录框或报“目标主体名称不正确”，常被简单归类为代理故障。Kerberos认证至少包含客户端找KDC、获取票据、访问目标服务三个阶段，只有其中一部分可能经过HTTP代理。
一条Kerberos请求经历什么
- 客户端根据Realm配置与DNS信息找到KDC；
- 用户完成初始认证，获得票据授予票据；
- 客户端按目标服务SPN向KDC申请服务票据；
- 客户端把服务票据交给HTTP、LDAP、SMB等目标服务；
- 目标验证票据，必要时再执行受控委派。
如果连第一步的KDC都不可达，修改浏览器HTTP代理没有帮助；如果票据已经获取而Web服务拒绝，则应检查SPN、反向代理身份和应用配置。
KDC连接不等于网页连接
Kerberos常使用UDP或TCP 88，密码更改等功能还可能涉及其他端口。HTTP代理一般不能替代到KDC的网络路径。报文较大时客户端可能从UDP切换到TCP，因此“偶尔成功、用户组多时失败”也可能与TCP路径或中间设备有关。
DNS为何是认证的一部分
客户端需要找到域控制器或KDC，并把访问的主机名映射到正确服务身份。DNS搜索域、SRV记录、分流DNS、IPv4/IPv6选择或错误的hosts记录，都可能让客户端连接到错误节点。不要为了临时连通改用IP地址，因为这会进一步破坏SPN匹配。
SPN到底匹配谁
SPN描述一个服务实例，例如Web服务通常与HTTP/主机名相关。负载均衡、别名域名或服务迁移后，SPN若仍绑定旧账号、重复注册或根本不存在，客户端就无法获得正确服务票据。排查时记录用户访问的完整主机名、目标服务账号和注册结果，不要只看服务器本机名。
反向代理前后的身份边界
反向代理终止TLS后，可能自己完成Kerberos认证，也可能把请求转给后端。若后端需要用户身份，必须使用明确且受支持的委派或身份传递设计。简单转发一个可被外部伪造的用户名请求头并不安全；后端应只信任受控代理来源，并清理外部同名头。
HTTP Negotiate与代理407
| 现象 | 更可能的阶段 | 优先证据 |
|---|---|---|
| 407 Proxy Authentication Required | 正向代理认证 | Proxy-Authenticate与客户端代理支持 |
| 401并带Negotiate | 目标Web服务认证 | 目标主机名、SPN和服务端日志 |
| KDC不可达 | 客户端取票 | DNS、88端口和KDC日志 |
| Clock skew | 票据时效验证 | 客户端、KDC、服务端UTC时间 |
时钟偏差为何如此敏感
Kerberos票据包含有效时间，系统时钟相差几分钟就可能被拒绝。不要通过延长容忍窗口掩盖长期漂移，应修复时间源、休眠恢复或虚拟机校时问题。时间同步的网络边界可参考NTP与Chrony时间同步排查。
票据缓存会造成什么错觉
更改DNS、SPN或账号后，客户端可能仍持有旧票据。先记录现有票据信息，再按组织流程清理和重新登录，避免一上来删除所有凭据导致证据消失。服务端密钥、机器账号密码不同步，也可能让新旧节点表现不一致。
跨域与委派不要靠猜
跨Realm信任、约束委派和资源端约束委派都有明确的信任方向。多跳访问失败时，应画出用户、前端服务、后端服务及其服务账号，确认到底需要认证还是委派。不要为了“先能用”开放宽泛委派权限。
安全排查清单
- 用故障用户实际访问的FQDN复现，不改成IP；
- 核对DNS SRV、Realm映射、KDC UDP/TCP可达性；
- 检查客户端票据、SPN唯一性及目标服务账号；
- 对齐客户端、KDC和服务端时钟；
- 分别读取代理、Web服务和域控日志；
- 工单中不要粘贴票据、口令、会话Cookie或完整身份令牌。
结论
Kerberos认证失败不能只看“是否配置代理”。先判断失败发生在找KDC、取票、申请服务票据还是目标验证，再核对DNS、SPN、时钟和委派边界，才能避免把身份配置问题误判为网络问题。
