[Date Prev][Date Next]
Re: Syncrepl with Kerberos support
Quoting Jaap Winius <email@example.com>:
Although I know how to configure syncrepl with the "simple" bindmethod,
using a clear-text password exchange and clear-text database
replication, and I know how to setup an provider server with MIT
Kerberos V encryption support, can anyone explain how to configure a
consumer so that syncrepl also uses Kerberos?
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
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:
retry="60 30 300 +"
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
slapd: 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
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.