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 是否真正在从外部源同步，而不是显示“已配置”却始终连接超时。
