[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:
<http://www.eyrie.org/~eagle/software/kstart/>
You may also want to look at:
<http://www.stanford.edu/services/directory/openldap/configuration/slapd-conf-replica.html>
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 +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++