Hi.
I have replication setup . Full replication of o=company, but user for replication (uid=replica,ou=users,o=company) is limited by ACL.
Master configuration:
access to dn.subtree="ou=users,o=company" attrs=userPassword by anonymous auth
access to dn.base="o=company" by dn.exact="uid=replica,ou=users,o=company" read
access to dn.subtree="ou=dev,o=company" by dn.exact="uid=replica,ou=users,o=company" read
####################################################################### # BDB database definitions #######################################################################
database hdb suffix "o=company" rootdn "cn=ldapadm,o=company" rootpw password directory /var/db/openldap-data/o=company
overlay syncprov
Slave configuration: ####################################################################### # BDB database definitions #######################################################################
database hdb suffix "o=company" rootdn "cn=ldapadm,o=company" rootpw password directory /var/db/openldap-data/o=company
syncrepl rid=001 provider=ldap://ro1.devel.ldap.company.ru:389 type=refreshAndPersist retry="5 10 300 +" searchbase="o=company" scope=sub schemachecking=off starttls=critical bindmethod=simple tls_reqcert=never binddn="uid=replica,ou=users,o=company" credentials="password"
Replication works.
When i move object in forbidden by ACL subtree, then no information about this modification goes to the replica server e.g. operation on master server:
dn: ou=groups2,ou=dev,o=company changetype: moddn newrdn: ou=groups2 deleteoldrdn: 1 newsuperior: ou=corp,o=company
This object is not deleted and contextCSN is not updated on the replica.
Is it expected behavior or not?
-- Konstantin Menshikov
openldap-server-2.4.26 on the provider and on the consumer.
25.05.2012, 19:14, "Nick Milas" nick@eurobjects.com:
On 25/5/2012 4:56 μμ, Konstantin Menshikov wrote:
I have replication setup .
What version of OpenLDAP are you running on the provider and on the consumer?
Nick
-- Konstantin Menshikov
On 25.05.2012 17:56, Konstantin Menshikov wrote:
Hi.
I have replication setup . Full replication of o=company, but user for replication (uid=replica,ou=users,o=company) is limited by ACL.
Master configuration:
access to dn.subtree="ou=users,o=company" attrs=userPassword by anonymous auth
access to dn.base="o=company" by dn.exact="uid=replica,ou=users,o=company" read
access to dn.subtree="ou=dev,o=company" by dn.exact="uid=replica,ou=users,o=company" read
####################################################################### # BDB database definitions #######################################################################
database hdb suffix "o=company" rootdn "cn=ldapadm,o=company" rootpw password directory /var/db/openldap-data/o=company
overlay syncprov
Slave configuration: ####################################################################### # BDB database definitions #######################################################################
database hdb suffix "o=company" rootdn "cn=ldapadm,o=company" rootpw password directory /var/db/openldap-data/o=company
syncrepl rid=001 provider=ldap://ro1.devel.ldap.company.ru:389 type=refreshAndPersist retry="5 10 300 +" searchbase="o=company" scope=sub schemachecking=off starttls=critical bindmethod=simple tls_reqcert=never binddn="uid=replica,ou=users,o=company" credentials="password"
Replication works.
When i move object in forbidden by ACL subtree, then no information about this modification goes to the replica server e.g. operation on master server:
dn: ou=groups2,ou=dev,o=company changetype: moddn newrdn: ou=groups2 deleteoldrdn: 1 newsuperior: ou=corp,o=company
This object is not deleted and contextCSN is not updated on the replica.
Is it expected behavior or not?
-- Konstantin Menshikov
somebody? anybody?
On 29/5/2012 9:01 πμ, Konstantin Menshikov wrote:
somebody? anybody?
I would say: if you can use test servers with 2.4.31 and BDB >= 4.6.21, then you could try to reproduce by doing some experiments (moving to branch visible by consumer binddn, moving to branch not visible by consumer) and report results with excerpts from the logs.
Nick
On 05/29/2012 07:25 PM, Nick Milas wrote:
On 29/5/2012 9:01 Ïμ, Konstantin Menshikov wrote:
somebody? anybody?
I would say: if you can use test servers with 2.4.31 and BDB >= 4.6.21, then you could try to reproduce by doing some experiments (moving to branch visible by consumer binddn, moving to branch not visible by consumer) and report results with excerpts from the logs.
Nick
Hi. I try use openldap-server-2.4.31 and db47-4.7.25.4 on FreeBSD 8.2-RELEASE-p4. Configufation master and slave attached. Log fragments also attached.
I try full replication of o=company, but with the help ACL limit access of replication binddn only ou=dev,o=company branch.
Testing plan: move cn=cacti,ou=groups,ou=corp,o=company to cn=cacti,ou=groups,ou=dev,o=company. move group back from dev to corp.
Result: moving to visible branch (dev): ok. moving from visible branch to unvisible: error, cn=cacti,ou=groups,ou=dev,o=company still exist on slave!
You wrote: "My tests (with v2.4.31 on both provider and consumer) show that syncrepl (refreshAndPersist) works correctly when replicating based on ACL restrictions. OpenLDAP consumer deletes correctly an entry from a branch when the entry is moved to another, invisible by the consumer binddn, branch, and it re-creates it correctly when it is moved back to a visible (based on ACL) branch."
Please, show your replication setup at which it works correctly.
I fount, that if to add ACL #access to dn.subtree="o=company" attrs=entry # by dn.exact="uid=replica,ou=users,o=company" read
moving to unvisible branch working correctly! That side effect can be? What level of access allows this ACL?
On 20/6/2012 3:10 μμ, Konstantin Menshikov wrote:
Please, show your replication setup at which it works correctly.
OK, here is an example test setup:
DN: ou=TestBranch1,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: TestBranch1
DN: dc=hostx,ou=TestBranch1,dc=example,dc=com objectClass: dNSDomain2 objectClass: domainRelatedObject associatedDomain: hostx.example.com cNAMERecord: www.example.com dc: hostx
DN: ou=TestBranch2,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: TestBranch2
ACLs (over-simplistic, devised to illustrate the case): {0}to dn.sub="ou=TestBranch1,dc=example,dc=com" by dn.exact="uid=dnsauth,ou=system,dc=example,dc=com" write by * none {1}to dn.sub="ou=TestBranch2,dc=example,dc=com" by * none
Consumer setup:
syncrepl rid=444 provider=ldaps://vdev.example.com type=refreshAndPersist tls_reqcert=never retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="uid=dnsauth,ou=System,dc=example,dc=com" credentials="secret"
Initial State: dc=hostx,ou=TestBranch1,dc=example,dc=com exists on both provider and consumer.
Action1: Manager moves (on the provider) dc=hostx from ou=TestBranch1,dc=example,dc=com to dc=hostx,ou=TestBranch2,dc=example,dc=com where consumer has no visibility. Result: Entry is removed from the consumer
Action2: Manager moves back dc=hostx from ou=TestBranch2,dc=example,dc=com to dc=hostx,ou=TestBranch1,dc=example,dc=com where consumer has visibility. Result: Entry is added back to the consumer
On the provider:
Jun 21 00:24:59 vdev slapd[2212]: slap_queue_csn: queing 0x41046300 20120620212459.398242Z#000000#000#000000 Jun 21 00:24:59 vdev slapd[2212]: slap_graduate_commit_csn: removing 0x1e4b94b0 20120620212459.398242Z#000000#000#000000 Jun 21 00:24:59 vdev slapd[2212]: slap_queue_csn: queing 0x4351e750 20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 vdev slapd[2212]: syncprov_sendresp: cookie=rid=444,csn=20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 vdev slapd[2212]: slap_graduate_commit_csn: removing 0x1e003b10 20120620212459.506829Z#000000#000#000000 Jun 21 00:25:27 vdev slapd[2212]: slap_queue_csn: queing 0x4251c300 20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 vdev slapd[2212]: syncprov_sendresp: cookie=rid=444,csn=20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 vdev slapd[2212]: slap_graduate_commit_csn: removing 0x1e46d620 20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 vdev slapd[2212]: slap_queue_csn: queing 0x41046750 20120620212527.515237Z#000000#000#000000 Jun 21 00:25:27 vdev slapd[2212]: slap_graduate_commit_csn: removing 0x1e46d5c0 20120620212527.515237Z#000000#000#000000
On the consumer:
Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444 LDAP_RES_INTERMEDIATE - NEW_COOKIE Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444 NEW_COOKIE: rid=444,csn=20120620212459.398242Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc2746a0 20120620212459.398242Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing 0xc28ba90 20120620212459.398242Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: do_syncrep2: rid=444 cookie=rid=444,csn=20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_message_to_entry: rid=444 DN: dc=hostx,ou=TestBranch1,dc=example,dc=com, UUID: 6bd53150-9abf-4c83-9d23-9a706b042e07 Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_DELETE) Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 be_search (0) Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 dc=hostx,ou=TestBranch1,dc=example,dc=com Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc47e150 20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing 0xc28ba90 20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: syncrepl_entry: rid=444 be_delete dc=hostx,ou=TestBranch1,dc=example,dc=com (0) Jun 21 00:24:59 dnslab slapd[20628]: slap_queue_csn: queing 0xc47e150 20120620212459.506829Z#000000#000#000000 Jun 21 00:24:59 dnslab slapd[20628]: slap_graduate_commit_csn: removing 0xc46f320 20120620212459.506829Z#000000#000#000000 Jun 21 00:25:27 dnslab slapd[20628]: do_syncrep2: rid=444 cookie=rid=444,csn=20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_message_to_entry: rid=444 DN: dc=hostx,ou=TestBranch1,dc=example,dc=com, UUID: bfd9ef4e-e299-445b-b0db-ffafbd8f3804 Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444 be_search (0) Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444 dc=hostx,ou=TestBranch1,dc=example,dc=com Jun 21 00:25:27 dnslab slapd[20628]: slap_queue_csn: queing 0xc46f7e0 20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 dnslab slapd[20628]: slap_graduate_commit_csn: removing 0xc46ea50 20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 dnslab slapd[20628]: syncrepl_entry: rid=444 be_add dc=hostx,ou=TestBranch1,dc=example,dc=com (0) Jun 21 00:25:27 dnslab slapd[20628]: slap_queue_csn: queing 0xc46f7e0 20120620212527.418467Z#000000#000#000000 Jun 21 00:25:27 dnslab slapd[20628]: slap_graduate_commit_csn: removing 0xc46ea50 20120620212527.418467Z#000000#000#000000
As I have noted in another message, I found it is important that the syncrepl user have NO access at all to the branch where we want no visibility, otherwise, there might be syncrepl tricky behavior.
Nick
On 25/5/2012 4:56 μμ, Konstantin Menshikov wrote:
When i move object in forbidden by ACL subtree, then no information about this modification goes to the replica server
I don't know if you have followed a recent thread, but according to Howard Chu:
(quote) "Visibility changes due to ACL rules are not detected. syncprov only checks an entry against the search parameters of the original sync search operation, i.e., the base, scope, and filter. If an entry matches these params before the modification, and no longer matches after the operation, syncprov will send a delete message for that entry. (Likewise if an entry doesn't match before, but matches after, syncprov will send an Add for the entry.)"
So, based on this, the behavior you see is expected.
And another quote (by me):
"So in essence Howard says that ACL-based filtering in replication does not result in proper results to consumers.
This is tricky! (I didn't know either.) It means that we should *not* design our replication based on ACL-filtering (which, unfortunately, we have done too), but, on the contrary, that we should design our DIT so that it can cover our replication needs based on consumer base/scope/filter configuration, and we should design/adapt our ACLs with the above rule in mind. "
I thought of your case when I followed this thread, and I thought I should send you a notice.
Regards, Nick
openldap-technical@openldap.org
-
Konstantin Menshikov -
Nick Milas