kerberos认证超时若源于域控cpu负载过高，本质是kdc服务（运行在lsass.exe进程中）无法及时响应as-req或tgs-req请求，表现为连接缓慢、反复重试、报错0x80090322或kerb_ap_err_skew，实为高cpu导致响应延迟被误判为时间偏移；需通过get-counter和get-process确认cpu及lsass占用，排查ldap查询、复制积压、spn冲突或edr扫描等诱因，并采取限流、重置netlogon、启用dc定位器策略值2等措施缓解。
kerberos认证超时若源于域控cpu负载过高，本质是kdc服务（运行在lsass.exe进程中）无法及时响应as-req或tgs-req请求。此时客户端常表现为连接缓慢、反复重试、最终报错0x80090322（时间偏移）、kerb_ap_err_skew，甚至触发事件id 4768失败但日志中无明显网络错误。关键要区分是“真超时”还是“假时间不同步”——后者往往是高cpu导致响应延迟，使客户端误判为时间偏差。
确认域控是否存在CPU瓶颈
登录域控制器，打开任务管理器或使用PowerShell快速验证：
- 运行Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 10，观察是否持续高于85%
- 检查Get-Process lsass -IncludeUserName，确认lsass.exe CPU占用是否异常突出（如长期>70%）
- 查看系统日志中是否有事件ID 1644（LDAP查询返回超过5000条结果）、事件ID 5719（找不到DC）或Netlogon警告5807（NO_CLIENT_SITE），这些常与CPU过载并发
定位高负载的直接诱因
CPU飙升很少是KDC本身逻辑问题，多由外部压力传导所致：
- 大量低效LDAP查询：如未加过滤条件的全量用户搜索、客户端频繁发起DC定位（LDAP ping），会耗尽ATQ线程池，连带拖慢Kerberos响应
- 复制积压或Netlogon RPC堆积：AD复制失败或跨站同步延迟，会导致lsass持续处理重试请求
- SPN冲突或PAC验证开销大：当用户所属组数量极多（如超1000个）、或存在重复/错误SPN，每次TGS-REQ都要做完整权限计算和签名验证，显著增加CPU负担
- 第三方安全软件扫描lsass内存：某些EDR产品对lsass.exe进行实时行为分析，造成严重性能干扰
快速缓解与验证方法
不重启DC的前提下，优先隔离负载源并验证效果：
- 临时限制非关键客户端访问：通过防火墙规则或组策略禁用部分OU的Kerberos策略（如降低票据有效期），观察CPU是否回落
- 运行net stop netlogon && net start netlogon重置Netlogon服务（注意：此操作会短暂中断信任关系，建议窗口期执行）
- 使用ldp.exe连接本机127.0.0.1:389，执行简单bind测试，若响应明显变快，说明外部网络请求是主因
- 客户端侧可尝试kinit -V username@DOMAIN.COM并抓包，对比AS-REQ发出到收到AS-REP的时间差；若延迟集中在域控IP响应段，而非DNS或路由环节，则基本锁定DC侧问题
长效优化要点
避免同类问题复发，需从架构和配置入手：
- 为高频查询类应用配置专用只读全局编录服务器（ROGC），分流KDC主负载
- 在域控制器组策略中启用“指定地址查找行为进行DC定位器ping”，设为值2（仅DNS查找），防止NetBIOS广播等低效解析拖垮ATQ线程池
- 定期清理无效SPN：setspn -X检测重复项，setspn -D删除冗余注册
- 对大型组成员关系启用“通用组成员身份缓存”（Universal Group Membership Caching），减少每次登录时的跨域查询开销
