Constraint violation: structuralObjectClass: no user modification allow

[openldap <openldap@ayni.com>]

Hi listers,

i have a master LDAP with version openldap-servers-2.3.39-1.fc8,
a slave LDAP with version openldap-servers-2.3.34-0.fc7
a slave LDAP with version openldap-server-2.3.33p1-bdb

the versions are close enough to one another in order to be compatible.

the first two are on fedore 8 and fedora 7, the third on openBSD. from 
the master to the two slaves, slurpd replication is installed.

as the slurpd replication will no longer be available, i started testing 
syncrepl from the third LDAP server onto a fourth one. i wanted to test, 
if i can configure them for refreshAndPersist replication.
to do that i  first configured the third to act as a syncrepl provider 
for the fourth one and then added a new entry in a test subtree on the 
master server.

the following happened: the second server immediately got the changes 
via slurpd and accepted them.
the third server also got the changes but rejected them:
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 fd=20 ACCEPT from 
IP=xx.xx.xx.xx:45565 (IP=0.0.0.0:3
89)
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 op=0 BIND 
dn="cn=manager,dc=mydom,dc=com" method=128
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 op=0 BIND 
dn="cn=Manager,dc=mydom,dc=com" mech=SIMPLE ssf
=0
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 op=0 RESULT tag=97 err=0 
text=
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 op=1 ADD 
dn="cn=wurguri,ou=LDIF-Test,dc=mydom,dc=com"
Mar 14 13:33:33 thirdhost slapd[18518]: conn=6 op=1 RESULT tag=105 
err=19 text=structuralObjectClass: n
o user modification allowed

on the master if found the following in the slurpd-log:

ERROR: Constraint violation: structuralObjectClass: no user modification 
allow
 ed
replica: thirdhost.mydom.com:389
time: 1205498012.0
dn: cn=wurguri,ou=LDIF-Test,dc=mydom,dc=com
changetype: add
sn: wurguri
cn: wurguri
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
structuralObjectClass: inetOrgPerson
entryUUID: 9a3fdcd8-860e-102c-9ead-03486d6a2d35
creatorsName: cn=myuser,ou=pam-ldap,dc=mydom,dc=com
createTimestamp: 20080314123332Z
entryCSN: 20080314123332Z#000000#00#000000
modifiersName: cn=myuser,ou=pam-ldap,dc=mydom,dc=com
modifyTimestamp: 20080314123332Z


as far as i understand, the third LDAP server did not like the 
structuralObjectClass specs. when googling around i found "that it is 
very easy with sed to extract the structuralObjectClass specs" from the 
ldif file.

what do i need to change either on the master, not to let it create ldif 
files which are unaceptable for the other(s), or on the slave to make it 
accept the structuralObjectClass specs?

suomi