If you use TFS on-prem, Git over HTTPS, and Windows, you may have run into a strange authentication issue:
You enter the correct username and password… and Git fails.
Then you try again, leave both fields blank, and suddenly it works.
That feels backward, but there is actually a solid reason for it.
The setup: TFS on-prem + Git + Windows + GCM
When Git runs over HTTPS on Windows, it usually relies on Git Credential Manager (GCM) to handle authentication.
GCM supports several authentication methods, including:
- NTLM / Kerberos using Integrated Windows Authentication
- Basic Auth using a username and password
- Token-based authentication such as Azure DevOps PATs
In Azure DevOps, Basic Auth or token-based auth is common.
In TFS on-prem, especially inside enterprise Windows domains, NTLM is often the default and sometimes the only allowed authentication method.
That difference is what causes the confusion.
Why entering your username can force the wrong auth method
This is the key behaviour:
When you type a username into the prompt, GCM often interprets that as:
“Use Basic Authentication for this request.”
It then attempts to authenticate by sending an Authorization: Basic header.
That is fine in environments where Basic Auth is allowed.
But in many on-prem TFS environments, Basic Auth is disabled.
So what happens next?
- TFS rejects the request
- GCM retries
- Git eventually reports:
fatal: Authentication failed
Even though the username and password you entered are completely correct.
The issue is not your credentials. The issue is the authentication method being attempted.
The magic moment: leaving username and password blank
This is where it gets interesting.
If you leave both the username and password fields blank, GCM no longer has explicit credentials to send. Instead, it falls back to Windows Integrated Authentication.
In effect, that tells Git:
“Try authenticating with my current Windows session.”
That triggers NTLM or Kerberos pass-through:
- No manual username is sent
- No manual password is sent
- Windows uses your currently logged-in identity
If your TFS server supports Integrated Windows Authentication, authentication succeeds immediately.
So what looks like a weird hack is actually GCM behaving exactly as designed.
Why Git Bash often works better than PowerShell
There is another wrinkle here.
Many developers notice that Git Bash succeeds more often than PowerShell, even on the same machine.
Why?
Because Git Bash, running through the Git for Windows MSYS2 environment, often falls back to NTLM more naturally.
PowerShell, on the other hand, can more easily push GCM toward Basic Auth behaviour unless Git is explicitly configured otherwise.
That is why:
- the same repository
- on the same machine
- with the same user
can fail in PowerShell, but work in Git Bash when no credentials are entered.
How to make it work reliably, including in PowerShell
If you want this to behave consistently across shells, it helps to make Git use the expected Windows-native auth path.
1. Set the modern credential helper
git config --global credential.helper manager-core
2. Use the Windows SSL backend
git config --global http.sslbackend schannel
This tells Git to use the Windows certificate store instead of OpenSSL, which tends to play more nicely in corporate environments.
3. Clear any cached incorrect credentials
git credential-manager-core erase
Or remove any saved credentials for that TFS server from Windows Credential Manager.
4. Do not enter a username or password when prompted
If your TFS server expects Integrated Windows Authentication, let NTLM or Kerberos do the work using your existing Windows session.
Alternative: use alternate credentials if TFS allows it
Some TFS environments expose Alternate Authentication Credentials.
This gives you a dedicated Git username and password for Basic Auth.
If your organisation allows it, this can make HTTPS Git authentication behave more like a typical username/password flow.
However, many enterprises disable this feature for security reasons, so it may not be available.
Why this matters
This behaviour catches a lot of developers out because it looks completely counterintuitive:
- Git prompts for a username and password
- You enter valid credentials
- Authentication still fails
- Leaving everything blank works
Once you understand the difference between Basic Auth and Integrated Windows Authentication, the behaviour stops looking random and starts making sense.
Quick summary
- TFS on-prem commonly expects NTLM/Kerberos
- Entering a username often pushes GCM toward Basic Auth
- If Basic Auth is disabled, authentication fails
- Leaving the fields blank allows Git to use your logged-in Windows identity
- Git Bash often falls back to NTLM more easily than PowerShell
- You can improve consistency by configuring Git to use the right credential helper and Windows SSL backend
Final thought
This is one of those issues that feels like a Git bug the first time you hit it.
But once you understand what is happening under the hood, it becomes clear:
entering credentials can actually break authentication, while entering nothing allows Windows auth to succeed.
In enterprise TFS environments, that small detail can save a lot of frustration.
Leave a Reply