fatal: authentication failed for 'http://tfs:8080/tfs/Collection/TeamProject/_git/Project/' #987

nilleb · 2016-12-07T13:40:35Z

Setup

git for windows x64 2.10.2+

$ git --version --build-options
14:17:04.620654 git.c:371               trace: built-in: git 'version' '--build-options'
git version 2.11.0.windows.1
sizeof-long: 4
machine: x86_64

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
Windows 10 up to date, stable channel

$ cmd.exe /c ver
Microsoft Windows [version 10.0.14393]

What options did you set as part of the installation? Or did you choose the
defaults?

Path Option: CmdTools
SSH Option: OpenSSH
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Difftool: Disabled

Any other interesting things about your environment that might be related
to the issue you're seeing?

The tfs:8080 server exposes its content only to users authenticated with NTLM/SPNEGO

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

cmd

What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.

git fetch origin

What did you expect to occur after running these commands?

Fetch the latest updates on the remote repository (or nothing at all)

What actually happened instead?

fatal: Authentication failed for 'repository uri'

If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?

Sorry, I can't. It's in my intranet, non accessible from the internet.

The text was updated successfully, but these errors were encountered:

nilleb · 2016-12-07T13:42:28Z

At the beginning I was suspecting an issue in libcurl. So I have just replaced all the files containing curl in the 2.11 distribution with the ones from the 2.10.1 distrib. But the situation hasn't improved.

whoisj · 2016-12-07T15:22:19Z

@nilleb did you have the Git Credential Manager for Windows option selected when you installed Git for Windows? You can check this by looking for a line like credential.helper=manager when you run git config --list --show-origin from the command line.

This could a GCM bug. If you do see the line above in your config, try this from a command prompt inside the repository in question git config credential.authority ntlm, then re-try your git fetch operation.

TonDekker · 2016-12-07T16:13:16Z

@nilleb I ran in the same problems and after a few un(installs) I decided the following:

remove all git related stuff
install the GCMW from https://github.com/Microsoft/Git-Credential-Manager-for-Windows/releases/tag/v1.8.0
Make sure to install the Git client from that setup.
A new Git client setup will appear.
Run, install that Git client
Reboot (optional, but after so many issues, I thought it would be safer)
Presto.

whoisj · 2016-12-07T18:05:15Z

Presto.

What happened? Failed again, worked this time?

TonDekker · 2016-12-07T19:27:42Z

@whoisj : sorry. Yeah, everything worked as expected. I can connect to our on premise TFS Git container.
This was a completely fresh desktop and I thought it wouldn't hurt to install all the latest clients, manager and whatnot. My other (older) system was working fine so I figured (maybe too late) that it could be something wrong with a specific version.

Version numbers:
Git: git version 2.10.0.windows.1
GCMW: 1.8.0

shiftkey · 2016-12-08T02:41:49Z

@TonDekker @whoisj is it worth looking into whether this is reproducible with 2.11.0.windows.1, which comes with GCM 1.8.1?

TonDekker · 2016-12-08T08:06:54Z

@shiftkey why shouldn't it ;) All I know is that 2.11.0.windows.1 and the supplied GCM with it, doesn't work with an on-premise TFS 2015, Update 3 .

dscho · 2016-12-08T09:47:47Z

I tried to reproduce this (using access I was provided by colleagues of mine), failing to do so.

However, I have a hunch that git credential-manager clear before trying again may work around the problems.

shiftkey · 2016-12-08T10:38:57Z

@TonDekker apologies, i didn't notice that you'd used 2.11.0 in the initial test 😀

nilleb · 2016-12-08T11:04:52Z

Using git 2.11.0

clearing the cache of the credential-manager doesn't improve the situation
changing the credential helper to 'store' in th file file:"C:\Program Files\Git\mingw64/etc/gitconfig" doesn't improve the situation

    > set GIT_TRACE=1
    > git fetch origin

    12:03:07.105602 git.c:371               trace: built-in: git 'fetch' 'origin'
    12:03:07.117696 run-command.c:350       trace: run_command: 'git-remote-http' 'origin' 'http://tfs:8080/tfs/COLLECTION/TeamProject/_git/project'
    12:03:07.158706 run-command.c:350       trace: run_command: 'git credential-store get'
    12:03:07.209489 git.c:607               trace: exec: 'git-credential-store' 'get'
    12:03:07.211470 run-command.c:350       trace: run_command: 'git-credential-store' 'get'
    12:03:07.235469 run-command.c:350       trace: run_command: 'git credential-store get'
    12:03:07.281346 git.c:607               trace: exec: 'git-credential-store' 'get'
    12:03:07.282362 run-command.c:350       trace: run_command: 'git-credential-store' 'get'
    12:03:07.305347 run-command.c:350       trace: run_command: 'bash' '-c' 'cat >/dev/tty && read -r line </dev/tty && echo "$line"'
    Username for 'http://tfs:8080':
    12:03:09.432042 run-command.c:350       trace: run_command: 'bash' '-c' 'cat >/dev/tty && read -r -s line </dev/tty && echo "$line" && echo >/dev/tty'
    Password for 'http://tfs:8080':
    12:03:09.894621 run-command.c:350       trace: run_command: 'git credential-store erase'
    12:03:09.944980 git.c:607               trace: exec: 'git-credential-store' 'erase'
    12:03:09.946969 run-command.c:350       trace: run_command: 'git-credential-store' 'erase'
    12:03:09.975873 run-command.c:350       trace: run_command: 'git credential-store erase'
    12:03:10.020097 git.c:607               trace: exec: 'git-credential-store' 'erase'
    12:03:10.021096 run-command.c:350       trace: run_command: 'git-credential-store' 'erase'
    fatal: Authentication failed for 'http://tfs:8080/tfs/COLLECTION/TeamProject/_git/project/'

