时间差几分钟，域就登不上了
Kerberos 在票据里带时间戳，客户端与域控时钟相差超过默认容忍范围（约 5 分钟）就会拒绝认证，表现是登录报错、访问共享失败、复制报错，而网络其实完全正常。这类问题的特点是「只影响一部分机器」：虚拟机上常见，物理机长期不开机也常见。排查关键不是反复输入密码，而是先把时间对齐，再处理根因。
基本信息
| 适用平台 | Windows 域环境（客户端与域控） |
|---|---|
| 容忍范围 | Kerberos 默认允许约 5 分钟偏差，超出即认证失败 |
| 时间层级 | 客户端信任本域域控，域控信任上级，林根域的 PDC 才向外部时间源同步 |
| 检查命令 | w32tm /query /status、w32tm /stripchart、w32tm /monitor |
| 修复命令 | w32tm /resync /force；域控侧配置外部源 |
| 相关服务 | Windows 时间服务（W32Time）必须处于运行状态 |
典型使用场景
- 登录失败排障：报错提到时间、Kerberos、时钟偏差时先查时间
- 虚拟机异常：克隆或恢复快照后时间漂移，认证大面积失败
- 复制异常：域控间时间不一致连带引发复制与认证问题
- 日志时间线错乱：多台机器日志对不上，先统一时间再谈取证
- 合规检查：确认林根 PDC 已配置可靠外部时间源并记录偏差
常用示例
常用示例
w32tm /query /status # 当前时间服务状态：源、上次同步结果、层级
w32tm /query /source # 当前使用的时间源
w32tm /stripchart /computer:dc01.corp.local /samples:5 # 与本机最接近的域控比对偏差
w32tm /resync /force # 立即强制同步一次
w32tm /monitor # 查看域内各域控的时间层级与偏差
Get-Date # 本机时间
REM 在域控上确认时间源配置
REM w32tm /query /configuration
REM 林根 PDC 配置外部时间源示例（需按环境选择可用 NTP 源）
REM w32tm /config /manualpeerlist:"ntp1.example.com,0x9 ntp2.example.com,0x9" /syncfromflags:manual /reliable:yes /update
REM w32tm /config /update && net stop w32time && net start w32time现象与原因对照
| 现象 | 常见原因 | 处置方向 |
|---|---|---|
| 登录报认证或时间错误 | 客户端与域控时间差超过容忍范围 | 先 resync 到域控，再查客户端时间源 |
| 虚拟机上反复漂移 | 宿主时间同步集成与系统时间服务冲突 | 二选一，统一由域时间链管理 |
| 多台机器同时异常 | 上级域控或 PDC 时间源错误 | 从林根 PDC 向下逐级核查 |
| 复制与认证一起报错 | 域控之间时钟不一致 | 对齐域控时间并检查时间源配置 |
| 开机时间明显落后 | 主板电池老化或虚拟化快照回滚 | 换电池或重新同步并确认虚拟机时间策略 |
域环境的时间是单向信任链：客户端跟随本域域控，域控跟随上层，最终由林根域的 PDC 角色去同步外部时间源。只对客户端反复执行同步、不修上级，问题会不断复发。
虚拟机容易出现双重时间源：宿主的时间同步集成与系统内的 Windows 时间服务同时生效，时钟会来回跳，表现为时快时慢。规范做法是由域时间链统一管理，关闭宿主侧的强制时间同步。
核对与验证
核对与验证
w32tm /query /status | Select-String -Pattern '源|Source|上次同步|Last' # 同步状态
w32tm /stripchart /computer:dc01.corp.local /samples:3 -dataonly # 只看偏差数值
Get-Service w32time | Select-Object Name, Status, StartType # 时间服务是否运行
Compare-Object (Get-Date) (Invoke-Command -ComputerName DC01 { Get-Date }) # 与域控时间直接对比
Get-WinEvent -LogName System -MaxEvents 50 | Where-Object ProviderName -like '*Time*' # 时间服务相关事件不要手工把域控时间「改对」了事：域控参与复制与时间权威，手工调整可能在域内引入不一致，正确做法是配置时间源并让其正常同步；同时 Kerberos 失败往往还会触发账号锁定，处置期间要留意锁定计数。