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

发表于 分类于 ， 阅读次数： 本文字数： 1.7k 阅读时长 ≈ 6 分钟

问题背景

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

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

故障现象

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

排查过程

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

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

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

1
w32tm /query /status

输出：

1
2
3
4
5
6
7
8
9
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.

而本机时间：

1
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
1
2
3
4
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 的规则：

1
2
3
4
5
策略 → 允许出站 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 更新为当前时间。

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

在受影响机器上：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 先停止 W32Time 服务
net stop w32time

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

# 重启服务
net start w32time

# 强制同步
w32tm /resync /force

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

第四步：通过 GPO 批量修复

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

1
2
3
4
5
6
7
8
$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 分钟的时差就能让整个认证体系瘫痪。