修复 Windows 上登录尝试失败的 RDP 错误

Fix the Logon Attempt Failed RDP Error on Windows

你输入凭据,Windows 安全提示框一闪而过,随后出现一条红色提示:The logon attempt failed。会话始终无法打开。我在家庭实验环境、客户端计算机和服务器上都遇到过这种情况。而且无论是由于缺少组策略权限、凭据管理器中的陈旧条目、某次 Windows 更新导致 CredSSP 出现问题,还是域控制器短暂不可访问,错误看起来都一模一样。

在本文中,我将带你了解导致 RDP 出现“登录尝试失败”错误的最常见、已确认的根本原因,以及经过验证的修复方法。

“RDP 登录尝试失败”是什么意思?

The logon attempt failed 是针对 RDP 身份验证链某处凭据被拒绝的通用 Windows 提示信息。它会在建立远程桌面之前,显示在 RDP 凭据提示框中的文本里。问题在于,Windows 会在多个不同的失败点返回相同的字符串。

目标机器上的 Windows 安全日志会将其记录为 Event ID 4625,而该事件中的状态码或子状态码才是真正用于标识失败位置的依据。

如何修复“远程桌面登录尝试失败”错误?

修复 1: 授予远程桌面服务登录权限

这解决了很大一部分凭据正确但连接失败的情况。我会在动其他任何东西之前从这里开始。

  1. 在目标计算机上,按下 Windows 键 + R,输入 secpol.msc,然后按下 Enter 以打开 本地安全策略

  2. 展开 本地策略 并选择 用户权限分配

  3. 在右侧窗格中,双击 通过远程桌面服务允许登录

    在本地安全策略中单击通过远程桌面服务允许登录
  4. 单击 添加用户或组,并输入您用于连接的帐户的确切用户名。

    在本地安全设置选项卡中添加用户或组
  5. 单击 确定 并关闭 本地安全策略

  6. 以管理员身份打开 命令提示符 并运行 gpupdate /force 以在无需重启的情况下应用更改。

    在提升权限的命令提示符中运行 gpupdate force

当您在计算机管理中时,还要核实该账户是否属于本地用户和组下的远程桌面用户组。这并不能替代策略权限,而是预期配置的一部分。默认情况下,属于远程桌面用户组通常会授予此权限,除非被本地或域组策略覆盖。但是,如果某个组策略明确覆盖了这一点,即使已具有组成员身份,您也可能需要将该账户直接添加到该策略权限中。

修复 2:在凭据管理器中清除过时的凭据

如果错误仍然存在,请在修复 1 之后立即运行此修复,尤其是在目标计算机上更改密码之后。

  1. 在连接的计算机上,打开开始菜单并搜索凭据管理器

  2. 选择 Windows 凭据

    在凭据管理器中选择 Web 凭据
  3. 查找任何以 TERMSRV/ 开头、后接目标计算机的 IP 地址或主机名的条目。

  4. 展开每个匹配的条目,然后点击 移除

  5. 关闭 凭据管理器

  6. 打开远程桌面连接,手动输入凭据,然后连接。

在仍在诊断时,不要让远程桌面连接再次保存凭据。连接前取消勾选允许我保存凭据复选框,以免 Windows 写入一个新的无效条目。

对于在 Microsoft Q&A 上报告的 Win11 到 Win11(内部版本26100.6584)的情况,通过控制面板 > 凭据管理器 > Windows 凭据 > 添加 Windows 凭据手动添加目标计算机的凭据,也能解决凭据委派策略造成干扰的情况。

在凭据管理器中添加 Windows 凭据

另外,请通过启动 mstsc、单击 显示选项,并避免使用任何已保存的连接配置文件,以使用新的 RDP 配置文件进行测试。损坏或过时的 RDP 配置文件 (.rdp) 可能会重复使用无效的参数或凭据。

修复 3:诊断并禁用网络级别身份验证

