一次Windows域账号批量锁定事件的排查实录
问题背景
某周一早上 8:30 至 9:15 之间，IT 服务台接到大量来电和工单，反映内容相同：**员工账号无法登录 Windows 域，提示”账户已被锁定”**。涉及人数约 45 人，分布在公司多个部门。
AD 域账号锁定策略配置为：5 次错误尝试后锁定，锁定时长 30 分钟。
从工单创建时间来看，锁定事件集中在 8:35 - 8:50 之间。帮助台手工解锁账号后，部分用户反映十几分钟内又被锁定，说明有某个程序或设备在持续使用旧密码尝试认证。
故障现象
- 45 名员工账号显示”已锁定”
- 解锁后部分账号再次被锁定（约 15-20 分钟后）
- 锁定发生时间集中（8:35-8:50），与员工上班开机时间吻合
- 域控服务器安全事件日志中出现大量 Event ID 4740（账号锁定事件）
排查过程
第一步：查看域控安全日志
登录主域控服务器，打开事件查看器 → Windows 日志 → 安全，筛选 Event ID 4740：
关键字段：
- Subject（主体）：域控 PDC（DC01）
- Account Name（被锁定账号）：各被锁定用户的 sAMAccountName
- Caller Computer Name（触发锁定的机器）：APP-SRV-01
所有 45 个账号的锁定来源都指向同一台机器：APP-SRV-01。
第二步：使用 Microsoft Lockout Status 工具确认
下载并使用微软官方工具 LockoutStatus.exe 查看账号锁定详情，可以看到锁定时间和来源 DC，进一步确认了锁定源为 APP-SRV-01。
第三步：排查 APP-SRV-01 上的认证行为
远程登录 APP-SRV-01（Windows Server 2019），查看安全日志中的 Event ID 4776（NTLM 认证失败）和 4625（登录失败）：
1 | 筛选条件：事件 ID = 4625，失败原因 = 用户名或密码不正确 |
发现从 8:33 开始，有一个账号（svc-erp，服务账号）每隔约 2-3 秒就发起一次 NTLM 认证，均以失败告终，失败原因为”密码不正确”。
第四步：为什么 svc-erp 的认证失败会锁定其他账号？
这里需要解释一个 Windows 认证的特殊现象：NTLM 认证时，如果用户名不正确，域控会尝试匹配用户名，匹配失败会计入域内所有同名账号的失败次数。但更直接的原因是：
进一步查看日志，发现这台服务器上的 IIS 应用程序池的标识账号被配置为 svc-erp，且该账号的密码在上周五（1月13日）按照公司密码策略到期，IT 管理员已修改了密码，但忘记同步更新 IIS 应用程序池的密码配置。
每当早上员工上班开机，大量浏览器访问内网 Web 应用，IIS 应用程序池启动，尝试使用旧密码进行认证，在短时间内对 svc-erp 账号发起了数百次认证失败，触发了锁定。
那为什么会锁定其他用户？继续深查……
第五步：发现另一个问题
再仔细分析日志，发现 APP-SRV-01 上还有一个 Windows 计划任务，配置的运行账号是 domain\%USERNAME% 格式的变量，但这个变量在任务运行时解析为了空字符串，导致域控在处理该空用户名认证请求时，对与请求特征相近的账号都计了一次失败（这是一个 Windows 的已知问题，见 KB2949873）。
同时，APP-SRV-01 上还安装了一个第三方监控 Agent，该 Agent 使用了另一个服务账号 svc-monitor，密码也在同一天过期，也没有更新，同样在不停重试认证。
综合来看，三个问题叠加造成了此次大规模账号锁定：
- IIS 应用程序池使用过期密码的
svc-erp服务账号 - 计划任务账号变量解析错误
- 监控 Agent 使用过期密码的
svc-monitor服务账号
解决方案
立即处理：
- 解锁所有被锁定账号（通过 PowerShell 批量解锁）：
1 | # 批量解锁 AD 中所有被锁定的账号 |
- 更新 IIS 应用程序池密码：
在 APP-SRV-01 上打开 IIS 管理器 → 应用程序池 → 选择对应的应用程序池 → 高级设置 → 标识 → 更新为新密码，然后重启应用程序池。
- 修复计划任务账号配置：
将计划任务的运行账号改为明确的域账号，而不是变量。
- 更新监控 Agent 配置：
在 Agent 配置文件中更新 svc-monitor 的新密码，重启 Agent 服务。
重启相关服务后，账号不再反复锁定，验证修复成功。
长期处理：
使用 托管服务账号（gMSA，Group Managed Service Account） 替换普通服务账号：
1 | # 创建 gMSA |
gMSA 的密码由 AD 自动管理和轮换，无需手动更新，从根本上避免服务账号密码过期问题。
根因分析
根本原因是服务账号密码策略管理不规范：普通域账号的密码到期策略同样应用到了服务账号上，修改密码后没有同步更新所有使用该账号的服务配置，导致服务使用旧密码反复认证，最终触发大规模账号锁定。
预防措施
1. 服务账号使用 gMSA 或 sMSA
彻底解决密码手动管理问题，AD 自动轮换密码，服务不感知。
2. 服务账号设置”密码永不过期”（次优方案）
如果暂时无法迁移到 gMSA，可对服务账号单独设置”密码永不过期”，避免自动过期触发问题。但这属于临时方案，存在安全风险。
3. 密码变更 SOP
修改服务账号密码时，必须同步检查所有使用该账号的服务/应用/计划任务，逐一更新。建立服务账号使用台账，记录每个服务账号被哪些服务使用。
4. 账号锁定告警
在 SIEM 或监控系统中配置 Event ID 4740 告警，当锁定数量在 10 分钟内超过阈值（如 5 个以上）时立即通知运维，快速定位来源机器。
总结
账号批量锁定事件看起来是个用户问题，实际上根源在于服务侧的配置管理疏漏。一个看不见的服务账号在后台不停地用错误密码敲门，却殃及了数十名员工的正常工作。
这次事件之后，我们对公司所有服务账号做了全面梳理，整理了台账，并推进了核心系统服务账号向 gMSA 的迁移。事实证明，这类”基础设施维护”的工作，往往是避免大故障的关键。