After a routine Visual Studio update silently upgraded Git for Windows to version 2.49.0, pushes to Azure DevOps started failing with a cryptic NTLM authentication error — even though our setup was supposed to use Kerberos. Here's what happened and how to fix it in 30 seconds.
The symptoms
You update Visual Studio (or Git for Windows directly), and suddenly any push to your Azure DevOps remote fails. The error mentions NTLM even though your network is configured for Kerberos. Typical signs:
- Git push fails immediately after a Visual Studio or Git for Windows update
- Error references NTLM authentication failure
- Clones and fetches from the same remote may still work
- The remote URL is an internal TFS/Azure DevOps server (e.g.
https://tfs.yourcompany.com)
What changed
Git for Windows 2.49.0 (shipped as MinGit 2.49.0) changed how it negotiates authentication for HTTPS remotes. The new default behaviour causes Git to attempt NTLM where it previously fell through to Kerberos — breaking on-premises Azure DevOps and TFS servers that rely on Kerberos/Negotiate for authentication.
Root cause: The http.emptyAuth setting tells Git to send an initial request without credentials, which prompts the server to advertise its supported auth schemes. Without it, the new Git version skips that negotiation step and defaults straight to NTLM — which then fails.
The fix
Run this single command in any terminal (Git Bash, PowerShell, or Command Prompt). Replace the URL with the base URL of your TFS/Azure DevOps server:
git config --global http.https://tfs.yourcompany.com.emptyAuth trueThis sets emptyAuth = true scoped only to your internal server URL, so Git sends an unauthenticated probe first. The server responds with the correct auth challenge (Kerberos/Negotiate), and the push succeeds as expected.
Why scope it to the URL? Using a URL-scoped config (http.https://…emptyAuth) rather than a global http.emptyAuth true keeps the change surgical — it won't affect authentication behaviour for GitHub, GitLab, or any other remotes.
Verifying the fix
After running the command, confirm it was written correctly:
git config --global --list | grep emptyAuthYou should see a line like:
http.https://tfs.yourcompany.com.emptyAuth=trueThen retry your push — it should go through immediately without prompting for credentials.
Alternative: roll back Git for Windows
If you need a temporary workaround while coordinating with your team, you can downgrade to Git for Windows 2.48.x from the official releases page. That said, the one-liner above is the cleaner long-term solution.
More information
Server advertises Kerberos, but GCM ignores it · Issue #2290 · git-ecosystem/git-credential-manager