Re: Syncrepl with Kerberos support

[Howard Chu <hyc@symas.com>]

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.

-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/