Kerberos syncrepl support for OpenLDAP

[Russ Allbery]

Jaap Winius <jwinius at umrk.nl> writes:

> Before I begin, let me say that, in this case, Kerberos only offers
> encrypted authentication and not data encryption for the OpenLDAP
> replication phase; for that it is necessary to set up a Certificate
> Authority and use TLS (LDAP over SSL, slapd on port 636).

That doesn't sound right.  GSSAPI offers confidentiality and OpenLDAP in
general knows how to use GSSAPI via SASL to obtain confidentiality.

I don't know specifically how to configure it for syncrepl, though.

> === My solution ===

> First download k5start (currently found at eyrie.org), compile and 
> install it on the OpenLDAP consumer server. Then create a simple script 
> on this host that uses k5start to automatically obtain and periodically 
> renew a Kerberos TGT for the LDAP service principal (you could use kinit 
> and a cron job instead, but that solution apparently has certain 
> weaknesses). Also, the script must run as the user that runs slapd (in my 
> case the openldap user). The relevant command I used was:

>    su -c "/usr/local/bin/k5start -U -f /etc/krb5.keytab \
>    -K 10 -l 24h &" -l openldap

> Of course, don't forget to edit /etc/passwd and change the shell setting
> for the openldap user to /bin/sh, or else it won't work

Rather than backgrounding k5start using the shell, you probably want to
use its -b flag.  Note that this flag combination will authenticate using
the first key listed in your /etc/krb5.keytab, which at many sites will be
the host/* key instead of the ldap/* key.

You can run k5start as root and have it chown the ticket cache to another
user, rather than having to change the shell of the openldap user.  Either
way will work, depending on which you prefer.

> Third, it was all was working at this point, except that an an error
> kept appearing in the OpenLDAP provider's syslog:

>     SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: \
>     No such file or directory

> There should be a better way to fix this, but I did it by installing a
> Debian package, called sasl2-bin. This automatically created the
> necessary database file, /etc/sasldb2 database, although I had to be
> careful give the openldap user permission to write to it. Slapd never
> seems to do that, but at least this prevented it from complaining.

I think the "right" way to fix this is to disable the SASL sasldb
authentication type, although I don't know exactly how to do that.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>