修复远程桌面凭据不起作用

在远程桌面中出现的Your credentials did not work错误并不意味着你的密码错误。许多情况下，发起连接的计算机会发送在更改密码后仍然残留的过期缓存凭据。在某些配置中，目标计算机处于基于 Windows Hello PIN 的登录状态，这会阻止使用 Microsoft 帐户进行 RDP 登录。这些是最常见的触发因素，但在两端设备上导致凭据失败的根本原因不止十几种。本指南涵盖了微软文档和 Q&A 中报告的最可靠修复方法，以及社区中反复出现的故障排除帖子。

如果你正在处理的是凭据堆栈本身已损坏的计算机，而不仅仅是密码错误，HelpWire 值得提前了解：它是一款免费的远程访问工具，连接时完全不触及 RDP 的本地帐户身份验证，因此下面的任何凭据问题都不适用于它。

HelpWire 4.8

可跳过无效的 RDP 凭据的远程访问

Visit Site

价格: 免费

受支持的系统: Windows, macOS, Linux

在下表中找到最可能的原因，并直接采用相应的修复方案，而不是逐一测试每个选项。

原因	所属端	修复部分
缓存或过期的凭据	客户端	修复 1
与 Windows Hello PIN 相关的 Microsoft 帐户登录问题	目标计算机	修复 2
用户名格式错误	客户端	修复 3
用户不在“远程桌面用户”组中	目标计算机	修复 4
凭据委派被 GPO 阻止	客户端	修复 5
RDP 安全层不匹配	目标计算机	修复 6
`Always prompt for password` 已启用	目标计算机	修复 7
网络配置文件设置为 `Public`	目标计算机	修复 8
LAN Manager 身份验证级别不匹配	目标计算机	修复 9
`fDenyTSConnections` 设置为 `1`	目标计算机	修复 10
空白密码限制	目标计算机	修复 11
RDP 侦听器未处于活动状态	目标计算机	修复 12
RDP 证书已过期	目标计算机	特殊情况
非默认 RDP 端口	目标计算机	特殊情况

这是在使用已启用 Windows Hello PIN 的 Microsoft 帐户的设备上远程桌面凭据不起作用时，最常被证实有效的修复方法。根据用户报告，在目标设备上仅使用 PIN 之后，在本地使用帐户密码登录已能恢复 RDP 访问。

注意： 适用于企业的 Windows Hello 是一项独立的企业功能，它确实支持通过 Microsoft Intune 或 Active Directory 证书服务进行的基于证书的部署来实现 RDP 登录。这需要 PKI 基础结构、证书部署以及域控制器证书。它不适用于标准的消费者或 SMB 设置，并且与此处描述的面向消费者的 PIN 场景无关。

在目标计算机上，注销当前会话。
在登录屏幕上，单击登录选项。
选择密码选项（钥匙图标）
使用您的完整 Microsoft 帐户密码登录。
在发起连接的计算机上重试 RDP 连接。

在登录屏幕上，点击 登录选项，然后点击 我忘记了我的 PIN。
使用您的 Microsoft 帐户凭据进行身份验证，包括任何两步验证的批准。
当系统提示重置您的 PIN 时，请确认重置。您可以重新输入相同的 PIN。
在基于密码的登录流程完成后重试 RDP 连接。

多位用户确认，关闭这个开关即可解决问题，无需退出并重新登录。

在目标计算机上，前往 设置 > 账户 > 登录选项。
查找 为提高安全性，仅允许此设备上的 Microsoft 帐户使用 Windows Hello 登录.
把它关掉。
注销并使用 Microsoft 帐户密码重新登录。

连接端计算机上的 Windows 凭据管理器会缓存 TERMSRV/ 条目。更改密码后，它会在每次连接尝试时不提示地静默发送旧密码。

在进行连接的计算机上，打开 凭据管理器。在开始中搜索它，或运行 control /name Microsoft.CredentialManager。
单击 Windows 凭据。
查找所有以 TERMSRV/ 开头，且后接远程计算机名称或 IP 地址的条目。
单击每个条目，然后单击移除。
重新连接。Windows 将提示输入新的凭据。

打开 远程桌面连接 (mstsc.exe).
输入远程计算机名称或 IP 地址。
单击 显示选项。
在登录设置中，单击已保存的用户名旁边的edit链接。
请输入当前密码并保存。

