SASL/GSSAPI + slurpd

["C. Grierson" <cbgb@u.washington.edu>]

hello all,

i have combed through all 600+ matches for "no such object" and read
through turbo's openldap howto thoroughly, and yet i still can't get
my SASL/GSSAPI slurpd replication to work.  like others with this issue,
all other functionality works; i can bind to the slave and search
around with 'ldapsearch' (and see sensitive data) via SASL, and i can
even use 'ldapmodify' to submit the rejected slurpd modifications via
SASL.  my slave has the EXACT same data, as i simply copied the .dbb files
from the master (and, yes, i had the same problems when populating the
slave from an LDIF).

i have convinced myself from other peoples' experiences and my own, that
it is an access control problem.  when i change my updatedn to gibberish
(just to see what happens), i notice that the error becomes "insufficient
access".  interesting, since this would somehow mean that the updatedn is
being recognized as 'special' (in that it gives "no such object" errors,
as opposed to the access errors for all other updatedns).

i noticed that on turbo's site (bayour.com), the suggested updatedn,
"uid=replicator.+\+realm=FOO" will halt my slave slap in it's tracks with
an "invalid dn" error from the config file on startup.  i've noticed in
the debug output that the actual dn that gets used is
"uid=replicator+realm=foo" (foo being my realm), and using a single '.'
works for the binds.

in any case, this is driving me nuts, as it seems that everything should
be working...  i can see that slurpd binds with the same dn as ldapXXX
does when using SASL, so what could possibly be the problem...?

thanks very much in advance,

-chris grierson