很少有比坐下来准备远程连接到自己的 PC、输入凭据，却以最无用的方式被告知“用户帐户限制(例如，按时间段的限制)正在阻止你登录”更让人泄气的事情了。

按时间段的限制？这台机器是我自己配置的。

那就是我：在将它迁移到较新的域功能级别后一小时，就被一台 Windows Server 服务器锁在门外。查阅了微软的文档和系统管理员论坛之后，我终于拼凑出哪里出了问题，而事实根本不是错误消息所暗示的那样。

有一件事没人会一开始就告诉你：这个错误不是单一问题，而是一类问题。其原因可能从无密码帐户，到在只允许 Kerberos 的情况下，身份验证路径静默回退到 NTLM，什么都有。理解了这一点，你就已经离修复它成功了一半。

症状 / 原因	环境	首要操作	频率
本地帐户空白 / 无密码	独立 / 家用 PC	修复 1 — 设置密码	常见
允许 RDP 登录权限中缺少帐户	任意	修复 2 — 检查用户权限分配	常见
帐户在拒绝 RDP 登录权限中	任意	修复 2 — 从拒绝策略中移除	常见
通过 IP 连接，NTLM 受限	域	修复 3 — 使用 FQDN 主机名	常见
帐户被锁定	任意	修复 4 — 在 ADUC / lusrmgr 中解锁	偶发
登录时间限制	域	修复 4 — 在 ADUC 中检查登录时间	偶发
帐户在受保护的用户中，Kerberos 出故障	域	修复 5 — 修复 Kerberos 或从组中移除	管理员/加固
事件日志显示身份验证失败	任意	修复 6 — 查看安全日志（事件 4625）	诊断

你需要的修复方法完全取决于你的环境。在更改任何内容之前，请先逐一检查以下问题。

你能使用同一账户在本机本地登录吗？ 如果可以，并且只有 RDP 失败，那就不是凭据错误。问题可能是 RDP 权限分配、策略限制，或身份验证路径问题。请在目标计算机的事件查看器 → Windows 日志 → 安全中查看事件 ID 4625。对于域环境，也请检查域控制器的安全日志，因为有些身份验证失败只会在那里显示。

是单个用户还是所有人？ 单个用户被锁定通常指向账户级设置。所有人同时被锁定则可能意味着近期的策略更改、组策略更新，或服务器端配置变更。

独立机器还是已加入域？ 域环境会引入 Active Directory 组策略、Kerberos、NTLM 限制以及受保护用户行为。如果你使用的是独立的家庭电脑，可能只有修复方法 1、2 和 4 相关。如果你在域中，所有修复方法都可能适用。

你是通过 IP 地址还是主机名进行连接？ 这比大多数人想象的更重要。通过 IP 地址连接通常会阻止 Windows 使用 Kerberos，并强制回退到 NTLM。如果你的环境限制了 NTLM，那么该回退将失败，你会得到与此完全相同的错误，即使你的实际账户并未发生任何变化。参见修复方法 3。

最近有发生什么变更吗？ 组策略更新、操作系统补丁、域功能级别升级以及安全加固，都可能在没有明显警告的情况下一夜之间导致 RDP 出现问题。在认为是你的账户问题之前，一定要先问自己这个问题。

修复项 1–4 在此最为相关。这些不需要 Active Directory 或域方面的知识。

从这里开始，特别是在家用 PC 或独立计算机上。

Windows 默认会阻止没有密码的本地账户进行远程登录。这是有意为之并记录在案的安全策略：默认启用了“Accounts: Limit local account use of blank passwords to console logon only”设置，这意味着无密码账户被限制为仅进行交互式控制台登录。RDP 属于远程交互式登录，因此会被阻止。

为什么会发生这种情况: 微软在本地安全策略设置 “账户：将本地账户使用空白密码的登录限制为仅限控制台登录。” 中记录了此行为。 (Microsoft Learn)

设置密码：打开计算机管理 → 本地用户和组 → 用户 → 右键单击该账户 → 设置密码。如果这样能解决问题，就完成了。

