Jonathan Boulle wrote: > Sorry, I thought I'd trawled the archives but apparently missed this one. > I'm not alone, this chap already described the exact same issue - although no > solution: > http://www.mail-archive.com/fedora-directory-us...@redhat.com/msg09880.html > It's a bug - can't remember the bug number - you might check the 389 bugs to find this one > -----Original Message----- > From: 389-users-boun...@lists.fedoraproject.org > [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Jonathan > Boulle > Sent: 30 July 2010 17:18 > To: 'General discussion list for the 389 Directory server project.' > Subject: [389-users] Problems with chaining (was: RE: Sanity check for > install approach) > > I've done a colossal amount of reading and experimentation to remedy the > ignorance demonstrated in my last email, so let's start again: > > I have, in a simple two-node (one supplier, one consumer) setup: > - Consumer set up with one local database (replicated from the supplier), + > one database link back to the supplier > - Suffix dc=example using both of these databases, + replication plugin (with > repl_chain_on_update) enabled, + suffix request processing set to "use the > databases" (i.e. no referrals) > - Database link on the consumer using cn=replication manager,cn=config; an > ACI on the supplier of (targetattr = "*")(version 3.0; acl "proxy acl"; > allow(proxy) userdn="ldap:///cn=replication manager,cn=config";) > > So, on a client which is pointed towards the consumer, let's try modify > something: > > [blog...@client02 ~]$ ldapmodify -x -ZZ -D uid=bloggsj,ou=people,dc=example > -w example > dn: uid=bloggsj,ou=People,dc=example > changetype: modify > replace: title > title: Sir > > modifying entry "uid=bloggsj,ou=People,dc=example" > > --- > > > On the supplier I see the relevant bind requests (as replication user *and* > as the bloggsj user, i.e. successfully proxied), and also that the change > succeeds (I turned on some ACL logging): > > <snip> > [30/Jul/2010:17:10:03 +0100] NSACLPlugin - proxied authorization dn is > (uid=bloggsj,ou=people,dc=example) > [30/Jul/2010:17:10:03 +0100] NSACLPlugin - #### conn=26 op=2 > binddn="cn=replication manager,cn=config" > [30/Jul/2010:17:10:03 +0100] NSACLPlugin - #### conn=26 op=2 > binddn="cn=replication manager,cn=config" > <snip> > [30/Jul/2010:16:56:27 +0100] NSACLPlugin - conn=20 op=2 (main): Allow write > on entry(uid=bloggsj,ou=people,dc=example).attr(title) to proxy > (uid=bloggsj,ou=people,dc=example): allowed by aci(51): aciname= "Enable self > write for common attributes", acidn="dc=example <snip> > > Great. Works fine, as expected. But if I try to change the userPassword, for > some reason the database link does _not proxy the authorisation_, but instead > uses the replication user to try make the change: > > [blog...@client02 ~]$ ldapmodify -x -ZZ -D uid=bloggsj,ou=people,dc=example > -w example > dn: uid=bloggsj,ou=People,dc=example > changetype: modify > replace: userPassword > userPassword: abc1...@# > > modifying entry "uid=bloggsj,ou=People,dc=example" > ldapmodify: Insufficient access (50) > additional info: Insufficient 'write' privilege to the 'userPassword' > attribute of entry 'uid=bloggsj,ou=people,dc=example'. > > --- > > On the supplier: > > <snip> > [30/Jul/2010:17:08:13 +0100] NSACLPlugin - #### conn=24 op=2 > binddn="cn=replication manager,cn=config" > <snip> > [30/Jul/2010:16:57:09 +0100] NSACLPlugin - conn=21 op=2 (main): Deny write > on entry(uid=bloggsj,ou=people,dc=example).attr(userPassword) to > cn=replication manager,cn=config: no aci matched the subject by aci(53): > aciname= "self", acidn="dc=example" > <snip> > > > Why do userPassword changes not proxy? > > I have tried > - enabling/disabling "ACL Plugin" component to chain > - enabling/disabling "password policy" component to chain > - enabling/disabling various LDAP controls to chain > - other attributes (homephone, surname, etc), all of which proxy fine to no > avail. > > > Rich (or anyone else :-), do you have any ideas? This really looks like a bug > to me - I haven't started poking around in the source yet though. > > > -----Original Message----- > From: 389-users-boun...@lists.fedoraproject.org > [mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Jonathan > Boulle > Sent: 29 July 2010 14:54 > To: 'General discussion list for the 389 Directory server project.' > Subject: Re: [389-users] Sanity check for install approach > > On closer examination of the doc, it appears that chaining updates is only > possible when using database links. > However, as I infer, using database links removes the possibility of > replication, because the link would pass any modification back to the remote > database. > Thus, if you had a consumer configured with a database link back to a > supplier, and then set up a replication agreement from the supplier to the > consumer, it would be replicating to its own database! > Am I understanding this correctly? > > Is there a way to achieve our desired scenario: where no clients can directly > access a read-write supplier (i.e. referrals are disabled, because network > access is blocked); but they're still able to change their passwords, because > the read-only consumer chains the update request back to a supplier? > > Cheers > > > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