NLA 会在远程桌面加载之前使用您的凭据对会话进行预身份验证。当天目标计算机无法连接到域控制器、存在 CredSSP 版本不匹配,或帐户类型与 NLA 握手不兼容时,NLA 可能会使身份验证握手失败,并在客户端显示相同的 logon attempt failed 消息。暂时禁用 NLA 可以确认它是否是原因。

  1. 在目标计算机上,按下Windows 键 + Pause 打开 系统属性,然后在左侧窗格中单击远程 设置。

  2. 远程选项卡上,取消选中仅允许运行使用网络级别身份验证的远程桌面的计算机连接

  3. 单击应用

  4. 在客户端计算机上尝试连接。

如果在禁用 NLA 的情况下连接成功,那么问题出在 NLA 身份验证链内部,你可以在不凭猜测的情况下进一步诊断。对于基于注册表的访问,NLA 设置存储在:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

值名称是 UserAuthentication。将其设置为 0 以禁用 NLA,或设置为 1 以强制启用。同一路径下的 SecurityLayer 值控制更广泛的安全层:0 表示仅 RDP 安全,1 表示协商,2 表示 SSL。

在注册表编辑器中更改 SecurityLayer 和 UserAuthentication 值

NLA 的预身份验证步骤,恰恰是在 IT 技术人员最常遇到的支持场景中容易出问题的环节:

  • 公司网络外的远程机器
  • 域控制器不可达的终端
  • 未进行任何 IT 设置的机器

如果你的用例是远程支持,而不是自行访问自己的机器,HelpWire 会将这一层完全剔除。终端用户只需打开会话链接,即可发起出站连接,无需 NLA、无需满足域可达性要求,也无需在其端进行任何账户配置。

修复 4:使用 Microsoft 帐户修复“登录尝试失败”的 RDP 错误

Microsoft 帐户可用于 RDP,但如果使用 Windows Hello 或 PIN 代替帐户密码、用户名格式不正确(例如在某些设置中使用电子邮件而非 MicrosoftAccount\email)或者发生凭据缓存冲突,则可能导致身份验证失败。在这些情况下,明确使用帐户密码或使用本地帐户通常更可靠:

  1. 在目标计算机上,打开设置并转到帐户,然后转到其他用户

  2. 点击 添加账户,然后点击 我没有此人的登录信息

  3. 选择 添加一个没有 Microsoft 帐户的用户

  4. 为本地帐户创建用户名和强密码。

  5. 创建账户后,在其他用户中单击它,选择更改账户类型,并将其设置为管理员

  6. 返回到修复 1,并在本地安全策略中为此本地账户授予 Allow log on through Remote Desktop Services 权限。

  7. 通过 RDP 进行连接时,请使用本地帐户的用户名和密码。

在许多情况下,切换到本地管理员帐户能更可靠地解决问题,尤其是在启用了无密码或基于 PIN 的身份验证时。

修复 5: 在 Windows 更新后修复 RDP“登录尝试失败”

据报告,有两种与更新相关的情况会导致此错误。第一种是 2018 年 5 月更新(KB4103727 及相关更新)中引入的 CredSSP 加密 Oracle 修正。第二种是在 Windows 11 24H2 和 25H2 上的 KB5065426,它会在由于未正确执行 Sysprep 而导致存在重复 SID 的计算机上破坏 RDP 身份验证。


对于 CredSSP 错误(An authentication error has occurred. The function requested is not supported)正确的修复方法是确保客户端和目标计算机均已完全更新,使其 CredSSP 版本彼此兼容。仅作为临时变通方法,请在发起连接的计算机上应用以下设置:

  1. 按下Windows 键 + R,输入 gpedit.msc,然后按下 Enter

  2. 导航到 计算机配置 > 管理模板 > 系统 > 凭据委派

    单击加密 Oracle 修正
  3. 打开 加密 Oracle 修正,并将其设置为 已启用

  4. 防护级别设置为易受攻击

    将加密 Oracle 修正设置为已启用,并将保护级别设置为易受攻击
  5. 运行gpupdate /force,在以管理员权限的命令提示符中。

这只是权宜之计。永久性的解决方案是更新目标计算机,使两端都运行兼容的 CredSSP 版本。

