Re: Syncrepl with Kerberos support

Jaap Winius wrote:

Before I begin, let me say that, in this case, Kerberos only offers encrypted authentication and not data encryption for the OpenLDAP replication phase;

False.

for that it is necessary to set up a Certificate Authority and use TLS (LDAP over SSL, slapd on port 636).

When using SASL, you can use a SASL encryption layer with or without an underlying transport encryption layer (TLS/ipSec/...). By default the Kerberos5 SASL/GSSAPI module includes encryption.

This has all been supported in OpenLDAP since .. more than 10 years now. I point this out specifically because until very recently, most other servers did not support it. (E.g., M$ ActiveDirectory did not support SASL encryption on top of TLS until just last year. Likewise with Fedora/RedHat/Netscape.)

=== 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@EXAMPLE.COM"

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

The authcid parameter isn't really needed, since SASL will obtain it from the GSSAPI module anyway.

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.

Configure an explicit list of SASL plugins, or just delete/rename the sasldb plugin. This is all bog-standard Cyrus-SASL administration stuff, nothing particular to OpenLDAP.

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

Ordinarily Kerberos-enabled services don't need tickets, just keytabs.

Since a consumer is actually a client, then all client-credential considerations apply and it's no different from running any other long-lived daemon that uses Kerberos tickets.

It sounds like this was a SASL and Kerberos learning experience for you, not much in this post is specific to OpenLDAP.