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