针对 Windows 11 24H2 和 25H2 上的 KB5065426 回归问题,社区报告的注册表变通方法尝试禁用该更新引入的功能开关:

  1. 在目标计算机上,按下 Windows 键 + R,然后输入 regedit.exe,以打开 注册表编辑器

  2. 导航到 HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides

    在注册表编辑器中导航到 Overrides
  3. 创建一个名为 718619 的 DWORD(32 位)值。

  4. 将数据设置为0。

  5. 重新启动目标计算机。

对此环境的永久修复方法是在进行任何部署之前在基础映像上运行 sysprep /generalize /oobe /shutdown

注意: 此注册表变通方案来自社区,未在微软官方文档中记录。应用前请先确认它适用于你的特定内部版本。

修复 6:修复在域环境中第二次尝试时 RDP 登录尝试失败的问题

在域环境中,一些用户发现第一次 RDP 尝试失败,但第二次成功,或者在第二次尝试时账户被锁定。不正确的 NTLM 身份验证设置(lmcompatibilitylevel)可能会在各台计算机实施的 NTLM 策略不一致的域或旧版环境中导致身份验证失败。


解决办法是使两台计算机上的 lmcompatibilitylevel 保持一致:

  1. 在域控制器和 RDP 主机上,均按下 Windows 键 + R,并输入 regedit.exe

  2. 导航到 HKLM\SYSTEM\CurrentControlSet\Control\Lsa

    在注册表编辑器中导航到 Lsa
  3. 查找或创建一个名为 lmcompatibilitylevel 的 DWORD 值。

  4. 将值设置为 5,这将强制执行:仅发送 NTLMv2 响应,拒绝 LM 和 NTLM

  5. 重启两台机器。

这对应的组策略路径为:计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 安全选项 > 网络安全: LAN Manager 身份验证级别。在两台计算机上将其设置为仅发送 NTLMv2 响应。拒绝 LM 和 NTLM,即可消除触发反复失败的不匹配。

使用事件查看器诊断 RDP 身份验证失败

在目标计算机上使用事件查看器是在更改任何设置之前准确确定适用的根本原因的最快方式。我在任何修复并非一目了然的计算机上都会先运行它。

  1. 在目标计算机上,按 Windows 键 + R,输入 eventvwr.msc,然后按 Enter

  2. 在左侧窗格中,展开 Windows 日志 并选择 安全

  3. 在右侧操作窗格中,单击筛选当前日志

  4. 事件 ID字段中输入4625,然后单击确定

  5. 单击最新的事件 ID 4625 条目,并在下方面板中阅读详细信息。

事件中的 StatusSubStatus 字段负责大部分诊断工作:

状态和子状态代码 含义 解决方法
0xC000006A 用户名正确,密码错误 验证密码,检查凭据管理器
0xC0000064 目标上不存在该用户名 在本地用户中核实准确的账户名称
0xC0000234 账户被锁定 Active Directory或本地用户管理中解锁
0xC0000072 账户已禁用 在用户管理中启用该账户
0xC000015B 未授予登录类型的权限 参见上面的修复 1(添加通过远程桌面服务允许登录权限)
0xC000006F 账户受登录时间限制 检查账户属性
0xC0000070 工作站限制 账户仅限于特定计算机

如果 SubStatus 显示 0x0,请改为参考 Status 代码。若 StatusSubStatus 显示 0xC000015B,但帐户已在 Remote Desktop Users 组中,请在应用 Fix 1 之前检查是否有域级 GPO 正在覆盖本地权限。

Logon Type 字段也值得检查。Type 10 是远程交互式,即 RDP 使用的类型。Logon Type 10 表示 RDP (RemoteInteractive)。其他登录类型可能表示不同的身份验证路径或会话处理失败,这更可能指向网络中继或网关配置问题,而非本地策略问题。

在域环境中,请在域控制器的 Security 日志以及目标计算机上运行相同的事件 ID 4625 搜索。域控制器通常会先于目标计算机记录身份验证拒绝,这两个条目合在一起可以精确显示身份验证链断开的位置。

