看起来这个问题挺典型的——同一个目标域AD账号在大部分客户端（包括源域的非DC机器）都能正常RDP登录目标域服务器，唯独源域的DC不行，而且之前是正常可用的，账号本身也排除了错误可能。结合你给出的错误码（0xC000006D/0xC000006A），我给你几个实际运维中常用的排查方向：

1. 优先排查Kerberos身份验证问题 #

域控制器默认会优先使用Kerberos做身份验证，而非DC客户端可能会自动回退到NTLM，这很可能是问题的核心：

• 检查域信任状态：在源域DC打开「Active Directory Domains and Trusts」，右键源域选择「属性」→「信任」标签，确认对目标域的双向信任显示“有效”；同理在目标域DC上也做一遍检查。
• 清除Kerberos缓存：在源域DC运行命令 klist purge 手动清除缓存，之后重启远程桌面服务或DC（如果允许的话），再尝试登录。
• 查看Kerberos日志：在目标域服务器的事件查看器中，查找「系统」日志里的Kerberos相关错误（比如事件ID 4768/4769），确认是否存在预身份验证失败的情况。

2. 检查源域DC的RDP身份验证配置 #

域控制器的RDP安全配置和普通客户端有差异：

• 打开源域DC的「远程桌面会话主机配置」，找到「RDP-Tcp」连接，右键选「属性」→「安全」标签，查看是否勾选了「要求使用网络级别身份验证」。可以临时改成「不要求使用网络级别身份验证」测试，排查是否是NLA导致的Kerberos协商失败。
• 检查本地安全策略：在源域DC的「本地安全策略」→「本地策略」→「安全选项」中，确认是否启用了「网络安全: 限制NTLM: 域控制器上的NTLM身份验证」这类限制策略——如果启用，会阻止DC使用NTLM访问目标域服务器，若Kerberos同时故障就会触发登录失败。

3. 验证目标域服务器的权限设置 #

虽然账号本身没问题，但目标域服务器可能对源域DC的登录做了限制：

• 登录目标域DC，打开「Active Directory用户和计算机」，找到目标域的服务器对象，右键选「属性」→「安全」标签，检查源域DC的计算机账号或源域相关组是否拥有「允许通过远程桌面服务登录」的权限。
• 同时检查目标域服务器本地的「远程桌面用户」组，确认是否包含该目标域用户账号或源域的授权组。

4. 排查DNS和时间同步问题 #

Kerberos对时间同步和DNS解析的要求非常严格：

• 确认源域DC与目标域服务器的系统时间差不超过5分钟（Kerberos默认时间容忍阈值）。
• 在源域DC上尝试解析目标域的域名和服务器主机名，确保能得到正确的IP；同理在目标域服务器上解析源域域名，排除DNS解析故障导致的身份验证失败。

5. 临时测试强制NTLM登录 #

如果以上排查都没头绪，可以尝试在源域DC上强制用NTLM验证：

• 打开「远程桌面连接」，点击「显示选项」→「高级」→「设置」，选择「使用以下RD网关服务器设置」并勾选「允许我使用与RD网关服务器不同的凭据」；或者在登录界面用目标域\用户名的格式，按住Ctrl+Alt+Delete后再输入密码，强制触发NTLM验证流程。

之前我处理过类似案例，最后发现是源域DC的Kerberos缓存过期，加上域信任的Kerberos密钥更新不及时导致的问题，你可以先从Kerberos和域信任方向入手排查，大概率能找到根源。

备注：内容来源于stack exchange，提问作者Rickedode