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

Re: slapd/slurpd replication log not written to

Quanah Gibson-Mount wrote:

--On Wednesday, August 09, 2006 11:47 AM +0100 Juliet Kemp <j.kemp@imperial.ac.uk> wrote:

[ master / slave LDAP setup using SASL/GSSAPI auth ]

SASL/GSSAPI doesn't have a bind dn. The DN is determined either by a authz-regexp mapping the SASL Identity to an entry in the directory, or by the SASL identity itself, if there isn't one. However, IIRC, you still have to specify the binddn parameter in the replica statement, it is essentially pointless.

OK, right.

For GSSAPI replication to work correctly, you'll need to give slurpd access to a ticket in its environment (KRB5CCNAME generally). I would suggest a utility like kstart for keeping the ticket refreshed, see:


You may also want to look at:


for an example of authz-regexp statements (which used to be called sasl-regexp).

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 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!).

Anyway: all is now working satisfactorily, thanks very much for the assistance!

Regards, Juliet

+ Ms Juliet Kemp                                                +
+ Computer Manager		            star@imperial.ac.uk         +
+ Astrophysics Group                                            +
+ Imperial College                  Tel: +44 (0)20759 47538     +
+ London. SW7 2AZ                   Fax: +44 (0)20759 47541     +