[Date Prev][Date Next]
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;
> 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
> 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
> retry="60 30 300 +"
> 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: 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/