Git: "NTLM authentication has been disabled in Git by default" with Azure DevOps Server
Since March 2026, Git for Windows no longer answers NTLM unless told to, because NTLM is weak. Azure DevOps Server and TFS sites that sign people in with Windows authentication often end up using NTLM, so git fetch, pull, push and clone over HTTPS fail with this warning. You can turn NTLM back on for your server today, but not for long: curl removes NTLM in version 8.24.0, planned for December 9, 2026, and Git for Windows builds with that curl will have no way back. The lasting fixes are Kerberos or SSH.
The whole message
What Git 2.53.0.windows.2 printed on November 2, 2026, against a test server on our own machine that asks for NTLM the way IIS does with Windows authentication (we put an example address in place of the test server's):
warning: Due to its cryptographic weaknesses, NTLM authentication has been disabled in Git by default. You can re-enable it for trusted servers by running: git config set http.https://tfs.example.com.allowNTLMAuth true fatal: Authentication failed for 'https://tfs.example.com/DefaultCollection/Project/_git/repo/'
The same happened when the server offered both Negotiate and NTLM, as IIS does by default. Microsoft's post on the change (Upcoming change: NTLM removal in Git (libcurl), July 1, 2026) names this warning as the first sign.
The dates
| When | What changed |
|---|---|
| Git for Windows 2.53.0(2), March 10, 2026 | NTLM off by default (CVE-2025-66413). The setting http.allowNTLMAuth turns it back on. |
| Git for Windows 2.54.0, April 20, 2026 | Also off: the NTLM fallback inside Negotiate, used when Kerberos is not available. |
| Git for Windows 2.55.0, June 29, 2026 | Turning NTLM back on did not work; 2.55.0(2) of July 2 restored it "temporarily". |
| curl 8.24.0, planned for December 9, 2026 | NTLM removed from curl (curl's deprecation list, release dates). Git for Windows' notes call it the point when "NTLM will be disabled, no opt-in possible". |
The newest Git for Windows, 2.56.0(4) of October 26, 2026, comes with curl 8.23.0, so the setting still works there (release notes). Microsoft's post expected the removal in September 2026; curl's own list now puts it in 8.24.0. http.allowNTLMAuth is a Git for Windows setting. On Linux and macOS, Git uses the system's curl, where NTLM has been a build option, off unless turned on, since curl 8.20.0.
Turning it back on for one server, for now
The command in the warning has no --global. Inside a repository it changes only that repository. Outside one, which is where you are before git clone, it stops with fatal: not in a git directory (our test). For every repository on the server:
git config set --global http.https://tfs.example.com.allowNTLMAuth true
For one clone only:
git -c http.https://tfs.example.com.allowNTLMAuth=true clone https://tfs.example.com/DefaultCollection/Project/_git/repo
The setting covers every path on that host; git config --get-urlmatch http.allowNTLMAuth <URL of the repository> shows whether it applies. Git older than 2.46 has no git config set: write git config --global http.https://tfs.example.com.allowNTLMAuth true instead. Microsoft asks you not to rely on this, and not to keep an old Git to keep NTLM.
Is it NTLM or Kerberos?
A connection that works does not tell you which one it uses, because Negotiate falls back to NTLM when it cannot get Kerberos. Microsoft's two checks, in PowerShell:
klist purge git fetch klist
A ticket for HTTP/ and your server's name means Kerberos. No such ticket means NTLM, or that authentication failed.
$env:GIT_TRACE_CURL = 1 $env:GIT_TRACE_REDACT = 0 git fetch 2> trace.txt
Look at the Authorization: lines in trace.txt. A token that starts with TlRMT is NTLM, after NTLM or after Negotiate alike. In our test, Git with NTLM turned back on answered a server that offered Negotiate and NTLM with Authorization: Negotiate TlRMTVNTUAAB…: NTLM inside Negotiate, because there was no Kerberos ticket for that address. The trace contains your credentials; delete it after reading.
The lasting fixes
- Kerberos from end to end. Microsoft names correct service principal names (SPNs) for the server's address, clients that reach a domain controller, and the IIS configuration. Each name people use for the server, such as a DNS alias or a load balancer's name, has to work with Kerberos.
- SSH for machines that cannot use Kerberos: workgroup machines, build agents and service accounts, if SSH is turned on for your server.
Readers of Microsoft's post report that Git could not complete Kerberos while IIS Extended Protection was set to Required. The post itself does not cover that.
In IntelliJ IDEA and Rider
JetBrains IDEs run the Git installed on your computer, so their fetch, pull and push fail the same way, and the same fixes apply. Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, talks to the server's REST API with a personal access token, not NTLM, so reviewing pull requests keeps working while you sort Git out. It supports Azure DevOps Server 2019 or later and TFS 2018 Update 2 or later. Reading is free; voting, commenting and completing are Pro (US$1 a month, with a 30-day trial).
Get it on JetBrains Marketplace
Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft, JetBrains, the Git for Windows project or the curl project.
More: Azure DevOps Server and TFS support dates · Git Credential Manager and Azure Repos · Azure DevOps over SSH · 日本語