kerberos认证因时间差失败是因为协议要求客户端与域控时间偏差不超过5分钟，超时即拒绝票据请求，错误代码如0x80090322；常见于虚拟机、未配ntp的设备或手动改时终端，需通过w32tm/chronyd等工具强制同步并验证源与偏移。

为什么 kerberos 认证会因时间差失败

Kerberos 协议默认要求客户端与域控（DC）时间偏差不超过 5 分钟，超出即拒绝票据请求，错误通常表现为 0x80090322（SEC_E_TIME_SKEW）、KRB_AP_ERR_SKEW 或登录时提示“账户限制”“凭据无效”。这不是网络或密码问题，而是时间戳校验直接失败。

• 时间不同步常见于虚拟机（尤其挂起/恢复后）、未启用 NTP 的嵌入式设备、或手动修改过系统时间的终端
• Windows 域成员默认通过 W32Time 服务从域控同步，但该服务在非活跃状态（如休眠唤醒）可能不自动重连
• Linux 客户端（如 SSSD 或 krb5）若配置了错误的 NTP 源或未启用 ntpd/chronyd，也会累积偏移

Windows 客户端强制立即同步时间

不要依赖后台服务自动修复，出问题时需手动触发并验证：

• 以管理员身份运行命令提示符，执行：

  w32tm /resync /force

• 若报错 The service has not been started，先启动服务：

  net start w32time

• 查看当前同步状态：

  w32tm /query /status

  ，重点关注 Source（应为域控 FQDN）和 Skew（单位毫秒，>300000 即超 5 分钟）
• 若仍不同步，检查防火墙是否放行 UDP 123 端口，以及域控是否允许该客户端作为时间源（w32tm /query /configuration 中 AnnounceFlags 需为 5 或更高）

Linux 客户端（SSSD/Kerberos）时间校准要点

SSSD 本身不处理时间同步，必须确保系统时间已准确：

• 优先使用 chronyd（RHEL8+/Ubuntu 20.04+ 默认）：

  sudo chronyc sources -v

  确认已连接到域控或可信 NTP 源（如 ntp.example.com）
• 若用 ntpd，检查 /etc/ntp.conf 是否包含域控地址，且未被 tinker stepout 0 等配置禁用步进校正
• 手动强制同步：

  sudo chronyc makestep

  （chronyd）或

  sudo ntpdate -s dc01.example.com

  （ntpd，注意该命令在较新系统中已被弃用）
• 验证 Kerberos 时间偏移：

  kinit username@EXAMPLE.COM && klist -v

  ，检查输出中 Valid starting 和 Expires 时间是否与本地 date 一致

域控侧时间源配置不能忽略

客户端时间再准，若域控自身漂移，整个域都会失效：

• 主域控（PDC Emulator 角色持有者）必须指向可靠外部 NTP 源，例如：

  w32tm /config /syncfromflags:manual /manualpeerlist:"time.windows.com pool.ntp.org" /reliable:yes /update

• 运行

  w32tm /resync /force

  后，用

  w32tm /query /peers

  确认已连接成功
• 次要域控应配置为从 PDC 同步，而非直连外部 NTP —— 检查其 Source 是否为 PDC 的主机名，不是 IP 或外部地址
• 虚拟化环境中，务必禁用宿主机时间同步功能（如 VMware Tools 的 “Synchronize guest time with host”），否则会覆盖域时间策略

时间同步不是“设好就完事”的配置，它是个持续生效的链路：域控靠外部 NTP 校准 → 成员机靠域控校准 → 应用（如 Kerberos）按毫秒级时间戳校验。任何一个环节断开或配置冲突，认证就会静默失败。最常被跳过的一步，是确认 PDC Emulator 是否真正在从外部源同步，而不是显示“已配置”却始终连接超时。