I run LDAP + Kerberos on my network for information and authentication. After setting everything up initially, I later acquired a spare machine and decided to run it as a slave LDAP server, using slurpd.

Executive summary: if trying to use two different Kerberos-authenticated users at the same time, you need to set the KRB5CCNAME value accordingly. Details follow…

The first thing I discovered was that the replog should in general be empty, because slurpd truncates it immediately on read. (in other words: an empty replog is not on its own the source of your problems!) Note that slurpd doesn’t have to do a full successful transfer to the slave server in order to do the truncating.

Setting rootdn and rootpw on the slave server got it working, but this was suboptimal; I wanted GSSAPI auth like everything else in the setup. Setup was as follows:

• rep_adm as replication admin; gen_adm as ‘general’ admin.
• Master replication config:

  replica uri=ldaps://server2.ph.ic.ac.uk:636
      tls=yes
      bindmethod=sasl
      binddn="uid=rep_adm,ou=people,dc=ph,dc=ic,dc=ac,dc=uk"
      saslmech=GSSAPI
  

  (Note that SASL/GSSAPI doesn’t have a bind dn; however, you have to put that in the replica statement anyway as it’s required.)
• Slave config:

  updatedn        "uid=rep_adm,ou=people,dc=ph,dc=ic,dc=ac,dc=uk"
  updateref       ldaps://server1.ph.ic.ac.uk
  
  access to *
          by dn="uid=gen_adm,ou=people,dc=ph,dc=ic,dc=ac,dc=uk" write
          by dn="uid=rep_adm,ou=people,dc=ph,dc=ic,dc=ac,dc=uk" write
          by * read
  

This generated the following problems:

• ERROR: Referral

  in the .rej file.
• Slave logs showed that halfway through slurpd seemed to switch from using rep_adm to using gen_adm.

It transpired that my first problem was that I was using rep_adm for replication, but gen_adm for my test runs. I would kinit as gen_adm to run the test, at which point slurpd would use this available ticket to attempt to replicate. However, on the slave server, gen_adm wasn’t set up as the updatedn; so replication failed. Altering the setup so that gen_adm was used throughout did the trick.

However, I wasn’t happy with that. I initially thought that k5start (a utility for managing Kerberos tickets for this sort of purpose) couldn’t keep 2 tickets active at the same time. However, in fact this is not the case, as was explained to me. I set up my slapd init script (which also starts slurpd and k5start to include this:

KRB5CCNAME="FILE:/tmp/ldap_replicator.tkt"
export KRB5CCNAME

.....

start_slurpd() {
    if [ "$SLURPD_START" != yes ]; then
        return 0
    fi
    echo -n " slurpd"
    reason="`start-stop-daemon --start --quiet --oknodo \
        --exec /usr/sbin/slurpd -- $SLURPD_OPTIONS 2>&1`"
    echo -n " k5start"
    # Start kstart in order to manage replication
    reason_kstart="`start-stop-daemon --start --pidfile \
        /var/run/k5start.pid \
        --exec /usr/bin/k5start -- -b -K 10 \
        -k /tmp/ldap_replicator.tkt \
        -p /var/run/k5start.pid \
        -f /etc/ldap/slurpd.keytab rep_adm`"
}

(reason and reason_kstart were caught separately elsewhere in the script so that a failure of kstart wouldn’t cause the total failure of the LDAP server).

All now functions happily. Much thanks due to the openldap-software list who are extremely helpful folk. Note that you will also need to ensure that your authz-regexp (used to be sasl-regexp) setup is correct (mine was already in place from initial server/client setup).

(Another discovery made along the way: extracting a user to a keytab then prevents one from being able to kinit as that user with the normal password. This, as was pointed out to me, is a Good Reason to have “service” principals, which can be extracted to keytabs and don’t interfere with userspace.)