Kerberos through loadbalancer

[Stefan Kania]

Hi to all,

we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
securing the replication via kerberos, everything works fine between the
providers. But now we want to set up some consumers. Between the
providers and the consumers a loadbalancer is located, so the consumers
only connect to the loadbalancer and the loadbalancer chooses one of the
providers. For the replication we put the fqdn from the loadbalancer
into the configuration. The fqdn is ldap.example.net. We then created a
host-principal and a service-principal for ldap.example.net and we put
the host-key into /etc/krb5.keytab of all ldap-providers the same with
the service-key. So now all provider can use both, the own keys and the
keys from the loadbalancer. But it's not working :-(. In the log of the
provider we see that the consumer connects. ldaps is working. But
kerberos failed with the following messages:
--------------------
SASL [conn=5032] Failure: GSSAPI Error: Miscellaneous failure (see
text) (Decrypt integrity check failed for checksum type
hmac-sha1-96-aes256, key type aes256-cts-hmac-sha1-96)

slapd[59382]: conn=5032 op=0 RESULT tag=97 err=49 qtime=0.000028
etime=0.017274 text=SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context

--------------------
The same user we are using works without using the loadbalancer. If our
solution is wrong, what would be the right way to use a loadbalancer
together with kerberos?

Stefan

[Stefan Kania]

Here the messages we get using ldapsearch on one of the consumers:
---------------
ldapsearch -H ldaps://ldap.example.net
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind: Invalid credentials (49)
additional info: SASL(-13): authentication failure: GSSAPI Failure:
gss_accept_sec_context


$ klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: search-repl@

Valid starting Expires Service principal
05/20/2022 09:46:35 05/20/2022 19:46:35 krbtgt/DE@DE
renew until 05/21/2022 09:46:35
05/20/2022 09:46:50 05/20/2022 19:46:35 ldap/consumer01@DE
renew until 05/21/2022 09:46:35
05/20/2022 09:47:07 05/20/2022 19:46:35 ldap/ldap1@DE
renew until 05/21/2022 09:46:35
05/20/2022 09:47:24 05/20/2022 19:46:35 ldap/ldap@DE
renew until 05/21/2022 09:46:35

---------------
As you can see we get the ticket for ldap.

Stefan

Am 20.05.22 um 09:41 schrieb Stefan Kania:

> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

[Russ Allbery]

Stefan Kania <ste...@kania-online.de> writes:

> we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
> securing the replication via kerberos, everything works fine between the
> providers. But now we want to set up some consumers. Between the
> providers and the consumers a loadbalancer is located, so the consumers
> only connect to the loadbalancer and the loadbalancer chooses one of the
> providers. For the replication we put the fqdn from the loadbalancer
> into the configuration. The fqdn is ldap.example.net. We then created a
> host-principal and a service-principal for ldap.example.net and we put
> the host-key into /etc/krb5.keytab of all ldap-providers the same with
> the service-key. So now all provider can use both, the own keys and the
> keys from the loadbalancer. But it's not working :-(.

Two things to check:

First, how did you put the service kep for ldap/ldap.example.net onto each
host? If you used ktadd via kadmin, you alas did not do that. Each time
you downloaded the keytab entry, ktadd randomized the key again, so only
the last host on which you put the key has a correct key and all of the
rest have incorrect keys.

You have to either manually copy the keytab file between hosts without
running ktadd again, or somehow use -norandkey to generate the keytab
entry.

If that's not the problem, it used to be that you had to apply a one-line
patch to Cyrus SASL to prevent it from forcing Kerberos to only use the
keytab entry that it thought corresponded to the local hostname, which
otherwise would prevent this trick from working. I thought Cyrus SASL
upstream had finally taken that patch and included it in a release, but
maybe you're using an old version of Cyrus SASL? I don't remember what
error message that used to produce, though, so maybe this is a different
problem.

--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>

[Stefan Kania]

Hi Russ

Am 20.05.22 um 18:45 schrieb Russ Allbery:

> Stefan Kania <ste...@kania-online.de> writes:
>
>> we have 4 ldap-provider ldap1.example.net to ldap4.example.net. We
>> securing the replication via kerberos, everything works fine between the
>> providers. But now we want to set up some consumers. Between the
>> providers and the consumers a loadbalancer is located, so the consumers
>> only connect to the loadbalancer and the loadbalancer chooses one of the
>> providers. For the replication we put the fqdn from the loadbalancer
>> into the configuration. The fqdn is ldap.example.net. We then created a
>> host-principal and a service-principal for ldap.example.net and we put
>> the host-key into /etc/krb5.keytab of all ldap-providers the same with
>> the service-key. So now all provider can use both, the own keys and the
>> keys from the loadbalancer. But it's not working :-(.
>
> Two things to check:
>
> First, how did you put the service kep for ldap/ldap.example.net onto each
> host? If you used ktadd via kadmin, you alas did not do that. Each time
> you downloaded the keytab entry, ktadd randomized the key again, so only
> the last host on which you put the key has a correct key and all of the
> rest have incorrect keys.

We created one keytab for each host and each service. One ldap-key for
each ldap(1..4).example.net and one for ldap.example.net We then put the
key from ldap.example.net to all ldap(1..4).keytab with ktutil. We
checked the KVNO and everything is ok there. So no two different keys.

>
> You have to either manually copy the keytab file between hosts without
> running ktadd again, or somehow use -norandkey to generate the keytab
> entry.
>
> If that's not the problem, it used to be that you had to apply a one-line
> patch to Cyrus SASL to prevent it from forcing Kerberos to only use the
> keytab entry that it thought corresponded to the local hostname, which
> otherwise would prevent this trick from working. I thought Cyrus SASL
> upstream had finally taken that patch and included it in a release, but
> maybe you're using an old version of Cyrus SASL? I don't remember what
> error message that used to produce, though, so maybe this is a different
> problem.

We use debian 11 and the packages from Debian. Do you have some more
information about the patch?
>

We use use "Layer 4 Load Balancing Direct Server Return Mode" on the
loadbalancer. So now NAT. So only the MAC-address is changed on the
loadbalancer. The consumer is only talking to ldap.example.net, the
loadbalancer.