某些配置会拒绝在会话之间保留 RDP 凭据。直接在“凭据管理器”中添加一个通用凭据条目会强制 Windows 使用该凭据。

打开 凭据管理器 > Windows 凭据.
单击 添加通用凭据。
在Internet 或网络地址中，输入TERMSRV/，后接远程计算机的主机名或 IP 地址。例如：TERMSRV/103.27.76.117 或 TERMSRV/COMPUTERNAME。
请输入用户名和密码。
单击确定，关闭 凭据管理器，然后重新连接。

你输入的用户名格式决定了 Windows 将请求发送到哪个身份验证提供程序。使用错误的格式会将请求路由到错误的身份源，即使密码正确也会失败。

Microsoft 文档说明，对于远程的已加入 Microsoft Entra 的设备，你可以根据所用的登录路径，使用 user@domain.com 或 AzureAD\user@domain.com 登录。如果一种格式失败，请尝试另一种。

帐户类型	正确格式	备注
本地帐户	`COMPUTERNAME\username</code`	示例：`DESKTOP-AB12\john`
域帐户（NetBIOS）	`DOMAIN\username`	示例：`CORP\johndoe`
域帐户（UPN）	`username@domain.com`	示例：`johndoe@corp.local`
Microsoft 帐户	完整的电子邮件地址	示例：`john@outlook.com`
已加入 Microsoft Entra	`AzureAD\user@domain.com` 或 `user@domain.com`	Microsoft 在文档中针对不同的登录路径同时记录了这两种格式。若第一种失败，请尝试另一种。

在目标计算机上，帐户必须属于“远程桌面用户”组或“管理员”组之一。Event ID 4625 的子状态为 0xC000015B 时，可确认用户尚未被授予所需的登录类型。仅有组成员身份仍可能被“用户权限分配”中的显式 Deny 所阻止。

在目标机器上，以管理员身份运行以下命令：
net localgroup "Remote Desktop Users" /add "DOMAIN\username" 或者在 PowerShell 中：
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"
打开运行并输入secpol.msc。
导航到 本地策略 > 用户权限分配.
双击 允许通过远程桌面服务登录。
单击 添加用户或组。
输入账户名称，然后单击确定。
在同一列表中检查是否有包含该用户或其所属组的拒绝通过远程桌面服务登录项。删除任何显式拒绝项。

当发起连接的计算机上的凭据委派策略限制凭据的转发方式时，即使密码正确，RDP 客户端也无法通过身份验证。这适用于所有账户类型，也是导致远程桌面凭据不起作用最容易被忽视的原因之一。修复操作应在客户端计算机上进行，而不是在远程计算机上。

