On Thursday 25 September 2008 11:36:41 Maurizio Lo Bosco wrote:

...

...

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

You haven't provided enough of your configuration to prove this. Since this is the most likely cause of your problems, you should either ensure this yourself, or provide enough information for people on this list to point out the mistakes ...

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.

With the same ACLs. Somehow I doubt this.

The problem is with the user making the replace of the attribute.

As far as I know about replication, this is impossible.

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

What is the Radius User used for ? Maybe it is also the syncrepl consumer's DN ? Who knows, you don't provide enough information.

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?

You haven't provided the context for this access control entry. You may have added it before the rule allowing your consumer's DN read access to all attributes (we can't tell since you don't provide the rest of your access controls), so since you don't have a clause for your consumer's DN (I assume it is not the rootdn, and also not "cn=Radius User", but since you don't provide your consumer configuration I can't do anything but make assumptions) in the access rule above, this could be the reason why your consumer does not have read access to the affected entries/attributes.

Now, if you don't want real help, keep posting cryptic descriptions with incomplete configuration. I'm not prepared to guess your configuration any further.

Regards, Buchan

Maurizio Lo Bosco wrote:

...

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?

Sounds like you've encountered ITS#5548, fixed in 2.4.11. Hard to tell since that only affects refreshAndPersist and you haven't told us any details of your syncrepl configuration.

I apologise for the incomplete informations.

It is exactly the refreshAndPersist syncrepl

Configuration resume:

Debian Etch stable Openldap 2.3.30-5 on provider and consumer

Consumer syncrepl config in slapd.conf: syncrepl rid=123 provider=ldap://192.168.10.4:389 type=refreshAndPersist interval=00:00:02:00 retry="10 40 60 +" searchbase="o=engineering,c=it" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncuser,ou=sysaccount,o=engineering,c=it" credentials=*****

Provider slapd.conf ----------

[...] sizelimit unlimited backend bdb checkpoint 512 30

database bdb

suffix "o=Engineering,c=IT" rootdn "cn=root,o=Engineering,c=IT" rootpw ******** directory /var/lib/openldap/engineering cachesize 300000

index cn,sn,mail,o,ou pres,eq,sub,subinitial index uid,member,uidNumber,gidNumber,segretaria pres,eq index codicefiscale,statusLdap,statoscadenze,applicazione pres,eq index objectclass,entryCSN,entryUUID pres,eq

moduleload syncprov overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

access to attrs="userpassword" by self write by anonymous auth by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read access to dn.base="o=Engineering,c=IT" by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write by users read access to attrs=RASPassword by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" write by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read access to dn.subtree="ou=Persone,o=Engineering,c=IT" by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read by dn="cn=Radius User,ou=SysAccount,o=engineering,c=it" read access to * by group="cn=staff,ou=Gruppi,o=Engineering,c=IT" write by dn="cn=syncuser,ou=SysAccount,o=Engineering,c=IT" read -----------

The Radius User is only used to write the value of the attribute RASPassword and nothing else, the replication is made with syncuser credentials.

Concerning the bug I think you have got the point! ------------- ITS#5548 Access control rules that uses connection data are evaluated using the wrong connection structure. The problem is in syncprov_matchop() where it around line 1233 assigns:

op2.o_hdr = op->o_hdr;

This causes ACL rules to be tested against the connection that made the change, not the syncrepl connection. It should retain the value from ss->s_op. ------------ in this way when I retrieve data with syncuser credentials, the ACL used to grant the access is the Radius User's ACL which means just read the base dn write the RASPassword

I have no rights to read other entries.

Unfortunately the debian testing is still freezed on the 2.4.10-3. I will bypass the problems using a less restricted ACL for the Radius User. I think the problem can be considered resolved, or at least understood. Thanks again, kind regards Mau