ad域控制器cpu负载过高本质是外部压力传导致lsass响应延迟，引发kerberos认证失败、ldap超时等；需通过get-counter和get-process确认cpu瓶颈，结合事件id 1644/5719/5807定位诱因，重点排查低效ldap查询、复制积压、spn冲突及edr扫描四类主因，并采取限流、重置netlogon、启用dc定位器策略值2等措施缓解。
ad域控制器cpu负载过高，核心问题往往不是kdc或lsass自身出错，而是外部压力传导导致服务响应延迟，继而引发kerberos认证失败、ldap查询超时、netlogon异常等连锁反应。排查需聚焦“谁在压垮lsass”和“为什么压垮”，而非仅看cpu数字。
确认是否真存在CPU瓶颈
先排除误判：高CPU未必等于业务受损，但持续高于85%且伴随认证异常，就需介入。
- 运行Get-Counter '\Processor(_Total)\% Processor Time' -SampleInterval 1 -MaxSamples 10，观察均值是否稳定超标
- 执行Get-Process lsass -IncludeUserName，确认LSASS的CPU占用是否显著高于其他进程（如长期＞70%）
- 检查系统日志中是否高频出现事件ID 1644（LDAP返回超5000条）、5719（找不到DC）、5807（NO_CLIENT_SITE）——这些是CPU过载的典型伴生信号
重点排查LSASS高负载的四大诱因
LSASS本身不主动消耗大量CPU，它的高负载几乎全是被“带偏”的。以下四类情况占实际案例九成以上：
-
低效LDAP查询泛滥：客户端未加过滤条件的全量搜索（如
(objectClass=user)）、频繁DC定位请求（每秒多次LDAP ping），会快速耗尽ATQ线程池，拖慢所有依赖LSASS的服务 - AD复制或Netlogon积压：跨站复制失败、FSMO角色争用、RPC重试队列堆积，会让LSASS持续处理失败重试逻辑，CPU居高不下
- SPN冲突或PAC验证开销大：重复注册SPN、用户所属安全组超1000个、启用了强PAC签名验证，每次TGS-REQ都要做完整权限计算与加密运算
- 第三方扫描或EDR过度干预：某些终端防护软件对LSASS内存区域进行高频Hook或扫描，或通过WMI持续轮询安全日志，直接触发内核级上下文切换开销
快速定位与缓解措施
不建议直接重启LSASS或域控。优先用轻量手段隔离问题源：
- 用netsh trace start scenario=NetConnection capture=yes捕获短时网络行为，识别异常LDAP/TCP连接源IP
- 临时重置Netlogon服务：net stop netlogon && net start netlogon，可清空RPC积压并重置DC定位缓存
- 启用DC定位器策略值2：reg add "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v DcLocatorExtraFlag /t REG_DWORD /d 2 /f，强制客户端使用更稳定的定位方式，减少无效尝试
- 若确认是某类客户端批量行为（如脚本、旧应用），可在防火墙或AD站点边界限流，或为其指定专用只读DC分流
