> > 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