有一种变通方法：可以通过 secpol.msc 或注册表项 LimitBlankPasswordUse 禁用空密码限制。对于任何可通过网络访问的计算机，请将此作为最后的手段。

警告： 禁用空白密码限制会显著削弱你的攻击面。设置强密码始终是正确的解决方案。

这是最常见的原因之一，也是最容易被忽视的。

Windows 使用两项互补的组策略设置来控制 RDP 访问：

通过远程桌面服务允许登录 — 授予连接的权限。
通过远程桌面服务拒绝登录 — 阻止连接的权限。

无论组成员身份如何，拒绝”策略始终会覆盖“允许”这是微软有据可查的行为。

在哪里可以找到它： 打开 gpedit.msc → 计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 用户权限分配。

检查这两个策略。确认你的帐户，或其所属的组（例如“远程桌面用户”或“管理员”出现在“允许”中。确认其未出现在“拒绝”中。如果你的帐户完全不在“允许”中，无论你的密码或凭据如何，都会被阻止 RDP 访问。

在域内的计算机上： 这些权限可以通过组策略在域级别进行设置，并且可以覆盖本地设置。如果本地设置看起来正确但问题仍然存在，请在目标计算机上使用gpresult /h report.html检查是否存在冲突的 GPO。

这一处改动解决的问题之多，远超出它本应解决的范围。

当你使用 IP 地址进行连接（例如，192.168.1.100）时，Windows 通常无法使用 Kerberos 身份验证，而会回退到 NTLM。对于独立的家用计算机，这通常没有问题。在加入域的计算机上，如果 NTLM 受到限制或被禁用，这种回退会静默失败，你会收到账户限制错误，尽管你的账户并没有任何变化。

请改用该机器的主机名：

server.yourdomain.com ✔ 推荐

192.168.1.100 ✘ 会强制回退到 NTLM

在连接到域内计算机时，也请使用 UPN 格式的凭据：user@domain.com 而不是 DOMAIN\user。这有助于 Windows 选择正确的身份验证路径，并避免许多出乎意料的边缘情况。

异常： Microsoft 已为 Windows Server 环境记录了较新的 Kerberos-over-IP 功能，但该功能需要显式配置，且默认不启用。 (Microsoft Learn：为 IP 地址配置 Kerberos).

对于多种不同的限制类型，Windows 都会返回相同的通用消息，这也是该错误令人沮丧的原因之一。帐户锁定和登录时间段限制是少见的两种错误消息在字面意义上确实准确的情况。

对于本地账户（独立或域） 打开 lusrmgr.msc → 选择该用户 → 检查是否已勾选帐户已锁定。如已勾选，则解锁。

对于域账户 打开 Active Directory 用户和计算机 → 找到该用户 → 双击 → 账户选项卡。勾选“解锁账户”并检查“登录时间”

一位 Windows Server 2016 管理员就遇到过这种情况：连接到服务器失败，并出现账户限制的消息，但并未有意配置任何时间限制。原因是域策略更新后，有一项组策略悄然应用了登录限制。安全日志中的事件 ID 4625 会显示具体的子代码。

事件 4625: 针对失败登录的安全日志条目包含一个子状态代码，用于标识确切原因。常见值：0xC0000234（帐户已锁定）0xC000006F（在允许时间之外登录）0xC0000022（拒绝访问）在猜测原因之前请先检查此项。

修复项 5 和 6 需要 Active Directory 访问权限，并熟悉 Kerberos 和 NTLM。如果你使用的是独立的家用电脑，可以跳过本节。

这是一种会令经验丰富的管理员措手不及的故障模式，且常在域升级后出现。

Active Directory 的 Protected Users 安全组对其成员强制实施更严格的身份验证规则：

完全阻止 NTLM 身份验证。
只允许 Kerberos，且仅限使用 AES 加密。
禁用 RC4 和 DES 的 Kerberos 加密类型。
不在本机缓存凭据。

