离线一个月后域信任失效？先分清是哪一种

一台笔记本在 VPN 外放置了六周，回来之后用户无法用域账户登录。错误信息提到信任关系，于是有人重置计算机账户，或者干脆强制用户走全隧道，问题似乎就消失了。这两种做法都没有证明到底哪里坏了。Windows 成员完全可以超过通常的机器密码周期继续离线而不自动失去信任，所以第一步是把可达性故障和真正的密钥不一致分开。

错误看着像信任，但有三种状态很相似

用户可能 用缓存的域信息登录，也可能是工作站找不到域控制器，还可能是成员与域对计算机账户的理解确实不一致。严格意义上的信任关系断裂只有第三种。

AD 复制健康状况是第四种观察，而且与这台工作站完全无关。它描述的是域控制器之间是否一致，健康的复制面板并不能证明本机的本地密钥与其计算机账户相符。

人们熟悉的 30 天默认值是一项变更策略，而不是离线过期期限。Microsoft 的 机器账户密码说明 描述了一个协同变更流程，组织也可以配置不同的间隔。

VPN 图标不能证明安全通道如何

任何测试要有意义，连接都必须好到能访问域服务。这包括预期的域 DNS 解析器、可定位的控制器、可达的认证服务，以及足够接近 Kerberos 要求的时钟。

全隧道在这里完全可以是一种合理设计。改用拆分隧道并不是健康域关系的前提，把它当前提会把诊断变成架构变更。查清工作站实际选择了哪个控制器，并把那个名字和错误一起记下来。

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

记录 DNS 服务器、解析到的控制器和准确的错误文本。VPN 客户端报告已连接，只说明隧道存在，不说明域路径可用。控制器在 Kerberos 端口有响应而在目录端口没有响应，那是防火墙的结论，不是信任的结论。

先测试，再修复

在获得授权的 Windows 域成员上，Test-ComputerSecureChannel -Verbose 是对本机与域之间通道的只读检查。要在你正在调查的机器上下文中运行，而不是从域控制器上运行，因为后者角色不同、恢复规则也不同。记录输出和退出状态，而不是通过或失败这样的字眼。如果该版本没有这个 cmdlet，那是模块的另一个问题。

结果仍然需要上下文。如果本机无法访问所选控制器或无法在其上通过认证，那么测试失败并不能独立证明离线密码已过期。保留实际错误和所用控制器，等路径确认可用后再重测。

把事件前后成员与相关控制器上的 Netlogon 事件关联起来。保留计算机名、源地址、时间以及任何账户变更的证据。另一个用户登录成功，或者控制器面板健康，都不能替代这台机器自己的交换过程。

只修复你证明过的那段关系

当连接稳定、管理员也确认修复合适之后，带授权凭据的 -Repair 模式是对成员工作站的一种受支持操作。它会改变关系，并不是又一次只读测试。

变更之前，先准备好经批准的本地恢复账户和管理路径。域控制器承担不同的恢复角色，本流程不应把它们当作普通工作站。要走组织的恢复流程，而不是依次运行好几个重置工具，指望其中一个是正确的。

修复之后，验证一次新的安全通道测试和原先的域操作。保留用户配置文件和应用程序状态，不要把删除后重新加入当成第一个没有解释的动作。

故障复发时该检查什么

如果故障复发，应该查看回滚、重复身份以及账户变更的时间点，而不是再把同一个账户重置一次。恢复的镜像、快照、克隆的机器身份，或者在别处做过的计算机账户重置，都值得调查。

一次暂时成功的重置是有用的恢复证据，但不能证明间歇性 VPN 造成了最初的不一致。下一次复发才会告诉你根因到底有没有被消除。

把控制器、DNS 服务器和测试输出写进工单。正是这份记录，才能把真正的信任故障和只是找不到域的笔记本区分开。