How does a git-clone look like with Kerberos authentication?

In our setup we have FreeIPA to authenticate users and we have a GitLab server where the users are all from FreeIPA (basically LDAP).

There is a howto page[1] describing integration of Kerberos in GitLab. I’ve done all that, but now comes the question: how do I use it? Can I simply use the https URL for cloning? So far that doesn’t work. I do have a TGT (Kerberos ticket) and that ticket works with other services that authenticate with it.

Does anyone have such a setup? FreeIPA + GitLab (EE)? Any hint is appreciated.

[1] https://docs.gitlab.com/ee/integration/kerberos.html

Have you followed this step?

When you press the Clone button a Kerberos entry should be visible but this is not really necessary, the latest releases automatically switching to Kerberos for the “normal” https URL.

Yes, I did. However, the description isn’t quite clear, at least not for me. O, and I didn’t see a Clone button.

Anyway, as a user I wasn’t able to get past Social sign-in as “Kerberos Spnego”. This is in the User Settings > Account tab. Clicking “Connect” gives me a 401. The reason is probably that the browser session does to have a TGT.

As an admin I could add a new “Identity” to my account, which I entered as keesb@EXAMPLE.COM.

So, first of all, I wanted to know if this was the right way to “attach” my Kerberos identity to my GitLab account.

Next, I would like to know if I can simply use a https URL to clone a repo. I tried but it asks for a username and a password. The whole exercise to use Kerberos is to not having to fill in user/password.

Ah, now I see what you mean by the clone button. Ha, ha. I’m an old-school command line guy.

The syntax of the URL is

https://:@gitlab.example.com/mygroup/myproj.git

I’m a step further. Arriving at the following:

$ git clone https://:@gitlab.example.com/mygroup/myproj.git
Cloning into 'myproj'...
remote: HTTP Basic: Access denied
fatal: Authentication failed for 'https://:@gitlab.example.com/mygroup/myproj.git/'

There is a valid TGT. Now I must find a way to debug this further.

Oh, and before someone tells me, I already tried this, It didn’t help

git config --global http.emptyAuth true

When the Connect step is not working all other action will not work! Have you tried another another application to see that your Browser setup is correct? What OS you’re on, what Browser?

Adding the UPN as admin for other users was not really working on my system?! Each user must do this.

Linux - Firefox

BTW, what is UPN?

To make things worse, my runners now also give this HTTP Basic: Access denied error. I reverted the config changes for Kerberos. Still it took a while until the runners were succeeding again.

Have you tested the setup of your Browser with another HTTP based service which is configured for Kerberos? There are a lot of possible reasons that the Kerberos authentication is not working…

keesb@EXAMPLE.COM - this is the User Principal Name of your account. When your KDC is a MS AD this is all in uppercase: KEESB@EXAMPLE.COM. Except for MS AD this is case sensitive!

What permissions are set for the keytab file, should be 600 for git:root or GitLab is not able reading the file -> possible 401.

Have you tried getting a TGT for the service account (SPN) in the keytab? The SPN must use the hostname/A record of your GitLab server.

When you have tried logging in you should see a token for the SPN running klist.

Regarding the runner issue have a look here.

I don’t know if I have one. Perhaps the webserver of my FreeIPA master can do that.

In that case, yes the UPN is alright. BTW The KDC is FreeIPA.

keytab has mode 600 for git:git. GitLab should be able to read it.

What command can I use for that? kinit?

Thanks.
This looks nasty. I never thought it would be that hard to enable Kerberos in GitLab.

Setting up Kerberos auth. is not the easiest thing when you start from scratch…

I’m not familiar with FreeIPA, sorry. I think the quickest way setting up a Kerberos based service is an Apache. A direction could be this link, alternatively ask Google to find an example for your OS.

A short guide for Firefox Kerberos you’ll find here.

To test the keytab run this: kinit -kt /etc/keytab HTTP/<HOSTNAME>@<DOMAIN>. The SPN you get with klist -kte /etc/keytab.

Yes, that’s working. For the FreeIPA master web server I am automatically logged in with my Kerberos credentials. (I needed to allow my domain in Firefox network.negotiate-auth.trusted-uris. I had already added FreeIPAs CA cert.)

What’s about the keytab file test?

First, I don’t just execute commands as root. The file /etc/keytab does not exist.
However, I can show the keytab file that I created for GitLab.

git@git:~$ klist -kte /etc/gitlab/http.keytab | sed -e '...'
Keytab name: FILE:/etc/gitlab/http.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 03/27/2020 14:45:11 HTTP/git.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 
   1 03/27/2020 14:45:11 HTTP/git.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 
   1 03/27/2020 14:45:11 HTTP/git.example.com@EXAMPLE.COM (des3-cbc-sha1) 
   1 03/27/2020 14:45:12 HTTP/git.example.com@EXAMPLE.COM (arcfour-hmac) 
   1 03/27/2020 14:45:12 HTTP/git.example.com@EXAMPLE.COM (camellia128-cts-cmac) 
   1 03/27/2020 14:45:12 HTTP/git.example.com@EXAMPLE.COM (camellia256-cts-cmac) 

OK. now I see how kinit works.

git@git:~$ klist
klist: Credentials cache keyring 'persistent:113:113' not found
git@git:~$ kinit -kt /etc/gitlab/http.keytab HTTP/git.example.com
git@git:~$ klist
Ticket cache: KEYRING:persistent:113:113
Default principal: HTTP/git.example.com@EXAMPLE.COM

Valid starting       Expires              Service principal
03/31/2020 16:41:19  04/01/2020 16:41:19  krbtgt/EXAMPLE.COM@EXAMPLE.COM

Ok this all looks good. Is git.example.com the A Record of the server or a CNAME?

Have you checked the blocked users list in the admin page of GitLab? When you see an account with your UPN delete it and try again the Connect thing.

Is there a service token for git.example.com when you run klist after a login try? Something like this:

klist
Ticket cache: KEYRING:persistent:113:113
Default principal: HTTP/git.example.com@EXAMPLE.COM

Valid starting       Expires              Service principal
03/31/2020 16:41:19  04/01/2020 16:41:19  krbtgt/EXAMPLE.COM@EXAMPLE.COM
03/31/2020 16:41:19  04/01/2020 16:41:19  HTTP/git.example.com@EXAMPLE.COM

The service token is delivered by the KDC even when you’re not registered/allowed to access the service.

Have you checked the log files for entries related to authentication?

It’s an A record.

At the moment I have Kerberos disabled because the runners were failing. So the webserver isn’t playing the Kerberos game right now.

Would you know offhand if GitLab-ce supports Kerberos? If it does I could setup a test server just for Kerberos testing.