从纸面上看，这是很好的安全做法。但在实践中，它会在隐式依赖 NTL 的环境中破坏 RDP 访问，这正是在通过 IP 地址连接、DNS 配置错误，或域升级后 Kerberos 尚未完全验证时会发生的情况。用户只会收到通用的帐户限制消息，且没有任何迹象表明与 Protected Users 有关。

为什么它会在域升级后出现： 提升域功能级别通常会更严格地执行现有策略。已在“受保护的用户”组中，但此前仍允许 NTLM 回退的帐户，可能会突然失败。 (Microsoft Learn: 受保护的用户安全组)

在从受保护的用户中移除任何人之前，请按顺序尝试以下步骤：

使用该计算机的 FQDN（server.domain.com）不要使用 IP 地址。
使用 UPN 凭据（user@domain.com）
验证从连接的计算机进行的 DNS 解析是否正常。
确认与域控制器的连接正常，并且 Kerberos 服务正在运行。

如果 Kerberos 工作正常，通常无需更改任何账户，问题就会消失。若仍未解决，您可以将该账户从受保护的用户中临时移除：

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

关于 PowerShell 远程处理: 当 PowerShell 远程处理可用时，此方法有效。请注意，PowerShell 远程处理在可用时也会使用 Kerberos，并在不可用时回退到 NTLM，因此在完全加固的环境中，它可能会面临相同的身份验证限制。Microsoft Learn：WinRM 安全性）

警告： 将帐户从受保护的用户中移除会削弱其安全态势。应将此视为诊断步骤，而非永久性修复。正确的解决方法是确保 Kerberos 在您的环境中正常运行。

在任何组成员身份发生更改后，请先注销，待身份验证刷新后再重试 RDP。

此时，请停止猜测并开始阅读。

在目标计算机上 事件查看器 → Windows 日志 → 安全。筛选事件 ID 4625。每条记录都包含失败原因和子状态代码，它们能比 RDP 错误消息本身更精确地标识确切原因。

要进行更深入的身份验证跟踪，还应启用：应用程序和服务日志 → Microsoft → Windows → Authentication。

在域控制器上 某些身份验证失败，尤其是与 Kerberos 相关的失败，只会记录在处理该请求的域控制器上，而不会记录在目标计算机上。当本地目标的日志无法提供完整信息时，请检查域控制器上的安全日志。

一旦在事件 4625 中找到子状态代码，错误就不再含糊，而会变成一个具体且可诊断的问题。常见代码列在上方的 Fix 4 说明中。

如果你在 macOS 上使用 Microsoft Remote Desktop 时看到错误代码 0xC07，它通常会与本文所述的同类身份验证和限制问题一起出现。社区报告显示，在许多情况下，通过主机名而非 IP 地址进行连接可以解决它，这与修复 3 中描述的 NTLM 回退模式一致。

目前没有权威的 Microsoft 文档能够将 0xC07 清晰地映射到单一根本原因。应将其视为表明你处于正确问题类别的一个信号，而非精确诊断。上述修复适用。

当 RDP 访问被拒绝，并显示 “user account restriction” 消息时，Windows 正在做它应该做的事情，只是没有告诉你你触发了哪条规则。

解决问题的最快路径是：

使用本文顶部的诊断矩阵来确定最可能的原因。
根据你的环境（家庭/独立或域）应用相应的修复。
如果原因仍不明确，请在目标计算机上检查事件 ID 4625。
对于域环境，在更改帐户设置之前，还应检查域控制器日志并确认 Kerberos 正常运行。

大多数时候问题很简单。即使不是，通常也是合乎逻辑的，只是被一条非常没有帮助的消息所掩盖。

如何修复用户账户限制正在阻止登录

快速诊断

第1部分：家用电脑 & 独立计算机

修复 1：该账户没有密码

修复 2：验证哪些用户有权限通过 RDP 连接

修复 3：停止通过 IP 地址连接

解决方法 4: 检查账户锁定和登录时间限制

第2部分: 域与企业环境

修复 5：受保护的用户组

修复 6: 当其他方法都行不通时，阅读日志

那么错误代码 0xC07 呢？

摘要