记一次 Windows 域账号批量锁定事件的排查

Mon, 16 Jan 2023 20:56:36 +0000

问题背景

某周一早上 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
2

筛选条件：事件 ID = 4625，失败原因 = 用户名或密码不正确
时间范围：08:00 - 09:00

发现从 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
2
3

# 批量解锁 AD 中所有被锁定的账号
Import-Module ActiveDirectory
Search-ADAccount -LockedOut | Unlock-ADAccount -PassThru | Select-Object Name, DistinguishedName

更新 IIS 应用程序池密码：

在 APP-SRV-01 上打开 IIS 管理器 → 应用程序池 → 选择对应的应用程序池 → 高级设置 → 标识 → 更新为新密码，然后重启应用程序池。

修复计划任务账号配置：

将计划任务的运行账号改为明确的域账号，而不是变量。

更新监控 Agent 配置：

在 Agent 配置文件中更新 svc-monitor 的新密码，重启 Agent 服务。

重启相关服务后，账号不再反复锁定，验证修复成功。

长期处理：

使用 托管服务账号（gMSA，Group Managed Service Account） 替换普通服务账号：

# 创建 gMSA
New-ADServiceAccount -Name "gMSA-ERP" -DNSHostName "app-srv-01.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "APP-SRV-01$"

# 在目标服务器上安装 gMSA
Install-ADServiceAccount -Identity "gMSA-ERP"

gMSA 的密码由 AD 自动管理和轮换，无需手动更新，从根本上避免服务账号密码过期问题。

根因分析

根本原因是服务账号密码策略管理不规范：普通域账号的密码到期策略同样应用到了服务账号上，修改密码后没有同步更新所有使用该账号的服务配置，导致服务使用旧密码反复认证，最终触发大规模账号锁定。

预防措施

1. 服务账号使用 gMSA 或 sMSA

彻底解决密码手动管理问题，AD 自动轮换密码，服务不感知。

2. 服务账号设置"密码永不过期"（次优方案）

如果暂时无法迁移到 gMSA，可对服务账号单独设置"密码永不过期"，避免自动过期触发问题。但这属于临时方案，存在安全风险。

3. 密码变更 SOP

修改服务账号密码时，必须同步检查所有使用该账号的服务/应用/计划任务，逐一更新。建立服务账号使用台账，记录每个服务账号被哪些服务使用。

4. 账号锁定告警

在 SIEM 或监控系统中配置 Event ID 4740 告警，当锁定数量在 10 分钟内超过阈值（如 5 个以上）时立即通知运维，快速定位来源机器。

总结

账号批量锁定事件看起来是个用户问题，实际上根源在于服务侧的配置管理疏漏。一个看不见的服务账号在后台不停地用错误密码敲门，却殃及了数十名员工的正常工作。

这次事件之后，我们对公司所有服务账号做了全面梳理，整理了台账，并推进了核心系统服务账号向 gMSA 的迁移。事实证明，这类"基础设施维护"的工作，往往是避免大故障的关键。

域控 on Zero Day Notes