域认证排查的利用链：三个前置条件与最小验证

4768 是 TGT 请求、4769 是服务票据、4771 是预认证失败，三条能还原大部分问题，要一起看

这篇只讲机制与验证思路，所有测试都应该在授权范围内、对自己的环境做。

先说结论

三个条件全满足才是高危；只有一两个，多半是「理论上可以」。

• 条件一：入口可达（能碰到）
• 条件二：校验可绕（能通过）
• 条件三：影响可证（能造成后果）
• 验证：用无害 payload 证明，不落地
• 修复：堵住入口或加严校验，二选一

条件一：入口可达

4768 是 TGT 请求、4769 是服务票据、4771 是预认证失败，三条能还原大部分问题，要一起看。

先确认这个入口是否对外、是否需要登录、是否有网关拦截。很多「漏洞」死在第一步。

条件二：校验可绕

同一个 SPN 被重复注册到两个账号，票据请求会随机命中其中一个，用户只会说时好时坏。

校验的常见问题是「只做一次」和「只做黑名单」，绕过思路通常来自这两点。

条件三：影响可证

NTLM 仍在大量内网设备上使用，关闭之前要先确认老旧设备清单，打印机往往最先出问题。

这个问题的几个已知事实

公开资料里比较确定的几条：

• 票据加密类型不一致，RC4 与 AES 混用会导致跨域信任偶发失败

验证方法（无害）

用能证明问题存在的最小动作，不读取真实数据、不写入、不横向。

修复思路

排查顺序是 DNS、时间、账号状态、SPN，八成问题在前两步就能定位，先看时间同步再动账号。

修完必须回归：同一入口的其它路径、同一参数在其它接口、以及历史数据的兼容。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 域内时间偏差超过五分钟 Kerberos 会直接拒绝，表现是密码正确却登不上
• 密码明明是对的却登不上，只查账号不看时间同步
• 直接关掉 NTLM，打印机与老 NAS 集体掉线
• SPN 重复注册当成偶发，重启后好了几天又犯

能证明「三个条件都成立」，比能打穿更重要。