你的 Mac 通过 RDP 发送了错误的 Windows 账户

隧道重新连接，Mac 再次到达办公网络，而远程桌面仍然返回登录失败。这个错误不是 VPN 的。隧道只是把 Mac 接入获批的网络；登录远程计算机的是 Windows 账户，而连接条目可能一直在发送你几个月前就停用的账户。

先查看这个条目，再动钥匙串。

VPN 账户和 Windows 账户是两回事

VPN 身份只向隧道网关认证设备或人。它不说明远程主机会接受哪个 Windows 账户，也无法替代后者。当隧道健康而桌面拒绝登录时，问题已经越过了网络层。把这两次认证当作彼此独立、日志也各自独立的事件。网关可能显示会话正常，而 Windows 安全日志却记录了一次原因完全不同的登录失败。

假设管理员让你使用 EXAMPLE\alex，而保存的条目仍在选择一个不带域名的 alex。它们是不同的账户。不带限定的名称会按远程计算机的本地账户解析，在加入域的机器上，它可能根本无法解析到域身份。

因此，去掉域前缀并不是通用的修复。它改变了所请求的账户，可能产生一种看起来像密码问题的拒绝，而密码从来都不是问题。

打开连接条目，而不是整个钥匙串

在当前的 macOS 版 Windows App 中，在“设备”下找到那台远程 PC，打开它的“编辑”操作，查看绑定到该条目的账户。应用提供已保存凭据的控件，可以选择另一个已保存账户，或移除过期的账户。这才是受支持的修正选择的位置。一次只改一个属性，这样你才知道究竟哪次修改起了作用。同时修改凭据和主机名，会得到一个谁也归因不了的结果。

不要一上来就删除钥匙串里所有名称包含服务器名的条目。钥匙串条目在各应用之间共享，大范围删除可能移除无关的访问权限，却对 Windows 一侧毫无改变。它还会毁掉证据——如果真正的问题其实是主机名、路由或 RDP 服务，你会需要这些证据。

如果同一条已保存凭据被多台远程 PC 使用，删除前先检查这些依赖关系。编辑单台 PC 的条目是可逆的；删除共享凭据则是影响范围更大、审计痕迹更差的改动。

使用管理员提供的账户形式

按签发时的原样输入账户，采用环境期望的形式：NetBIOS 风格的域用 DOMAIN\user；如果目录使用用户主体名称，就用 user principal name。然后把它保存到这台 PC，并做一次有意识的连接尝试。

留意登录提示显示的是哪个账户。如果提示里已经是另一个名字，说明保存的选择没有被替换，你刚才的尝试测的还是旧凭据。

不要把密码留在便签、工单和截图里。改为记录账户名和确切的错误代码，因为代码能区分凭据错误、策略拒绝、密码过期，以及根本不接受 RDP 的机器。

登录之前的连接失败是另一种故障

如果查看器在任何 Windows 登录出现之前就失败，凭据不是嫌疑对象。检查主机名能否解析、隧道上是否存在到主机的路由，以及 RDP 服务是否在监听。从未建立的 TCP 连接永远到不了账户层。

反过来，明确的账户拒绝并不能证明 DNS 坏了，也不能证明应当放宽证书校验。这类改动会削弱连接，通常还会让拒绝原封不动地留在原处。

用尽可能小的步骤测试：确认端口可达、确认登录提示出现、确认显示的账户就是你要的，然后再输入密码。每一步都有各自的失败和各自的修法。

不要动自动重连

自动重连会复用现有条目，包括其中保存的账户。它是便利功能，不是凭据修复，所以关掉它不会修正错误的选择，打开它也不会造出一个选择。如果条目现在保存的是正确账户，重连就会用它。

保存修正后的条目，手动连接一次，并记下哪个账户成功了。正是这一行，让下一个人的诊断只需五分钟，而不是花一下午在钥匙串里考古。