h.b.furuseth@usit.uio.no wrote:

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard

If a referral object's "ref" DN differs from the entry DN, and you update a subordinate of the referral object, the DN part of the referral from back-bdb is wrong.

bash$ cat ref.ldif dn: o=we o: we ref: ldap://elsewhere/o=they objectClass: referral objectClass: extensibleObject

dn: cn=me,o=we cn: me objectClass: organizationalRole

bash$ ldapadd ...< ref.ldif adding new entry "o=we"

adding new entry "cn=me,o=we" ldap_add: Referral (10) matched DN: o=we referrals: ldap://elsewhere/cn=me,o=we

It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96:

		rs->sr_ref = referral_rewrite( ref, NULL,
			&op->o_req_dn, LDAP_SCOPE_DEFAULT );

I don't quite understand that function though: Why does it use default_referral (slapd.conf 'referral')? That is for use when no local backend database handles the operation, which I would think means no database's be_chk_referrals() gets be called. And indeed the function uses it if !be_issuffix( op->o_bd,&op->o_req_ndn ) which looks to me like a test for whether this function is _not_ to be called for this database.

I've never understood that function either. ;) It seems completely unnecessary, since the individual operations' code also does referral checks. Can you try testing with be_chk_referrals NULL'd out?