Kerberos auth not working when accessing repo via HTTPS using CNAME #4400
Comments
|
If I understand correctly, there is no out-of-the-box support for Gitea in Git Credential Manager. But there seems to be new OAuth support added in git-ecosystem/git-credential-manager#1047 (see that PR for an example configuration). Here is some documentation how to find the necessary metadata of your Gitea installation: https://docs.gitea.io/en-us/development/oauth2-provider/ See also git-ecosystem/git-credential-manager#879, git-ecosystem/git-credential-manager#1227 and git-ecosystem/git-credential-manager#145. |
To confirm, you're looking to use Kerberos rather than OAuth, username/password, personal access tokens with your internal Gitea instance?
This error message comes from Git, not Git Credential Manager.
I suspect that there's some issue with your DNS setup, given it works correctly with the canonical server hostname. Could you try again with various tracing settings enabled to see what's going on? Please note that the trace output (especially libcurl's) may contain sensitive information so you should review and redact such information before posting. |
Confirmed.
I've double-checked DNS and the CNAME correctly points to the server's canonical hostname.
|
|
Git makes unauthented request and get a libcurl sees this and tries to use Negotiate, but it doesn't get accepted: Git/libcurl, having failed to authenticate, then asks GCM for credentials: GCM returns an empty username/password because it sees that the server supports Negotiate, and wants Git/libcurl will try to use that, but it's already tried that. The real problem here is that first attempt to auth by libcurl isn't working. Do have a trace for when it works, using the other server hostname? |
|
@mjcheetham - sorry for the delay...
|
|
The initial request, apart from the host name and date, are the same, and the response (401) is entirely expected: http.c:724 == Info: Trying 10.7.209.61:443...
- http.c:724 == Info: Connected to ServerHostname.example.org (10.7.209.61) port 443 (#0)
+ http.c:724 == Info: Connected to gitea.example.org (10.7.209.61) port 443 (#0)
http.c:724 == Info: schannel: disabled automatic use of client certificate
http.c:724 == Info: using HTTP/1.x
http.c:683 => Send header: GET /UserName/CodeRepo.git/info/refs?service=git- upload-pack HTTP/1.1
- http.c:683 => Send header: Host: ServerHostname.example.org
+ http.c:683 => Send header: Host: gitea.example.org
http.c:683 => Send header: User-Agent: git/2.40.1.windows.1
http.c:683 => Send header: Accept: */*
http.c:683 => Send header: Accept-Encoding: deflate, gzip, br, zstd
http.c:683 => Send header: Pragma: no-cache
http.c:683 => Send header: Git-Protocol: version=2
http.c:683 => Send header:
http.c:683 <= Recv header: HTTP/1.1 401 Unauthorized
- http.c:683 <= Recv header: Date: Tue, 02 May 2023 18:52:53 GMT
+ http.c:683 <= Recv header: Date: Fri, 28 Apr 2023 16:57:22 GMT
http.c:683 <= Recv header: Server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_auth_gssapi/1.6.1
http.c:683 <= Recv header: WWW-Authenticate: Negotiate
http.c:683 <= Recv header: Content-Length: 381
http.c:683 <= Recv header: Content-Type: text/html; charset=iso-8859-1
http.c:683 <= Recv header:The subsequent (authenticated) request also appears the same at first: http.c:683 => Send header: GET /UserName/CodeRepo.git/info/refs?service=git-upload-pack HTTP/1.1
- http.c:683 => Send header: Host: ServerHostname.example.org
+ http.c:683 => Send header: Host: gitea.example.org
http.c:683 => Send header: Authorization: Negotiate <redacted>
http.c:683 => Send header: User-Agent: git/2.40.1.windows.1
http.c:683 => Send header: Accept: */*
http.c:683 => Send header: Accept-Encoding: deflate, gzip, br, zstd
http.c:683 => Send header: Pragma: no-cache
http.c:683 => Send header: Git-Protocol: version=2
http.c:683 => Send header:
- http.c:683 <= Recv header: HTTP/1.1 200 OK
+ http.c:683 <= Recv header: HTTP/1.1 401 Unauthorized
- http.c:683 <= Recv header: Date: Tue, 02 May 2023 18:52:53 GMT
+ http.c:683 <= Recv header: Date: Fri, 28 Apr 2023 16:57:22 GMT
http.c:683 <= Recv header: Server: Apache/2.4.37 (Red Hat Enterprise Linux) OpenSSL/1.1.1k mod_auth_gssapi/1.6.1
- http.c:683 <= Recv header: WWW-Authenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARufiQLvEOHNEjQZ8/Wncqgg2oNVWyIS0SXTtD2lG0nC8a8mwtwQR/Th3Df32jEYOD5yIW8dLCC9CxqwZyfjqYjwbX4/i7KVaB5DZ8UKT0xeVu0b1Jks7HR2GK3KBuAaqAylkmHrHKs3IJ4rlkgxmc=
- http.c:683 <= Recv header: Cache-Control: no-cache, max-age=0, must-revalidate
- http.c:683 <= Recv header: Content-Type: application/x-git-upload-pack-advertisement
+ http.c:683 <= Recv header: Content-Type: text/html; charset=iso-8859-1
- http.c:683 <= Recv header: Expires: Tue, 01 Jan 1980 00:00:00 GMT
- http.c:683 <= Recv header: Pragma: no-cache
- http.c:683 <= Recv header: X-Frame-Options: SAMEORIGIN
- http.c:683 <= Recv header: Content-Length: 158
+ http.c:683 <= Recv header: Content-Length: 381
- http.c:683 <= Recv header: Set-Cookie: i_like_gitea=c03bebdee2e051a7; Path=/; HttpOnly; SameSite=Lax
- http.c:683 <= Recv header: Set-Cookie: _csrf=NA__fYWuC0zXsDc6M9peqhgmySM6MTY4MzA1MzU3MzY3MTI4NzUxNQ; Path=/; Expires=Wed, 03 May 2023 18:52:53 GMT; HttpOnly; SameSite=Lax
- http.c:683 <= Recv header: Set-Cookie: macaron_flash=; Path=/; Max-Age=0; HttpOnly; SameSite=Lax
http.c:683 <= Recv header:
However, the In any case, at this point the server, when accessed via the CNAME, is immediately returning a 401 response. I can only imagine there's some auth ticket/message validation issue on the server-side, related to the CNAME. I did do a quick search for
|
That SF question has to do with impersonation -- not really relevant to the issue here. Also, note that I already have an SPN for |
|
http.c:724 == Info: Trying 10.7.209.61:443...
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Setup
defaults?
to the issue you're seeing?
I have installed Gitea on a internal RHEL8 server, which is joined to Active Directory. I've configured Apache on that server as a reverse proxy to do SSL termination and Kerberos SSO authentication. I've also set up a CNAME [
gitea.example.org] in DNS for that server to make the URLs more memorable (and shorter).I am able to access the git repos via HTTPS URLs that reference the CNAME using
giton Linux. I can also access the gitea website using Firefox or MS Edge on Windows. All this works seamlessly with Kerberos single sign on, and I'm never prompted for a password nor denied access.When using the git for windows client program, it only works if I use an HTTPS URL with the canonical hostname for the server. However, if the URL uses that CNAME (eg.
https://gitea.example.org/UserName/CodeRepo.git) I getfatal: Authentication failed.Details
cmd.exeMinimal, Complete, and Verifiable example
this will help us understand the issue.
URL to that repository to help us with testing?
Sorry, as mentioned, it's an internal Gitea installation.
The text was updated successfully, but these errors were encountered: