解决 Windows instance 时间不同步问题

解决OpenStack Windows实例时间偏差
本文介绍了解决OpenStack环境中Windows实例系统时间总是慢8小时的问题。提供了两种解决方案:一是给Windows镜像添加os_type属性;二是直接修改数据库中已部署实例的os_type属性。

 

这是 OpenStack 实施经验分享系列的第 3 篇。


问题描述


通过上一节部署出来的 Windows instance 有时候会发现操作系统时间总是慢 8 个小时,即使手工调整好时间和时区,下次 instance 重启后又会差 8 个小时。


原因


KVM 对 Linux 和 Windows 虚拟机在系统时间上处理有所不同,Windows 需要额外一些设置。


解决办法一


给 Windows 镜像添加 os_type 属性。

glance image-update --property os_type="windows" <IMAGE-ID>

明确指定这就是一个 windows 镜像。通过此镜像部署 instance 的时候,KVM 会在其 XML 描述文件中设置相应参数,保证时间的同步。


解决办法二


对于之前部署的 Windows instance,用第一种方法就没有效果了,只能采取一点非常规手段:Hack Database!


假设要 hack 的 instance 的名字是 win-test,用下面的 MySQL 命令:


$ use nova;

$ update instances set os_type='windows' where hostname='win-test';

$ select hostname,os_type from instances where hostname='win-test';

+------------+----------+

| hostname  | os_type  |

+------------+----------+

| win-test     | windows |

+------------+----------+


需要重启 win-test,KVM 会获取修改后的数据库信息,更新 XML 配置,保证时间同步。


下一节继续讨论镜像使用上的经验和技巧。


<think>嗯,用户问的是Windows AD服务器中部分用户访问异常怎么解决。这个问题看起来有点复杂,首先我得理清楚可能的原因。AD服务器问题通常涉及多个方面,比如网络、DNS、用户账户状态、组策略、权限、时间等等。用户提到是部分用户有问题,所以可能需要排除是不是特定用户组或OU的问题。 首先,我应该考虑网络连通性。如果部分用户无法访问,可能是他们的客户端到域控制器之间的网络有问题。需要检查是否能ping通域控制器,端口是否开放,尤其是LDAP需要的389和636,还有Kerberos的88端口。不过用户可能没有权限直接测试端口,可能需要指导他们联系网络管理员。 然后是DNS问题。AD严重依赖DNS,如果客户端的DNS设置不正确,或者域控制器的SRV记录有问题,会导致认证失败。这时候需要检查客户端的DNS配置是否正确指向AD的DNS服务器,以及nslookup是否能解析到正确的域控制器。 接下来是用户账户状态。检查这些用户账户是否被锁定、禁用,或者密码是否过期。另外,账户可能被移动到不同的OU,应用了不同的组策略,导致权限变化。需要查看事件查看器里的安全日志,看看有没有相关的登录失败事件,比如错误代码,像4768、4771这样的Kerberos错误。 时间也是一个常见问题。AD要求客户端和服务器的时间差不超过5分钟,否则Kerberos认证会失败。需要检查客户端的时间设置是否正确,是否同了域控制器的时间。 组策略的问题也不能忽视。如果这些用户所在的OU应用了有问题的GPO,可能会导致登录问题。可以用gpresult看看应用了哪些策略,或者用组策略建模来模拟策略应用情况。 还有SID冲突的可能性,虽然比较少见,但如果用户账户被误复制,可能会有重复的SID,导致权限混乱。不过这种情况在正常管理下应该不会发生。 另外,复制问题在多域控制器环境中可能出现。如果某个域控制器没有及时同,用户登录时可能连接到不同的DC,导致凭据问题。需要检查AD复制状态,用repadmin命令查看是否有复制错误。 最后,建议分骤排查:从网络和DNS开始,然后检查账户状态、时间,接着看组策略和权限,最后考虑AD复制和SID问题。如果用户有备份的话,恢复用户账户或系统状态也是一个选项,但可能需要更高级的权限和操作。 可能需要提醒用户,如果这些骤无法解决,可能需要深入分析日志或联系微软支持。同时,确认用户是否有足够的权限去执行这些检查,或者是否需要联系IT部门协助。</think>### Windows AD服务器部分用户访问异常排查指南 --- #### **一、初定位问题范围** 1. **确认异常特征**: - 异常用户是否集中在特定组织单元(OU)或用户组? - 报错现象是登录失败、权限丢失还是资源访问被拒? - 错误代码(如 `0xC0000064`, `0xC0000234`)是否有规律? 2. **检查基础服务状态**: - 打开 **事件查看器** → **Windows日志** → **系统/安全日志**,过滤 `Kerberos`、`NTDS` 相关事件。 - 确认域控制器(DC)的 **Netlogon**、**DFS Replication** 等服务是否正常运行。 --- #### **二、网络与DNS排查** 1. **客户端网络连通性**: - 让异常用户执行 `ping <DC_IP>` 测试延迟和丢包。 - 检查防火墙是否放行以下端口: - Kerberos: **TCP/UDP 88** - LDAP: **TCP 389(明文)**、**TCP 636(SSL)** - Global Catalog: **TCP 3268/3269** 2. **DNS配置验证**: - 客户端DNS必须指向AD集成的DNS服务器。 - 执行命令验证SRV记录: ```powershell nslookup -type=SRV _ldap._tcp.dc._msdcs.<域名> ``` --- #### **三、用户账户与策略检查** 1. **账户状态排查**: - 打开 **AD用户和计算机** → 检查异常用户属性: - 账户是否被禁用(√选 **Account is disabled**)? - 密码是否过期(**Password never expires** 是否勾选)? - 登录时间限制(**Logon Hours**)是否生效? 2. **组策略影响分析**: - 在客户端执行命令生成策略报告: ```cmd gpresult /h report.html ``` - 检查是否应用了限制性策略(如 **软件限制策略** 或 **登录脚本错误**)。 --- #### **四、Kerberos时间** 1. **时间偏差问题**: - 客户端与DC时间差超过 **5分钟** 会导致Kerberos票据失效。 - 强制同时间: ```cmd w32tm /resync /force ``` 2. **票据缓存清理**: - 让用户清理Kerberos票据: ```cmd klist purge ``` --- #### **五、高级故障排查** 1. **AD复制状态检查**: - 在域控制器执行命令验证复制健康状态: ```powershell repadmin /replsummary ``` - 若发现复制错误,使用 `repadmin /syncall` 强制同。 2. **SID冲突检测**: - 使用 **PsGetSid** 工具检查异常用户SID是否重复: ```cmd PsGetSid <用户名> ``` --- #### **六、恢复方案** 1. **临时应急措施**: - 重置用户密码并解除锁定。 - 将用户移动到默认OU,避开冲突策略。 2. **系统级修复**: - 使用 **NTDSUTIL** 工具修复AD数据库: ```cmd ntdsutil "activate instance ntds" "files" "integrity" quit quit ``` - 从备份还原用户账户或系统状态(需提前验证备份有效性)。 --- #### **总结骤** 1. 优先排除网络/DNS问题; 2. 验证账户状态与组策略; 3. 检查时间与Kerberos票据; 4. 深入排查AD复制与数据库健康; 5. 必要时联系微软支持(提供 `MSINFO32` 报告和日志)。 > **注意**:涉及AD架构修改的操作需在测试环境验证后执行,避免生产环境连锁故障。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值