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/[email protected]" > > 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