在域环境中,并非每次 RDP 失败都会在目标计算机上生成清晰的 4625 条目,尤其是当身份验证更早在域控制器处失败时。

如果仍未解决,以上修复后还可能剩下两个边缘情况:

  1. 目标计算机处于挂起的 Remote Desktop Services 会话状态。在意外断电或强制断开后,TermService 可能进入拒绝新身份验证的状态。完全重启目标计算机可清除此状态。如果你有进入该计算机的其他途径,可以通过 services.msc 仅重启 Remote Desktop Services,而无需整机重启。

  2. 域或组织单位级别的组策略为你的帐户应用了“通过远程桌面服务拒绝登录”权限,它会覆盖其下方的所有“允许”权限。 运行 rsop.msc 于目标计算机上,并导航到 计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 用户权限分配

    如果你的帐户同时出现在 通过远程桌面服务允许登录通过远程桌面服务拒绝登录 下,则无论组成员身份如何,Deny 都会生效。你需要在应用该策略的级别,从 Deny 条目中移除该帐户,这需要 Group Policy Management Console 访问权限。

RDP 登录尝试失败错误的原因

这6个根本原因占据了我所见案例的绝大多数,并且在微软文档、社区论坛以及现场故障排除中也经常被报告。

错误字符串 根本原因 环境
The logon attempt failed. 缺少 Allow log on through Remote Desktop Services 策略权限

用户名格式不正确(本地与域不匹配)
工作组或域
Your credentials did not work. The logon attempt failed. 凭据管理器中存在过期或冲突的凭据 所有环境
Logon credentials invalid. 某些 RDP 场景中的 Microsoft 帐户凭据问题(通常由于密码/PIN 不匹配或凭据处理导致) Windows 11
An authentication error has occurred. The function requested is not supported. 客户端与目标之间的 CredSSP/NLA 安全不匹配(通常在更新后或当一方未完全打补丁时) 更新后,所有环境
An authentication error has occurred. The Local Security Authority cannot be contacted. 域控制器不可达导致的 NLA 失败 域网络
Logon failure: user has not been granted the requested logon type at this computer. 通过 组策略 明确拒绝了该账户的 RDS 登录权限 域或本地策略

注意: 在混合环境中,错误的用户名格式(例如使用本地用户名而不是DOMAIN\username,或相反)即使密码正确也会导致立即的身份验证失败。

当连接到完全错误的主机时(例如,DNS解析到另一台机器)或者目标未正确启用远程桌面时,也可能出现该错误。

这些原因中的大多数可追溯到 RDP 在远程桌面尚未显示任何像素之前就叠加其身份验证层的方式。这种设计对于企业网络协议来说是合理的。但对于在无法完全控制的终端上执行远程支持的 IT 技术人员而言,这些层则成为会话失败的不可避免来源。HelpWire 专为这种特定用例而构建。您只需发送一个链接即可启动会话,终端用户无需在其端进行任何账户配置即可连接。此外,无人值守访问使您无需再次经过身份验证链即可进行后续工作。

为什么即使密码正确,RDP 仍显示“Remote Desktop Connection Logon Attempt Failed”

正确的凭据无法覆盖缺失的策略权限。本地安全策略中的允许通过远程桌面服务登录权限与本地管理员权限是彼此独立的控制项。如果你的帐户未在目标计算机的该权限下列出,Windows 会在确认密码是否有效之前就拒绝连接。我见过有人重置密码两次,把自己的帐户添加到本地 Administrators 组,仍然遇到同样的错误,因为这两种操作都不会影响该策略设置。

第二个隐性原因是发起连接的计算机上的凭据管理器。Windows 会按目标的主机名或 IP 地址存储 RDP 凭据。如果这些已保存的凭据已过期或属于不同的帐户,Windows 可能会在提示你之前,取决于该条目的保存方式,自动为该目标应用已存的凭据。你看到错误,以为是密码不对,改了密码,又再次碰壁。在某些情况下,凭据管理器中的已存凭据会覆盖手动输入,尤其是在更改密码之后。

