Git连接Azure DevOps时NTLM认证失败问题排查求助

一、Git的NTLM认证凭据来源 #

• Windows环境下的Git默认通过Git Credential Manager (GCM) 处理认证凭据。当检测到服务器支持Windows集成认证（NTLM/Kerberos）时，GCM会直接调用Windows系统安全API，从当前登录用户的Windows安全上下文提取认证信息——也就是你当前登录Windows的域账号或本地账号的凭据，不会生成明文凭据，所以日志里显示“生成空凭据”是正常行为。
• 如果系统没有可用的集成认证上下文（比如非域环境、用户未登录域），GCM才会弹出窗口要求手动输入账号密码，之后将凭据缓存到Windows凭据管理器中。

二、NTLM认证的头部携带方式 #

NTLM认证遵循三次握手流程，头部携带逻辑如下：

1. 初始请求：客户端发送不带认证信息的请求，服务器返回401响应，同时在WWW-Authenticate头部指定NTLM；
2. 协商请求：客户端收到响应后生成NTLM协商消息，将其编码为Base64字符串，放在Authorization: NTLM <协商字符串>头部发送给服务器；
3. 认证请求：服务器返回包含挑战信息的401响应，客户端用自身凭据加密该挑战信息，生成最终的认证响应，同样编码后放在Authorization: NTLM <响应字符串>头部发送，服务器验证通过后返回200。

• 正常客户端会完整携带NTLM握手所需的头部字段（如Authorization、Connection: keep-alive等），确保握手流程顺利完成。

三、新客户端认证失败的可能原因 #

• Windows集成认证组件缺失：未安装Visual Studio的环境可能缺少必要的系统组件（如Visual C++运行库、.NET相关组件），导致GCM无法正常调用Windows的NTLM认证API，无法生成完整的协商/响应头部。
• 网络配置限制：新客户端所在网络的防火墙、代理服务器可能拦截了NTLM握手的关键头部字段，或者限制了请求头部的大小，导致NTLM协商信息被截断，服务器无法识别。
• Git配置细节差异：虽然版本一致，但可能存在本地配置偏差：
  • 执行git config --global credential.helper确认是否指向GCM（正常应为manager或manager-core）；
  • 检查git config --global http.ntlm是否设置为true，部分环境需显式开启NTLM支持；
  • 排查是否存在自定义http.extraHeader配置，可能覆盖或干扰NTLM头部的生成。
• 用户权限/域环境问题：新客户端的Windows用户可能没有Azure DevOps服务器的访问权限，或者未加入目标域，导致系统无法获取有效的NTLM凭据。
• GCM兼容性问题：Git 2.43.0自带的GCM版本可能与未安装VS的环境存在兼容性问题，可尝试手动更新GCM到最新版本测试。

内容的提问来源于stack exchange，提问作者AppleMoose