Re: syncrepl 'access to' constraints

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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