[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd/slurpd replication log not written to

--On Thursday, August 10, 2006 5:27 PM +0100 Juliet Kemp <j.kemp@imperial.ac.uk> wrote:

Many thanks for this.  It turned out that my problem was indeed to do
with Kerberos auth.  The authz-regexp stuff was fine; the problem was
that I was trying to use slurpd_adm as the replicator DN/ticket, but
ldapadm as the usual admin DN/ticket.  Thus during my test runs, I would
kinit as ldapadm; which meant that slurpd was using this available
ticket, but on the slave server ldapadm was not set up as the replication
DN so replication failed.

On altering my setup so that ldapadm was used for all (i.e. was in the
'replica' config on the master, although as above that's not necessary;
had a kerberos ticket on the master; was the updatedn value on the slave;
and had appropriate access on the slave), it worked fine.

Unfortunately, it seems that it's not possible to have 2 Kerberos tickets
active at the same time: i.e. it's not possible for me to set up
slurpd_adm as the replication user, & have k5start managing that ticket,
and then to kinit as ldapadm (the admin user) on the master server - if I
do so, replication stops working.  I.e. the replication user & the admin
user need to be the same if one wishes to be able to run admin tasks
whilst logged on to the master server.

I ran my servers this way for years and didn't have any such problem. All you need to do is have a slurpd init script that sets the KRB5CCNAME variable to point to a file other than *your* ticket cache. Otherwise, yes, getting a new ticket will blow away the existing ticket cache, which you don't want. And then only start/stop slurpd with the init script. For example, mine had:

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

And then I set up k5start to keep /tmp/ldap_replicator.tkt renewed with the Kerberos principal in the keytab for slurpd replication.

You can do something similar if you switch to (delta-)syncrepl as well. I simply have the replicas use their host keytab to maintain a ticket that is authorized to bind and search the master as needed.

I also discovered that it seems that extracting a user to a keytab then
prevents one from being able to kinit as that user with the normal
password.  (These are both really Kerberos issues, but I mention them
here in case anyone is looking through the archive due to encountering
similar problems!).

This is why we have "service" principals, which are not real users, and thus never exist in anything outside of a keytab. Then we can assign keytabs to our many applications and not worry about them conflicting with user-space.


Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html