帐户锁定是在工作组环境中容易被忽视的第三个原因。如果另一台设备、浏览器中的陈旧已保存凭据,或已断开的 RDP 会话在同一帐户上反复尝试旧凭据,那么在你打开远程桌面连接之前,帐户就会被锁定。检查目标计算机在计算机管理中的本地用户管理面板,不到 30 秒就能确认。

大多数人在遇到“Remote Desktop Login Failed”后首先会尝试做什么(以及为何行不通)

禁用 Windows 防火墙是本能的第一步。防火墙规则决定TCP 3389连接能否到达目标主机。若已出现凭据提示,问题通常不在防火墙。

将该账户添加到本地 Administrators 组是第二个本能做法。管理员权限并不会授予远程桌面服务的登录权限。这是分开的控制项。即使是本地管理员,如果缺少相应的策略权限,仍然会被 RDP 阻止。

在未先查看事件查看器的情况下反复尝试不同的用户名格式只是盲试。DOMAIN\user, user@domain.com,以及仅使用用户名,都可能表示同一个账户。没有手头的Event ID 4625,你就没有依据判断到底哪里在失败。

在发起连接的计算机上以管理员身份运行远程桌面连接客户端并不起作用。身份验证依据的是目标计算机的安全策略,而不是客户端的。

另外,请确认目标计算机已启用远程桌面,并且所用的 Windows 版本支持作为 RDP 主机进行连接(Windows 家庭版不支持)

常见问题

NLA 会在远程桌面加载之前对会话进行身份验证。当目标计算机无法访问域控制器,或客户端与目标之间存在 CredSSP 版本不匹配时,NLA 可能会在会话初始化之前终止身份验证尝试。这通常会在客户端显示为 The logon attempt failed 消息。在目标计算机的 系统属性 > 远程 选项卡下暂时禁用 NLA 可确认 NLA 是否是原因。

在目标计算机上运行rsop.msc,然后导航到计算机配置 > Windows 设置 > 安全设置 > 本地策略 > 用户权限分配。如果受影响的帐户出现在Deny log on through Remote Desktop Services下,则该条目会覆盖所有允许权限,必须在其被应用的组策略级别,使用组策略管理控制台将其移除。

从 2026 年 4 月的 Windows 更新(KB5083769)开始,Microsoft 在 .rdp 文件连接之前新增了强制性警告,要求用户确认要共享哪些本地资源。这是一项用于防止欺骗攻击的安全功能,但如果对话框不保存偏好设置,可能会显得重复。将 RedirectionWarningDialogVersion 设为 1 可暂时将对话框行为恢复为 2026 年 4 月之前的行为,尽管底层的安全改进仍然保持激活。


专业提示:在你需要之前,为每台你远程管理的计算机设置一个用于 RDP 访问的专用本地管理员帐户。为其设置一个强密码并存储在密码管理器中,并在设置时授予它 Allow log on through Remote Desktop Services 权限。当域控制器宕机、更新后 NLA 出现问题,或主帐户遇到策略冲突时,该本地帐户就是进入计算机的唯一路径,能够绕过本文所述的整条身份验证链。


如果你为用户管理 .rdp 文件,请在 2026 年 4 月更新之后考虑使用 PowerShell 对其进行签名,以避免重复的信任警告。在安装了 KB5083769 或更高版本的 Windows 11 中,未签名的 .rdp 文件每次启动都会触发新的欺骗警告。

如果“登录尝试失败”错误阻断了你进入该机器的唯一途径,而你又没有控制台访问权限、没有备用本地账户、现场也无人可以更改设置,那么常规的 RDP 故障排除就会碰壁。你无法在无法登录的计算机上打开 secpol.msc、清除凭据管理器,或禁用 NLA。


在这种情况下,HelpWire 提供了一个切实可行的出路。终端用户打开一个会话链接,他们无需进行账户配置、无需 NLA 握手,也不要求其端具备域可达性。会话建立后,你可以在该机器内应用本文中的任一修复,并恢复 RDP 以供日后使用。