dscho · 2016-12-08T14:52:07Z

Ah! I think I found something. Could you try again after git config --global http.emptyAuth true?

nilleb · 2016-12-08T15:08:00Z

@dscho bingo. that's it, congratulations. and, btw, thanks for your responsiveness and your help.

This merges the "Pre-release to test fixes for #981 and #987". These commits were actually meant to land in `master` before merging the Pull Requests; Better late than never. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes #987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Implicit NTLM authentication [works again](git-for-windows/git#987) when accessing a remote repository via HTTP/HTTPS without having to specify empty user name and password. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes #987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes git-for-windows#987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes #987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes git-for-windows#987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes #987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes git-for-windows#987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: David Turner <dturner@twosigma.com>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes git-for-windows#987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

It is common in corporate setups to have permissions managed via a domain account. That means that the user does not really have to log in when accessing a central repository via https://, but that the login credentials are used to authenticate with that repository. The common way to do that used to require empty credentials, i.e. hitting Enter twice when being asked for user name and password, or by using the very funny notation https://:@server/repository A recent commit (5275c30 (http: http.emptyauth should allow empty (not just NULL) usernames, 2016-10-04)) broke that usage, though, all of a sudden requiring users to set http.emptyAuth = true. Which brings us to the bigger question why http.emptyAuth defaults to false, to begin with. It would be one thing if cURL would not let the user specify credentials interactively after attempting NTLM authentication (i.e. login credentials), but that is not the case. It would be another thing if attempting NTLM authentication was not usually what users need to do when trying to authenticate via https://. But that is also not the case. So let's just go ahead and change the default, and unbreak the NTLM authentication. As a bonus, this also makes the "you need to hit Enter twice" (which is hard to explain: why enter empty credentials when you want to authenticate with your login credentials?) and the ":@" hack (which is also pretty, pretty hard to explain to users) obsolete. This fixes #987 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho added mcve-required unclear labels Dec 8, 2016

dscho self-assigned this Dec 9, 2016

dscho added this to the v2.11.1 milestone Dec 9, 2016

dscho added bug git and removed mcve-required unclear labels Dec 9, 2016

dscho closed this as completed in 114042a Dec 12, 2016

whoisj mentioned this issue Dec 21, 2016

Doesn't "Magically" Work for Me microsoft/Git-Credential-Manager-for-Windows#337

Closed

whoisj mentioned this issue Jan 5, 2017

Installer fails to deploy and enable git credential manager properly microsoft/Git-Credential-Manager-for-Windows#351

Closed

whoisj mentioned this issue Jan 13, 2017

Not being prompted for credentials since domain pw change (and attempts to fix which may have made it worse) microsoft/Git-Credential-Manager-for-Windows#355

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fatal: authentication failed for 'http://tfs:8080/tfs/Collection/TeamProject/_git/Project/' #987

fatal: authentication failed for 'http://tfs:8080/tfs/Collection/TeamProject/_git/Project/' #987

nilleb commented Dec 7, 2016

nilleb commented Dec 7, 2016

whoisj commented Dec 7, 2016 •

edited

Loading

TonDekker commented Dec 7, 2016 •

edited

Loading

whoisj commented Dec 7, 2016

TonDekker commented Dec 7, 2016 •

edited

Loading

shiftkey commented Dec 8, 2016

TonDekker commented Dec 8, 2016

dscho commented Dec 8, 2016

shiftkey commented Dec 8, 2016

nilleb commented Dec 8, 2016 •

edited

Loading

dscho commented Dec 8, 2016

nilleb commented Dec 8, 2016

fatal: authentication failed for 'http://tfs:8080/tfs/Collection/TeamProject/_git/Project/' #987

fatal: authentication failed for 'http://tfs:8080/tfs/Collection/TeamProject/_git/Project/' #987

Comments

nilleb commented Dec 7, 2016

Setup

Details

nilleb commented Dec 7, 2016

whoisj commented Dec 7, 2016 • edited Loading

TonDekker commented Dec 7, 2016 • edited Loading

whoisj commented Dec 7, 2016

TonDekker commented Dec 7, 2016 • edited Loading

shiftkey commented Dec 8, 2016

TonDekker commented Dec 8, 2016

dscho commented Dec 8, 2016

shiftkey commented Dec 8, 2016

nilleb commented Dec 8, 2016 • edited Loading

dscho commented Dec 8, 2016

nilleb commented Dec 8, 2016

whoisj commented Dec 7, 2016 •

edited

Loading

TonDekker commented Dec 7, 2016 •

edited

Loading

TonDekker commented Dec 7, 2016 •

edited

Loading

nilleb commented Dec 8, 2016 •

edited

Loading