Kerberos syncrepl support for OpenLDAP

[Jaap Winius]

On Sun, 10 Jan 2010 12:58:09 +0000, Jaap Winius wrote:

> ... how to configure things so that syncrepl uses Kerberos
> encryption? I know it's possible, using stuff like GSSAPI
> and kinit cron jobs, ...

Okay, I'll answer this one myself.

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).


=== 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


Second, I configured syncrepl in slapd.conf to look like this:

   syncrepl rid=123
        provider=ldap://ldapks.example.com:389/
        type=refreshAndPersist
        retry="60 30 300 +"
        searchbase="dc=example,dc=com"
        bindmethod=sasl
        saslmech=gssapi
        realm=example.com
        authcid="ldap/ldapks2.example.com at EXAMPLE.COM"

NB: ldapks2.example.com is the localhost, while ldapks.example.com is an 
alias for the OpenLDAP provider server.


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.


=== Notes ===

Along the way, I did run into two other problems. One was this syslog 
error message:

   slapd[5395]: SASL [conn=7] Failure: GSSAPI Error: \
   Unspecified GSS failure.  Minor code may provide \
   more information (Key version number for principal \
   in key table is incorrect)

This turned out to be due to an invalid Kerberos ticket on the consumer 
server.

Another, more inexplicable error that I ran into earlier involved running 
an ldapadd that added two entries to the directory on the provider 
server: the first addition would succeed (and make it to the consumer), 
but the second one would not. The reason was that, at hat point, the 
provider slapd had died after writing the first entry to the database. At 
the time, the solution appeared to be to install and configure k5start on 
the provider the same as on the consumer; it seemed like the provider was 
trying to authenticate to the consumer. Unfortunately, I have since not 
been able to reproduce this behavior, so I must conclude that problem was 
likely unrelated and that a k5start configuration on the provider is not 
necessary.

Comments welcome.

Cheers,

Jaap