要真正看懂Kerberos认证请求日志，关键是将每条日志定位到“客户端→KDC→服务端”完整链路中：4768（TGT成功）、4771（预认证失败）、4769（服务票据发放）均记录于域控制器安全日志，需启用组策略审计；4771错误码（如0x17、0x12、0x24）直指预认证、账户状态或时间偏差等根因；结合Wireshark抓包可验证AS-REQ/TGS-REQ细节，联动日志与流量才能精准排障。
要真正看懂 kerberos 认证请求日志，关键不是堆砌事件 id，而是把每一条日志放进“客户端→kdc→服务端”的完整链路里去定位它在哪一环、起什么作用、异常时暴露什么问题。
从哪查：Kerberos 请求日志的来源与位置
Kerberos 认证请求（AS-REQ）由客户端发起，但日志只记录在域控制器（KDC）上，不保存在客户端或目标服务端。必须登录域控，打开事件查看器 → Windows 日志 → 安全，筛选以下事件 ID：
- 4768：TGT 请求（即 AS-REQ 成功处理）——含用户 SID、客户端 IP、请求时间、加密类型、是否预认证成功
- 4771：预身份验证失败（AS-REQ 被拒）——最常见报错来源，直接指出失败原因（如密码错误、账户禁用、时间偏差、密钥版本不匹配）
- 4769：服务票证发放（TGS-REQ 成功）——可反推 TGT 是否有效、SPN 是否注册正确、服务账户是否启用
注意：这些日志默认不开启。需提前在域控组策略中启用“Kerberos 身份验证（成功和失败）”，并运行 auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable。
怎么看：4771 错误码背后的真实含义
4771 是 Kerberos 排错的第一入口。它的“错误代码”字段（Event Data 中的 ErrorCode）是十六进制值，对应 RFC 4120 定义的 KRB-ERROR 码，但 Windows 实现有定制。常见值解读如下：
- 0x17（KDC_ERR_PREAUTH_REQUIRED）：客户端未提供预认证数据（如时间戳加密块）。通常因客户端禁用预认证（如某些 Linux kerberos 客户端配置）、或用户属性中勾选了“不需预认证”
- 0x12（KDC_ERR_CLIENT_REVOKED）：用户被禁用、过期、或登录时间/工作站限制不满足
- 0x24（KDC_ERR_CLIENT_NOTYET_VALID）：客户端时间比域控快超过 5 分钟（Kerberos 默认容差），或用户账户设置了未来生效时间
- 0x30（KDC_ERR_KEY_EXPIRED）：krbtgt 账户密码已过期（极少发生，但重置后旧 TGT 会立即失效）
不要只看错误码，同步检查日志中的 Client Address 和 Client Name，确认是不是来自预期设备；再比对 Time Generated 与域控系统时间，排除时钟漂移。
怎么串：把日志和抓包联动验证
单看日志只能知道“失败”，但不知道“为什么失败”。Wireshark 抓包（UDP 88 端口）能补全日志缺失的上下文：
- 若日志出现 4771 + 错误码 0x17，Wireshark 中应看到 AS-REQ 包的 padata 字段为空，或只有 type=112（PA-PAC-REQUEST）而无 type=2（PA-ENC-TIMESTAMP）
- 若日志显示 4768 成功，但后续访问服务失败，Wireshark 中检查 TGS-REQ 是否发出、TGS-REP 是否返回、AP-REQ 中的 Service Ticket 是否被服务端解密失败（此时服务端可能记 4625，而非 Kerberos 事件）
- 对比日志时间戳与抓包帧时间，误差超 1 秒就需怀疑时间同步问题；连续多个 AS-REQ 时间间隔极短（毫秒级），可能是客户端缓存票据失效后自动重试，也可能是暴力枚举痕迹
抓包时建议在客户端执行 klist purge 清空票据缓存，再触发一次全新认证，确保日志与流量严格一一对应。
怎么防：从日志反推配置风险点
高频出现的特定 4771 错误，往往暴露底层配置隐患：
- 大量 0x24 错误 → 客户端 NTP 配置错误或未指向域控，需统一部署 W32Time 组策略
- 集中出现在某台 Linux 服务器 → 检查其 krb5.conf 中 default_realm 和 dns_lookup_realm 是否正确，避免因 realm 解析失败导致预认证绕过
- 某服务账户频繁触发 4769 失败 → 检查 SPN 是否重复注册（setspn -X）、服务账户密码是否被手动修改但未更新密钥版本（kvno）
- 非管理员账户大量请求 4768 → 结合 Netlogon 日志（5805/5807）排查 Kerberoast 攻击迹象
