Kerberos“三次握手”是客户端与KDC、服务端间三阶段加密交互，分别解决密码验证、TGT安全分发和PAC权限确认问题；每步依赖时间同步、密钥一致与策略统一。
kerberos 的“三次握手”不是 tcp 那种连接建立过程，而是客户端与 kdc、服务端之间完成身份确认的三个严格递进的加密交互阶段。理解它，关键不是记步骤，而是看清每一步在解决什么信任问题。
为什么第一次交互必须用密码哈希加密时间戳而不是直接传密码
客户端向 AS 发送 KRB_AS_REQ 时，不传明文密码，而是用用户密码的 NTLM 哈希加密一个当前时间戳。AS 在 AD 中查到该用户后，用自己存的同一哈希去解密这个时间戳——能成功，就证明客户端知道正确密码；时间戳未过期（默认 5 分钟窗口），就证明请求不是重放攻击。
常见错误现象：KRB_AP_ERR_BAD_INTEGRITY 或登录失败但无明确提示，往往是因为客户端和域控制器时间偏差超过 5 分钟，或密码已变更但本地缓存未刷新。
- Windows 客户端默认依赖域控制器时间同步，务必确保
w32time服务正常运行 - Linux 客户端需手动配置 NTP 指向同一域控 IP，不能只靠
systemd-timesyncd - AD 中用户密码哈希变更后，旧 TGT 不会自动失效，需等其自然过期（默认 10 小时）或手动清理
kerberos ticket cache
为什么 TGT 能被客户端接收却无法被客户端解密
AS 返回的响应里包含两部分：用用户密码哈希加密的 Session Key-AS，以及用 krbtgt 账户密码哈希加密的 TGT。前者客户端能解，后者不能——因为客户端根本不知道 krbtgt 的密钥。
这个设计直接封死了客户端伪造或篡改 TGT 的可能。TGT 本质是“我已被 AS 认证过”的加密凭证，只能由 TGS（用 krbtgt 密钥）验证真伪。
使用场景中容易忽略的一点：TGT 本身不绑定具体服务，所以一次获取后可反复用于向不同服务申请 ST，直到过期。这也是 Kerberos 实现单点登录（SSO）的基础。
- TGT 默认有效期为 10 小时，最大可续期 7 天（取决于域策略
MaxRenewAge） -
klist可查看当前缓存的 TGT；kinit -R可尝试续期，但前提是原始 TGT 未过期且策略允许 - 若服务端日志出现
KRB_AP_ERR_TKT_EXPIRED，优先检查客户端 TGT 是否已过期，而非服务端时间
为什么服务票据（ST）里要嵌入 PAC 而不只是 Session Key
当 TGS 返回 ST 给客户端时，ST 不仅包含 Session Key-Server 和时间戳，还强制嵌入 PAC（Privilege Attribute Certificate）。PAC 是 Active Directory 生成的二进制结构，内含用户 SID、组成员关系、是否为管理员等权限信息。
服务端收到 ST 后，用自身密钥解密出 PAC，并交由本地 LSASS 验证——这步绕过了再次查 AD，极大提升性能，也防止服务端被诱导接受伪造的权限声明。
典型问题：Access denied 却认证成功，往往不是 Kerberos 流程失败，而是 PAC 中的组策略未生效，或服务端启用了 Validate client's PAC 但 AD 中用户对象被禁用“此账户支持 Kerberos AES 加密”选项。
- Windows Server 2016+ 默认启用 PAC 签名验证，若服务端是旧系统（如 Win2008 R2），可能因签名算法不兼容拒绝 ST
- 用
setspn -L检查服务主体名是否唯一；重复 SPN 会导致 TGS 无法确定该用哪个服务密钥加密 ST - PAC 不参与网络传输加密，但会被服务端校验完整性——若被中间人篡改，解密后校验失败直接拒收
真正容易被忽略的复杂点在于：三次交互中任何一环的时间戳校验、密钥派生、PAC 解析都依赖精确同步和策略一致性。不是流程写对了就能通，而是整个域环境的每个节点——客户端、KDC、服务端——必须共享同一套时间源、同一套加密策略、同一套权限模型。漏掉任意一个，表面看是“认证失败”，实际可能是 PAC 验证静默跳过、AES 密钥协商降级、甚至 TGT 被当成无效票据丢弃。
