6:56 a.m.
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
12:53 a.m.
openldap-server-2.4.26 on the provider and on the consumer.
25.05.2012, 19:14, "Nick Milas" <nick(a)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
11:01 p.m.
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?
--
Konstantin Menshikov
8:25 a.m.
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
5:10 a.m.
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?
--
Konstantin Menshikov
2:53 p.m.
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
9:38 a.m.
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
4119
days inactive
4145
days old
openldap-technical@openldap.org
7 comments
2 participants
participants (2)
-
Konstantin Menshikov -
Nick Milas