Gerrit 2.15.12 - Kerberos + GSSAPI + Active Directory - possible bug in sending SPN

Question

Running on RHEL 7.5 with Java 8. Kerberos 5 release 1.15.1.

We are seeing a strange behaviour with this set-up that has been seen in all versions since 2.11.10.

Note, I can't post direct logs or config as it my company blocks this.

Steps to reproduce

1) Configure gerrit to use kerberos

gerrit.config

[container]
javaHome = <path to JRE>
javaOptions = -Djava.security.auth.login.config=<path to jaas.conf>

[auth]
type = LDAP

[ldap]
authentication = GSSAPI
server = ldap://<AD Realm>
<.. other AD related stuff..>

jaas.conf

KerberosLogin {
    com.sun.security.auth.module.Krb5LoginModule
            required
            useTicketCache=true
            doNotPrompt=true
            renewTGT=true;
};

which is direct from the documentation.

2) kinit the keytab to create a ticket in the cache. 3) Try to login. It fails with "Server not found in Kerberos database (7)".

It will also fail if you change the jaas.conf to try and use the keytab directly.

You can access LDAP directly using the username/password but due to Company restrictions we can't have an unencrypted password at rest on a device so this is not a viable long, term solution.

We have taken packet captures of the traffic to the AD Realm and we see the same behaviour whether we use the keytab or the cache.

1) For the kinit we see one request to AD with the SPN field set to the SPN from the keytab. This, of course, works fine. 2) For any request from Gerrit we see TWO requests to AD, the first has the correct SPN from the cache/keytab the second tries to send an SPN of "ldap/" no matter what value of SPN is set. This second request is what is causing the error as that SPN is not recognised b AD.. Note, we have tried keytabs with various SPN's (HTTP/device, host/device, HTTP/device@ etc etc). The same thing happens every time.

This may well be something very simple is wrong in our config but we have been banging our heads on this for weeks now.

Answer 1

The second request most likely shows up because you specified an LDAP server ldap://<AD Realm> in Gerrit's configuration. HTTP GSSAPI authentication may very well have succeeded at this point, but now the application needs to authenticate itself against the LDAP server before it can retrieve information about the user. That happens independently from the HTTP authentication itself.

It's normal that the SPN is not recognized because Active Directory generally doesn't use <AD Realm> to pick a domain controller – instead the individual server names have to be specified, eg ldap://dc01.ad.example.com . (Real AD clients choose a server automatically via DNS SRV records, but plain LDAP clients often don't support that.)

Note also that a keytab is essentially an unencrypted password at rest.