GitLFS and Azure Devops Server incompatibile on Windows due to credential conflict.

[AJH16]

Which version of GCM are you using? 2.0.785

Which Git host provider are you trying to connect to?

• [ ] Azure DevOps
• [ x] Azure DevOps Server (TFS/on-prem)
• [ ] GitHub
• [ ] GitHub Enterprise
• [ ] Bitbucket
• [ ] Other - please describe

Can you access the remote repository directly in the browser using the remote URL?

• [ x] Yes
• [ ] No, I get a permission error
• [ ] No, for a different reason - please describe

---

[Azure DevOps only] What format is your remote URL?

• [x ] Not applicable
• [ ] https://dev.azure.com/{org}/...
• [ ] https://{org}@dev.azure.com/{org}/...
• [ ] https://{org}.visualstudio.com/...

[Azure DevOps only] If the account picker shows more than one identity as you authenticate, check that you selected the same one that has access on the web.

• [ x] Not applicable
• [ ] I only see one identity
• [ ] I checked each identity and none worked

---

Expected behavior

GitLFS and Git are able to authenticate.

Actual behavior

Azure Devops Server requires that no username be given to use a PAT token for Git authentication, so you must enter AD credentials to successfully log in to Git. It also requires a PAT token for using GitLFS (and discards the username.) Git Credential Manager does not support no user name or using different credentials for Git and GitLFS, so it is impossible to authenticate both at the same time.

Logs

Logs aren't particularly relevant on this one as the authentication failure is purely procedural because of the way the credential flow works.

I've already started experimenting with solutions. I think the ideal solution is probably to allow a setting to prefer using integrated authentication if possible even when a credential is in the credential store. Then it should be possible to use this for the Kerberos login for Git while falling back to the credentials for the PAT when GitLFS can't support integrated auth. There's still a few details I haven't worked out yet, but that's the general direction I've been heading in for a fix.

[elementary-my-friend]

Hi, I don't know what I did on GitHub but it wasn't intentional or even something I understood. I'm very sorry.

I'm dealing with a hacker named Roy Solberg. He's on GitHub and I'm so stressed right now. I don't know what to do! I need him to STOP.

Sincerely, Anne Mare W

On Wed., Aug. 24, 2022, 10:00 p.m. AJ Henderson, @.***> wrote:

Which version of GCM are you using? 2.0.785

Which Git host provider are you trying to connect to?

• Azure DevOps
• [ x] Azure DevOps Server (TFS/on-prem)
• GitHub
• GitHub Enterprise
• Bitbucket
• Other - please describe

Can you access the remote repository directly in the browser using the remote URL?

• [ x] Yes
• No, I get a permission error
• No, for a different reason - please describe

---

[Azure DevOps only] What format is your remote URL?

• [x ] Not applicable
• https://dev.azure.com/{org}/...
• @.***/{org}/...
• https://{org}.visualstudio.com/...

[Azure DevOps only] If the account picker shows more than one identity as you authenticate, check that you selected the same one that has access on the web.

• [ x] Not applicable
• I only see one identity
• I checked each identity and none worked

---

Expected behavior

GitLFS and Git are able to authenticate.

Actual behavior

Azure Devops Server requires that no username be given to use a PAT token for Git authentication, so you must enter AD credentials to successfully log in to Git. It also requires a PAT token for using GitLFS (and discards the username.) Git Credential Manager does not support no user name or using different credentials for Git and GitLFS, so it is impossible to authenticate both at the same time.

Logs

Logs aren't particularly relevant on this one as the authentication failure is purely procedural because of the way the credential flow works.

I've already started experimenting with solutions. I think the ideal solution is probably to allow a setting to prefer using integrated authentication if possible even when a credential is in the credential store. Then it should be possible to use this for the Kerberos login for Git while falling back to the credentials for the PAT when GitLFS can't support integrated auth. There's still a few details I haven't worked out yet, but that's the general direction I've been heading in for a fix.

— Reply to this email directly, view it on GitHub https://github.com/GitCredentialManager/git-credential-manager/issues/849, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABUXTW6DS5DOV6GO2D5UMTTV23HVTANCNFSM57RLJWBA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ldennington]

Thanks for raising this up and working on a fix! Happy to provide a review when it's ready for PR 😊.

[Sk8695451]

autication

[AJH16]

Found an alternate work around that doesn't require this change. Looks like the real underlying issue was an issue in how Git LFS was handling the authentication itself. The underlying issue with the handling of basic auth is still present, but it can be avoided by fixing the kerberos transport issues in Git LFS (for the curious, the transport stream was being automatically upgraded to HTTP2 even though Kerberos, at least on IIS, requires an HTTP1.1 transport.) It was also unnecessarily checking a reverse IP lookup on the name.

I couldn't find a clean way to inform Git Credential Manager whether it was in a Git or Git LFS context without also making coordinated changes on the Git LFS side, and with a more secure work around now (working on a fix on the Git LFS side for the transport issue), this doesn't seem particularly critical.

I'm suggesting closing this issue as I don't think I will have time to complete a solution and I don't think it's critically needed with the other fixes that will allow Azure Devops and Git LFS to operate together properly via Kerberos in a more secure way than using basic auth.

If nobody else has any objections, I'll close it once the fix is in for Git LFS Kerberos.

[ldennington]

Thanks for the deep dive on this @AJH16. I agree that the basic auth issue can be de-prioritized in light of the Kerberos fix in LFS. Your plan to close this issue when those changes complete is also fine - would you mind linking to them here when they're ready, though?

[AJH16]

SureOn Aug 31, 2022 1:05 PM, Lessley Dennington @.***> wrote: Thanks for the deep dive on this @AJH16. I agree that the basic auth issue can be de-prioritized in light of the Kerberos fix in LFS. Your plan to close this issue when those changes complete is also fine - would you mind linking to them here when they're ready, though?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[ldennington]

@AJH16 - is there by chance an LFS issue we can link to and close this issue?

[mjcheetham]

for the curious, the transport stream was being automatically upgraded to HTTP2 even though Kerberos, at least on IIS, requires an HTTP1.1 transport.

Does Git LFS respect the http.version Git config variable? Would forcing Git (and LFS?) to stick to HTTP/1.1 workaround this problem?

[AJH16]

@ldennington I don't know of a linked issue yet.

@mjcheetham Git LFS does not respect it, but setting it does work because the session that is open is HTTP/1.1, so the logic that reuses the existing connection doesn't end up finding an HTTP/2 connection if Git itself is using HTTP/1.1.

[ldennington]

Closing - haven't heard back and seems to be an issue with LFS rather than GCM.