家里那台 Windows 台式机，前段时间 Win 11 系统更新失败，只好重装。重装之前，用微软账户从 Mac 远程桌面连它一直好好的；重装之后，机器名、账户、网络、客户端一样都没变，连过去却永远是一句冷冰冰的 “The credentials did not work”。
诡异的是，家里另外两台老机器，同样走 Tailscale、同样的客户端，一切正常。同一个微软账户、正确的密码（网页登录验证过）、机器上 whoami /upn 也确认登录的就是这个账户——所有环节单独看都是对的，合起来就是连不上。而这套组合在重装前的旧系统上明明跑了很多年。
折腾了一个下午，最后发现罪魁祸首竟然是 Windows 一个标着"推荐"的新安全开关：“为了提高安全性，仅允许对此设备上的 Microsoft 账户使用 Windows Hello 登录”。这篇文章记录完整的排查过程，以及这个开关如何在不动声色之间，把 RDP + 微软账户这个再标准不过的场景整个废掉。
第一现场：错误码比报错对话框诚实
Windows App（原 Microsoft Remote Desktop）在 Mac 上的日志藏在：
1 | ~/Library/Containers/com.microsoft.rdc.macos/Data/Library/Logs/Windows App/*.log |
里面反复出现的是这一段：
1 | RDPSECURITYFILTER(ERR): Caught a SecFilterException during handshake: |
-1073741715 换算成十六进制是 0xC000006D——Windows NT 状态码里的 STATUS_LOGON_FAILURE，“用户名或密码错误”。
这条日志排除了一个大方向：网络没有问题。TCP、TLS、NLA 握手全部完成，失败发生在凭据验证阶段——是服务器（那台 Windows）主动拒绝了这组凭据，而不是连不上。
嫌疑人一个个排除
嫌疑人一：用户名格式。 用微软账户连 RDP 的经典坑是用户名可能要写成 MicrosoftAccount\<username>@outlook.com 而不是裸邮箱。改了，没用。
嫌疑人二：密码。 无密码（passwordless）账户无法做网络登录；输错、输入法全角字符也是常见翻车点。用无痕浏览器在 account.microsoft.com 验证过密码有效，而且密码本来就是纯 ASCII。排除。
嫌疑人三：账户搞混了。 机器上 quser 显示的登录用户名是一串从邮箱截短而来的 SAM 短名（微软账户都会生成这么一个本地名），whoami /upn 输出的正是那个 outlook 邮箱——没搞混。
嫌疑人四：权限。 "远程桌面用户"组加过了。但注意 0xC000006D 发生在凭据校验阶段，还没走到权限检查——权限不足会是另一种错误。这个方向本身就是死路。
一个假线索。 我让那台机器用 mstsc 连 localhost 做对照测试，结果弹了个"无法连接到另一个控制台会话"——这是登录成功之后的会话冲突，我一度据此认为"凭据本身没问题"。后来才意识到这个测试是无效的：mstsc 连本机时会直接用当前已登录会话的凭据做单点登录，根本没走"输入密码 → 验证"这条路。凡是看起来太顺利的对照实验，先怀疑实验本身。
转折点：换一台 Windows 也连不上
在另一台 Windows 机器上用 mstsc 连这台新装系统的机器，同样失败。这一下把"Mac 客户端问题"和"密码输入问题"两条线全部杀死——问题确定在这台机器对网络登录的处理上。
于是请出服务器端的第一手记录：Windows 安全审计日志里的登录失败事件（Event ID 4625）：
1 | Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} -MaxEvents 5 | |
这份日志一次给出了两个关键发现。
审计日志的双重真相
4625 事件里除了状态码 0xC000006D，还有一个子状态码（Sub Status），它才是拒绝的真正原因。对比从两台不同客户端发起的失败：
来自另一台 Windows（mstsc）：
1 | 登录失败的账户: |
来自 Mac（Windows App）：
1 | 登录失败的账户: |
两个独立的问题同时浮出水面：
-
Mac 上的 Windows App 不拆分
域\用户名。 mstsc 会把MicrosoftAccount\<username>@outlook.com拆成"域 + 用户名"两个字段发送，Mac 客户端把整串当成一个用户名原样发过去，服务器去找一个字面上叫MicrosoftAccount\<username>@outlook.com的本地用户，当然不存在（0xC0000064）。这是客户端缺陷，与密码无关。顺带验证：从 Mac 发裸邮箱（不带前缀）时子状态是0xC000006A——说明裸邮箱服务器是认的。所以 Mac 上反而要用不带前缀的形式。 -
就算用户名格式完全正确，密码也被判错（
0xC000006A）。 密码明明是对的。这才是真正的谜底所在。
谜底：一个"推荐"的安全开关
回头看这台机器的锁屏界面时，最后一块拼图归位了：登录选项里根本没有"密码"，只有 PIN。
Windows 11 在"设置 → 帐户 → 登录选项"里有一个开关：
为了提高安全性，仅允许对此设备上的 Microsoft 帐户使用 Windows Hello 登录（推荐）
这台机器重装时开着它，日常登录全靠 PIN。问题在于：
- 交互式登录（坐在机器前输 PIN）和网络登录（RDP、SMB、SSH）走的是两套凭据验证路径；
- 微软账户做网络登录时，服务器需要用缓存的密码凭据来验证 RDP 客户端提交的密码；
- 而这套新装系统从装机起就没用过密码登录，这个缓存凭据从未被建立/刷新过。
这也解释了为什么重装之前一切都好：旧系统这些年或多或少做过密码登录（开机、解锁），密码凭据的缓存一直在被刷新，RDP 自然一直 work。而重装后的全新安装一路 Hello/PIN 引导下来，这把钥匙从来没有被配过——同样的硬件、同样的账户，差别只在一次重装。
于是：网页登录密码有效（在线验证）、本机控制台畅通（PIN 走另一套）、本地账户 RDP 正常（走本地 SAM）——全世界哪儿都好好的，唯独"从任何地方用微软账户 RDP 进这台机器"必败，且报错是那句极具误导性的"用户名或密码错误"。没有任何日志、任何提示指向这个开关。
修复
- 设置 → 帐户 → 登录选项 → 把"仅允许 Windows Hello 登录"关掉；
- 注销（锁屏不行，要注销），在登录界面选"登录选项 → 密码"，用微软账户密码登录一次——这一步才是真正建立密码验证凭据的动作；
- 重启一次；
- 从 Windows 端用
MicrosoftAccount\<username>@outlook.com验证（参照组，直接通）； - 从 Mac 端用裸邮箱
<username>@outlook.com（绕开客户端不拆分域的缺陷）。
之后日常开机照样用 PIN，互不影响。日志里 0xC000006D 从此绝迹。
复盘
这次排查走过的弯路，几乎每个坑都值得记一笔：
| 坑 | 教训 |
|---|---|
| 报错对话框只说"凭据不工作" | 去 NT 状态码里找真相：0xC000006D + 子状态 0x6A/0x64 语义完全不同 |
| localhost 当对照实验 | mstsc 连本机走 SSO，测的不是"输入的凭据" |
| 只从 Mac 测试 | 换客户端对照，才能区分客户端缺陷和服务端问题 |
| 4625 事件看得太晚 | 它同时记录了"到达的账户名/域"和"拒绝原因"，是最早该看的地方 |
而根本原因那一面更值得说：一个以提高安全性为名、默认"推荐"的开关，悄悄改变了凭据验证的可用性，让 RDP + 微软账户这个教科书场景静默失效，错误信息还指向用户自己（“你的密码错了”）。安全的初衷没问题，但安全特性打断互操作性的时候，至少应该在日志里留一句人话。这两个小时里，被怀疑过的有网络、Tailscale、权限、输入法、键盘布局、账户混淆、客户端版本……唯独真凶——那个打着"推荐"标签的开关——从头到尾没有出现在任何错误信息里。
如果你也在新装或重装的 Windows 11 上遇到"微软账户 RDP 永远密码错误"，先去锁屏界面看看还有没有密码登录选项。大概率，你也在同一个坑里。