FreeRDP连接Windows RD Gateway的NTLM认证问题分析与解决

问题背景

在使用FreeRDP客户端(版本2.11.5)从Ubuntu 24.04系统通过Windows Server 2022 RD Gateway连接目标Windows Server时，出现了认证失败的问题。错误日志显示"NTLM认证失败"和"协议安全协商失败"，而在Windows安全事件日志中可以看到状态码0xC000035B的错误。

环境配置

系统环境由三部分组成：

1. 客户端：Ubuntu 24.04系统，安装FreeRDP 2.11.5
2. RD Gateway服务器：Windows Server 2022
3. 目标服务器：Windows Server 2022

关键配置点：

• 两台Windows服务器都启用了"要求使用网络级别身份验证进行远程连接"
• 注册表项LmCompatibilityLevel设置为3
• RD Gateway配置了SSL证书并使用FQDN
• 所有服务器都处于工作组环境而非域环境

错误现象

使用以下命令连接时失败：

xfreerdp /v:<目标服务器IP> /u:<用户名> /p:<密码> /g:<网关FQDN> /gu:<网关用户名> /gp:<网关密码> /sec:nla

错误日志关键部分：

1. FreeRDP日志显示"HTTP响应接收重试次数超出"和"协议安全协商失败"
2. Windows安全日志显示NTLM认证失败，状态码0xC000035B

问题分析与解决

经过排查，发现问题主要出在以下几个方面：

1. 网关传输协议选择

默认情况下，FreeRDP会尝试自动检测网关的传输协议类型。但在某些配置下，自动检测可能失败。通过明确指定传输协议可以解决此问题：

xfreerdp /v:<目标服务器IP> /u:<用户名> /p:<密码> /g:<网关FQDN> /gu:<网关用户名> /gp:<网关密码> /gt:rpc

其中/gt:rpc明确指定使用RPC传输协议。测试发现/gt:auto和/gt:http在此环境下无法正常工作。

2. 安全协议选项

原命令中使用了/sec:nla选项，这实际上限制了安全协商的灵活性。在FreeRDP中：

• NLA(网络级别认证)会建立一个经过认证的TLS隧道
• 单纯的TLS选项建立的是匿名TLS隧道(会显示Windows登录界面)

最佳实践是让FreeRDP自动协商最合适的安全协议，除非有特殊需求，否则不应强制指定安全协议类型。

3. 工作组环境下的认证

虽然服务器处于工作组环境，但认证时仍需要注意用户名格式。在网关认证时，可能需要使用<计算机名>\<用户名>的格式，即使没有真正的域环境。

深入技术细节

NTLM认证流程

从日志可以看到完整的NTLM认证流程：

1. 客户端发送NEGOTIATE消息(包含支持的加密选项)
2. 服务器回复CHALLENGE消息(包含服务器支持的选项)
3. 客户端发送AUTHENTICATE消息(包含认证信息)

在失败案例中，虽然NTLM握手完成了，但后续的HTTP网关通信失败。

状态码分析

Windows安全日志中的状态码0xC000035B表示：

• 服务器无法验证客户端的凭据
• 在工作组环境中常见原因是认证信息格式不正确或传输协议不匹配

最佳实践建议

1. 网关传输协议：当自动检测失败时，明确指定/gt:rpc
2. 安全协议：除非有特殊需求，否则不要强制使用/sec选项
3. 认证信息格式：在工作组环境中尝试<计算机名>\<用户名>格式
4. 日志分析：同时检查FreeRDP日志和Windows安全日志以全面了解问题

总结

通过明确指定RPC传输协议和优化安全协议选项，成功解决了FreeRDP通过RD Gateway连接时的NTLM认证问题。这个案例展示了在复杂网络环境下，理解协议协商过程和正确配置参数的重要性。特别是在混合环境(工作组+网关)中，认证流程的细节配置往往决定了连接的成功与否。