I think that some access rules are missing for the user, something like contextCSN in the user dn.
The only requirement is that the DN that is used as the binddn in the syncrepl statement on the consumer must have read access to all the attributes that are required to be replicated to the consumer, plus the entryCSN/entryUUID on all the entries that must be replicated, plus the contextCSN on the basedn. Additionally, the DN must have a sufficiently large "quota" (time/size limits) to retrieve the entire contents that matches the filter used in the consumer configuration.
I have a single master server replicating with syncrepl a consumer openldap. The same version 2.3.30-5 of openldap is used on every server on the same OS debian etch.
The user for the syncrepl has full read access to every entry in the provider so I think thera are no problems for the replication, in fact if I modify the attribute with a different user the replace is correctly replicated.
The problem is with the user making the replace of the attribute.
Since the Radius User must only write a single attribute I have just inserted the rule for the single attribute
access to attrs=RASPassword [...] by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" write
This way I can change the attribute using ------- ldapmodify -x -f cambia_raspwd.ldif -D "cn=Radius User,ou=SysAccount,o=engineering,c=it" -W ------- but the replace is not propagated to the consumer.
If I insert a _read_ access for the Radius User to the tree containing the entries whose RASPassword is going to be changed
access to dn.subtree="ou=Persone,o=Engineering,c=IT" [...] by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" read
the change on the attribute is correctly replicated to the consumer!
I don't know why but without the read access granted to the Radius User the replace modify is not propagated to the consumers. What am I missing? Hope I have provided enough info. Thanks Mau