Active Directory on Zero Day Notes

一次NTP时间同步异常导致Kerberos认证全部失效的排查实录

Mon, 14 Jul 2025 09:15:00 +0000

问题背景

某周一上午 9 点左右，公司 IT 服务台接到多起投诉：员工无法访问共享文件夹（\\fileserver\share），访问内网系统提示"用户名或密码不正确"，即使重新输入正确密码仍无法登录。部分员工的 Outlook 也无法连接 Exchange，提示需要重新输入密码。

受影响人数约 60 人，分布在不同楼层，但有一个共同点：周末期间他们的电脑一直保持开机状态（服务器机房和少量长期开机的办公室电脑）。

故障现象

访问共享文件夹报错：登录失败：目标账户名不正确
Outlook 提示凭据错误，无法连接 Exchange
部分系统登录时报：此计算机上的时钟与主域控制器上的时钟不同步
klist 命令查看 Kerberos 票据，显示无法获取票据：KRB5KRB_AP_ERR_SKEW: Clock skew too great

排查过程

第一步：注意到时间错误提示

一位细心的用户截图发给 IT，截图中包含了一行小字：此计算机上的时钟与主域控制器上的时钟不同步。这个提示是关键线索。

在一台受影响的机器上查看系统时间：

`1`	`w32tm /query /status`

输出：

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x00000000
Last Successful Sync Time: 7/11/2025 11:30:45 PM
Source: time.windows.com
Poll Interval: 17 (131072s)

关键发现：Last Successful Sync Time 是 7月11日（周五晚上），已经 3 天没有同步！

再看当前时间与域控的差异：

`1`	`net time \\dc01`

输出：

1
2

Current time at \\DC01 is 7/14/2025 9:23:15 AM
The command completed successfully.

而本机时间：

time /t

`1`	`09:17:42`

本机时间 09:17，DC 时间 09:23，差了约 6 分钟，超过了 Kerberos 允许的最大时间偏差（5 分钟）。

第二步：Kerberos 时间敏感性原理

Kerberos 协议要求客户端和 KDC（Key Distribution Center，通常是域控）之间的时间差不超过 5 分钟（由 MaxClockSkew 参数控制，默认值 5 分钟）。这是 Kerberos 防止重放攻击的安全机制。

当时间偏差超过 5 分钟时：

客户端申请 Kerberos 票据（TGT）时，KDC 会拒绝请求，返回 KRB5KRB_AP_ERR_SKEW
所有依赖 Kerberos 的服务认证失败，包括：共享文件夹访问、Exchange、域控登录、GPO 应用等

第三步：追查 NTP 同步失败的原因

受影响的机器理论上应该从域控同步时间（域成员机器默认时间源是域控）。检查这些机器为什么没有同步：

`1`	`w32tm /query /configuration`

输出发现这台机器的 NTP 源被手动配置为了 time.windows.com（外网 NTP 服务器），而不是使用域的自动配置（NT5DS，从域层次结构同步）。

继续查看其他受影响机器，发现大部分受影响机器的 NTP 配置有问题，要么被手动改过，要么因为某个组策略没有正常应用而导致 NTP 源配置不正确。

进一步查看域控本身的 NTP 配置：

1
2

# 在 DC01 上执行
w32tm /query /status

Leap Indicator: 3(not synchronized)
Stratum: 0 (unspecified)
Last Successful Sync Time: 7/11/2025 11:28:13 PM
Source: ntp.aliyun.com

域控本身也没有同步！ 域控的上游 NTP 服务器（ntp.aliyun.com）从周五晚上开始就无法访问了。

第四步：排查为什么 NTP 服务器不可达

`1`	`ping ntp.aliyun.com`

`1`	`Request timeout for icmp_seq 0`

无法 ping 通。检查防火墙日志，发现周六白天运维团队在做例行防火墙策略清理时，误删了一条允许 UDP 123（NTP 协议端口）出站的规则，导致所有机器无法向外部 NTP 服务器同步时间。

由于周末无人值班，这个问题持续了 2 天多，域控的时间逐渐漂移，到周一早上已经偏差 6 分钟，触发了 Kerberos 认证失败。

完整的故障链： 防火墙误删 UDP 123 规则 → NTP 同步失败 → 域控时间漂移 → 域成员机器时间偏差超 5 分钟 → Kerberos 认证失败 → 大量服务不可访问

解决方案

第一步：恢复防火墙 NTP 规则

在 FortiGate 防火墙上重新添加允许出站 UDP 123 的规则：

策略 → 允许出站 NTP
Source: Internal_Network
Destination: All
Service: NTP (UDP 123)
Action: Accept

第二步：强制域控同步时间

1
2

# 在 PDC（主域控制器）上执行
w32tm /resync /force

等待同步完成：

`1`	`w32tm /query /status`

验证 Last Successful Sync Time 更新为当前时间。

第三步：强制受影响机器同步

在受影响机器上：

# 先停止 W32Time 服务
net stop w32time

# 注册并重新配置为域同步
w32tm /unregister
w32tm /register

# 重启服务
net start w32time

# 强制同步
w32tm /resync /force

# 验证
w32tm /query /status
net time \\dc01

第四步：通过 GPO 批量修复

对于大量受影响机器，通过 PowerShell 远程批量执行：

$computers = (Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=company,DC=com").Name
Invoke-Command -ComputerName $computers -ScriptBlock {
    Stop-Service w32time -Force
    w32tm /unregister
    w32tm /register
    Start-Service w32time
    w32tm /resync /force
}

处理完成后，相关 Kerberos 错误消失，服务全部恢复正常。

根因分析

根本原因是防火墙变更管理不规范，例行清理操作误删了 NTP 出站规则，且该变更没有经过充分测试和验证，也没有回滚计划。NTP 时间同步失败属于"慢性"故障，不会立即触发告警，而是在时间漂移积累到一定程度后才爆发。

次要原因是缺乏 NTP 同步状态的监控，如果有监控在 NTP 同步失败时立即告警，可以在几小时内发现并修复，而不是等到周一早高峰才被动发现。

预防措施

1. NTP 同步状态监控

在 Zabbix 中添加监控项，监控关键服务器（尤其是域控）的时间同步状态和时间偏差，超过 60 秒偏差时告警：

1
2

# Zabbix Agent 自定义 UserParameter
UserParameter=ntp.offset,w32tm /query /status | grep "Phase Offset" | awk '{print $3}'

2. 防火墙变更双人复核

所有防火墙策略变更必须经过运维负责人审核，变更后验证关键服务（DNS、NTP、AD认证）的可用性。

3. 保留 NTP 备用内网服务器

在内网部署一台 NTP 服务器作为备用，即使出口 NTP 不可达，内网机器也可以从内网 NTP 服务器同步时间。

总结

NTP 是 AD 域环境中"沉默的基础设施"，平时无人关注，一旦出问题却能引发连锁反应。这次事故让我们深刻认识到：越是基础的服务，越需要完善的监控。时钟同步听起来不重要，但在 Kerberos 的世界里，6 分钟的时差就能让整个认证体系瘫痪。

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

Mon, 16 Jan 2023 09:00:00 +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 的迁移。事实证明，这类"基础设施维护"的工作，往往是避免大故障的关键。