RE: SASL/GSSAPI + slurpd replication

["Howard Chu" <hyc@highlandsun.com>]

Sounds like you're making blind guesses, and you're asking us to as well.
Some version numbers would probably help.

A snippet of your slave slapd's debug output would also help. What request
is being made that returns "no such object" ?

I have just now successfully tested this using OpenLDAP 2.1.3, so I know it
works.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support 

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of C. Grierson
> Sent: Thursday, July 11, 2002 12:03 PM
> To: openldap-software@OpenLDAP.org
> Subject: SASL/GSSAPI + slurpd replication
> 
> 
> hello,
> 
> 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
>