在连接的计算机上，打开运行并输入gpedit.msc。
导航到 计算机配置 > 管理模板 > 系统 > 凭据委派。
将拒绝委派已保存的凭据设置为未配置。
将 拒绝委派新凭据 设置为 未配置。
打开 仅 NTLM 服务器身份验证时允许委派已保存的凭据。将其设置为 已启用。
单击显示，在 将服务器添加到列表 旁边，并输入 TERMSRV/*。单击确定。
针对以下项目重复步骤 5: 允许委派已保存的凭据, 允许使用仅 NTLM 服务器身份验证委派新的凭据, 以及 允许委派新的凭据.
导航到 计算机配置 > 管理模板 > Windows 组件 > 远程桌面服务 > 远程桌面连接客户端。
将不允许保存密码设置为未配置。
将在客户端计算机上提示输入凭据设置为未配置。
关闭组策略编辑器，并在以管理员身份运行的命令提示符中运行gpupdate /force。

在其他所有解决方案都失败后，多位用户确认此修复有效。当客户端与目标之间协商的安全层无法达成一致时，身份验证会在凭据被完全评估之前就被拒绝。

在目标计算机上，打开运行并输入gpedit.msc。
导航到 计算机配置 > 管理模板 > Windows 组件 > 远程桌面服务 > 远程桌面会话主机 > 安全。
打开 要求为远程 (RDP) 连接使用特定的安全层。
将其设置为Enabled。在下拉菜单中，选择RDP作为安全层。
单击确定，然后在以管理员身份运行的命令提示符中执行 gpupdate /force。

当在远程计算机上启用此策略时，它会覆盖客户端上已保存的凭据，并强制要求重新进行身份验证。该提示会静默失败，从而产生凭据错误，而不是显示可见的密码对话框。

在目标计算机上，打开运行并输入gpedit.msc。
导航到 计算机配置 > 管理模板 > Windows 组件 > 远程桌面服务 > 远程桌面会话主机 > 安全。
打开 连接时始终提示输入密码。
将其设置为已禁用或未配置。
注销并重新登录，或运行 gpupdate /force。

当目标计算机的网络配置文件设置为Public时，Windows 会阻止传入的 RDP 连接。Microsoft 的 RDP 疑难解答指南将网络配置文件和防火墙配置视为导致连接失败的合理原因。当其他设置看起来都正确时，这种情况很常见。

在目标计算机上，打开 设置 > 网络和 Internet > 状态。
单击更改连接属性。
将 网络配置文件 设置为 专用。

发起连接的计算机与远程计算机之间的身份验证级别不匹配，会在 NTLM 协商层导致凭据被拒绝，无论密码是否正确。

在目标计算机上，打开运行并输入gpedit.msc。
导航到 计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 安全选项.
打开 网络安全: LAN Manager 身份验证级别。
将其设置为以下三个已确认可用的值之一：Send NTLMv2 response only、Send NTLMv2 response only. Refuse LM，或Send NTLMv2 response only. Refuse LM and NTLM。这三种任意一种都能解决不匹配问题。最宽松、应首先尝试的选项是Send NTLMv2 response only。
单击确定。

当在设置中显示RDP已启用，但连接仍然失败时，可能有两个注册表值覆盖了 UI 设置。微软在其文档中将 fDenyTSConnections 定义为控制用户是否可以使用远程桌面服务进行远程连接的设置。

以管理员身份打开 注册表编辑器 (regedit.exe)。
导航到： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
确认 fDenyTSConnections 已设置为 0。
还要检查：
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services。如果此处出现 fDenyTSConnections 并设为 1，则有一项组策略在强制执行该阻止。更改本地值不会生效。必须在其源头更正该 GPO。
要验证RDP 端口是否未从默认值更改，请导航到：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
查找 PortNumber。将显示进制切换为 Decimal。
该值应为 3389。如果不是，您的 RDP 客户端必须改为通过该自定义端口进行连接，使用格式 hostname:PORT。

在进行任何注册表更改后，重启远程桌面服务：打开 services.msc，找到 远程桌面服务，右键单击，然后选择 重新启动。

对于未设置密码的账户，Windows 默认会阻止 RDP。这是本地安全策略的限制，而不是 RDP 设置。

打开运行并输入 gpedit.msc。
导航到 计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 安全选项.
打开 账户: 将使用空白密码的本地账户限制为仅限控制台登录.
将其设置为Disabled。

在假定问题与凭据相关之前，先确认目标计算机上的 RDP 协议确实在侦听连接。如果 RDP 侦听器未处于活动状态，服务器会在评估远程桌面凭据之前就在协议层面拒绝连接。这会产生看起来像身份验证失败的错误。

通过PowerShell Remoting或物理控制台访问，在目标计算机上以管理员权限运行此命令：

qwinsta

查找名为rdp-tcp且STATE为Listen的条目。如果没有该条目或状态不同，说明 RDP 服务出现协议故障。检查上方Fix 10中的注册表项和下方边缘情况部分中的 RDP 证书，然后重启Remote Desktop Services。

专业提示: 在每台你远程管理的计算机上，保留一个不使用 Microsoft 帐户登录的本地管理员帐户。它可以绕过阻碍 RDP 的 MSA、PIN 和证书问题。将凭据存储在密码管理器中，而不是存储在你自己计算机上的“凭据管理器”中。但它仍然依赖于 RDP 的身份验证堆栈能正常工作。如果目标计算机上的凭据委派、安全层或 NLA 出现故障，那么在有人到现场进行操作并先行修复之前，使用本地帐户也无济于事。

HelpWire 完全消除了这种依赖。它是一款免费的远程访问工具，可将操作员与客户端直接连接，完全不经过 RDP 的本地帐户身份验证。会话从一个链接开始：操作员发送链接，远程计算机上的人员打开并批准连接，双方的会话都不与任何 Windows 用户名、密码或 Microsoft 帐户绑定。连接本身使用 TLS 和 AES-256 加密；由于不依赖 RDP，无论目标运行 Windows、macOS 还是 Linux，其工作方式都相同。这一点在此处尤为有用，因为上面的若干修复（Windows Hello PIN 问题、Microsoft Entra 登录格式）都特定于 Windows 处理自身凭据的方式。

连接建立后，你可以在会话内部执行修复 1 到修复 12，而不会再被你试图解决的同样凭据问题所阻碍，因为本文所涵盖的凭据管理器、凭据委派策略或 LAN Manager 身份验证级别都不会介于你与该机器之间。

HelpWire 4.8

可跳过无效 RDP 凭据的远程访问。

Visit Site

价格: 免费

受支持的系统: Windows, macOS, Linux

在目标计算机上打开 事件查看器，并在 Windows 日志 > 系统 中检查来自 Microsoft-Windows-TerminalServices-RemoteConnectionManager 的 事件 ID 1057 或 1058。这些事件表明自签名证书续订失败。

打开 mmc.exe > 文件 > 添加/删除管理单元 > 证书 > 计算机帐户。
转到 证书 > 远程桌面。
删除已过期的自签名证书。
在services.msc中重新启动远程桌面服务。Windows 会自动重新生成证书。

导航到 C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
取得与 RDP 相关的密钥文件的所有权。
删除该文件。
重新启动 远程桌面服务。

使用主机名连接时，请确认 DNS 解析到的是正确的主机，尤其是在主机重装或 IP 变更之后。

在目标计算机上，在提升权限的命令提示符中运行 IPCONFIG /All，并记录实际的 IP 地址。
在发起连接的机器上，运行 nslookup MACHINENAME 并确认返回的 IP 是否一致。
另外在 PowerShell 中运行 Test-NetConnection -ComputerName SERVER-IP -Port 3389。如果 TcpTestSucceeded 返回 False，问题出在网络或防火墙，而不是凭据。
如果 DNS 已过时，请直接通过 IP 地址连接或更新 DNS 记录。

在已加入域的计算机上，多次失败的 RDP 尝试会触发锁定策略。请在域控制器上的事件查看器中查找事件 ID 4625，其子状态为0xC0000234。对于目标计算机上的本地账户，运行：

net user USERNAME

在输出中查找Account active: No。要重新启用：

net user USERNAME /active:yes

Microsoft 文档指出，对于远程已加入 Microsoft Entra 的设备，您可以根据登录路径使用 user@domain.com 或 AzureAD\user@domain.com 登录。如果一种格式失败，请尝试另一种。无论哪种情况，请确认已将该用户添加到目标计算机上的 Remote Desktop Users 组。此外，请在 Entra 管理中心的 设备 > 特定设备 > 本地管理员 下检查该设备。

事件 ID 4625 在 Windows 安全日志 中记录每次登录失败。子状态字段标识确切的身份验证失败原因，从而彻底消除诊断中的猜测。

子状态代码	失败原因	解决方法
`0xC000006A`	用户名正确，密码错误	清除凭据管理器，验证当前密码
`0xC0000234`	账户被锁定	通过管理员账户解锁，或等待锁定策略
`0xC0000072`	账户已禁用	在计算机管理中启用该账户
`0xC0000071`	密码已过期	更改目标账户的密码
`0xC000015B`	用户缺少 RDP 登录权限	将其添加到远程桌面用户组，并检查用户权限分配

要访问这些日志：打开 事件查看器 > Windows 日志 > 安全，然后按 事件 ID 4625 进行筛选。在事件详细信息中，展开 失败信息，并查看 子状态 的十六进制值。

当 Windows 远程桌面凭据无法使用时，大多数人首先会重置其 Microsoft 帐户的密码。这对上文提到的 PIN 和缓存凭据场景没有帮助。问题往往不在于帐户密码本身，而在于缓存的凭据，或设备之间不匹配的身份验证状态。重置密码并不能解决问题，因为客户端会继续提交较旧的缓存凭据，直到清除或替换已保存的 TERMSRV/ 条目为止。

第二种常见的尝试是切换 NLA 的启用与禁用。对于 Windows Hello PIN 问题和陈旧的缓存凭据，NLA 的状态并不是关键因素。PIN 问题的原因在于，标准的 Windows Hello PIN 身份验证是与设备绑定的，且不会通过标准的 RDP 身份验证流程进行转发。禁用 NLA 还会削弱连接安全性，而无法解决根本原因。

在一些论坛帖中流传的第三种方法是删除 WinStations 注册表项。然而，这可能会导致计算机无法正常工作，并需要完全重新安装操作系统。

当问题在于 RDP 配置本身，而不是凭据格式问题时，值得在工具箱中保留一款为支持工作而构建的工具。例如，HelpWire 通过向远程用户发送链接来启动会话，远程用户运行一个轻量级客户端。然后你无需针对远程计算机的本地帐户进行任何身份验证即可连接。当你需要进入一台 RDP 凭据堆栈已损坏的计算机时，这就消除了对 RDP 正确配置的依赖。

当你发现远程桌面凭据不起作用时，最常见的原因是发起连接的计算机上的Windows 凭据管理器中缓存了过期的密码，其会在更改密码后未提示地自动发送。另一个常见原因是目标计算机上次在本地使用Windows Hello PIN进行身份验证，这在某些设置下可能会阻止使用 Microsoft 帐户通过 RDP 登录。

标准的 Windows Hello PIN 是设备绑定的，且不会通过标准 RDP 身份验证流程进行转发。RDP 在标准的消费者和 SMB 配置中需要基于密码的凭据。

Windows Hello for Business 是一项独立的企业功能，确实通过基于证书的身份验证来支持 RDP，但它需要 PKI 基础设施、通过 Intune 或 AD CS 部署证书，以及域控制器证书。它在标准的消费者或 SMB 配置中不可用。

从开始菜单打开凭据管理器，单击Windows 凭据，并删除所有与该远程计算机对应、以TERMSRV/开头的条目。如果凭据在会话之间无法保留，请使用添加通用凭据，在凭据管理器中手动输入TERMSRV/[hostname] address，与用户名和密码一起输入。

是的。凭据委派设置位于连接的计算机的在组策略中的计算机配置 > 管理模板 > 系统下，用于控制是否会转发凭据。将拒绝委派已保存的凭据或拒绝委派新凭据设置为已启用会静默阻止身份验证。将二者都设置为未配置，并在仅使用 NTLM 服务器身份验证允许委派已保存的凭据下启用TERMSRV/*可解决此问题。

清除发起连接的计算机上的 凭据管理器 条目并重试。如果连接仍然失败，请在 PowerShell 中运行 Test-NetConnection -ComputerName SERVER-IP -Port 3389。如果 TcpTestSucceeded 返回 True 但凭据仍然验证失败，则问题在目标计算机上。如果返回 False，则问题在网络或防火墙上。进入目标计算机后，在 安全日志 中查看 Event ID 4625，以确定确切的失败原因。

如何修复远程桌面凭据无法使用的问题

修复远程桌面凭据无法使用的 12 种方法

修复 1：在目标计算机上使用您的密码登录一次（Windows Hello PIN 问题）

方法A：退出登录并使用密码重新登录

方法 B：如果密码选项缺失或变灰

方法 C：禁用仅使用 Windows Hello 登录的开关（独立修复）

解决方法 2: 在用于连接的计算机上从凭据管理器中清除过时的凭据

方法A: 通过凭据管理器删除条目

方法 B: 在 RDP 客户端中直接更新密码

方法C：当已保存的凭据无法持久化时，手动添加一个通用凭据

修复 3: 使用正确的用户名格式

修复 4：将用户添加到远程桌面用户组并验证登录权限

修复 5: 在用于连接的计算机上修复凭据委派组策略

修复 6：通过目标计算机上的组策略更改 RDP 安全层

修复 7：在目标计算机上禁用“始终提示输入密码”

修复 8：在目标计算机上将网络配置文件从公用更改为专用

修复 9: 在目标计算机上设置 LAN Manager 身份验证级别

修复 10：检查 fDenyTSConnections 注册表项和 RDP 端口

修复 11：处理目标账户的空密码

修复 12: 检查 RDP 侦听器状态

修复 13: 当 RDP 的凭据堆栈本身损坏时使用 HelpWire

远程桌面凭据无效问题的边缘情况修复

RDP 自签名证书失败 (事件 ID 1057 或 1058)

验证 DNS 和主机定向

账户锁定

Azure AD / Entra ID 已加入的计算机

如何在事件查看器中查看 RDP 登录失败

Windows 远程桌面凭据无法使用时的常见错误

常见问题