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:
[bloggsj@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:
[bloggsj@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: abc123!@#
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-bounces@lists.fedoraproject.org [mailto:389-users-bounces@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.
________________________________________________________________________
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-users@redhat.com/msg09880.html
-----Original Message----- From: 389-users-bounces@lists.fedoraproject.org [mailto:389-users-bounces@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:
[bloggsj@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:
[bloggsj@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: abc123!@#
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-bounces@lists.fedoraproject.org [mailto:389-users-bounces@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-users@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.
________________________________________________________________________
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-users@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-bounces@lists.fedoraproject.org [mailto:389-users-bounces@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:
[bloggsj@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:
[bloggsj@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: abc123!@#
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-bounces@lists.fedoraproject.org [mailto:389-users-bounces@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-users@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-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
From: 389-users-bounces@lists.fedoraproject.org [389-users-bounces@lists.fedoraproject.org] on behalf of Rich Megginson [rmeggins@redhat.com] Sent: 02 August 2010 16:33 To: General discussion list for the 389 Directory server project. Subject: Re: [389-users] Problems with chaining (was: RE: Sanity check for install approach)
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-users@redhat.com/msg09880.html
It's a bug - can't remember the bug number - you might check the 389 bugs to find this one
For the sake of future googlers. The bug is https://bugzilla.redhat.com/show_bug.cgi?id=520151 and is fixed in the RC3 release. We have not yet tested it but according to the release notes anyway.
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
389-users@lists.fedoraproject.org
-
Gerrard Geldenhuis -
Jonathan Boulle -
Rich Megginson