[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Replication and acl: moddn operation problem.

To: Nick Milas <nick@eurobjects.com>
Subject: Re: Replication and acl: moddn operation problem.
From: Konstantin Menshikov <kostjnspb@yandex.ru>
Date: Wed, 20 Jun 2012 16:10:21 +0400
Cc: openldap-technical@openldap.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340194222; bh=PZnRM4IGzr0vuLrljnmZCQafs5ibToBYnL1YKvfNuIU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=hbbiCMvOIq6SyE4RrPHuYLkRLJgvdPmCk2YBzWFBw24uK3hRswGCkQ6gAZJn8c5kl Ftsc4xPqEtNxVT2HCkSOT1GXrWU11cRXz9VoyUUSEZnY/KRnvGGS5tNqF1HP+2GhsU tcom25gZmjoxQSqbpQCEUpqEzaHYObR94GWTWIzE=
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340194221; bh=PZnRM4IGzr0vuLrljnmZCQafs5ibToBYnL1YKvfNuIU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type; b=Doz9itDxBOilCyg3XrJIpHPJRaPX/+CBhEbsolPNJ7MODE6NW44j8TFzBp4rBkE9h lA48GaP1brL0c459nJaPFEkh2SwvzGD9I8cHocZJHkQGAjaGzSsEXKGtPKlvVdyUiG tAmL/YyAFVdXwIZ4XdIOJCuk+dPnv2DlDCCYMB+E=
In-reply-to: <4FC4EA58.2040806@eurobjects.com>
References: <862431337954189@web9h.yandex.ru> <4FC4663F.1080008@yandex.ru> <4FC4EA58.2040806@eurobjects.com>
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20

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 notvisible 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 FreeBSD8.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 accessof replication binddn only ou=dev,o=company branch.



Testing plan:

move cn=cacti,ou=groups,ou=corp,o=company tocn=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) showthat syncrepl (refreshAndPersist) works correctly when replicating basedon ACL restrictions. OpenLDAP consumer deletes correctly an entry from abranch when the entry is moved to another, invisible by the consumerbinddn, branch, and it re-creates it correctly when it is moved back toa 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

ee slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/corba.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/dyngroup.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/java.schema
include         /usr/local/etc/openldap/schema/misc.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/openldap.schema
include         /usr/local/etc/openldap/schema/ppolicy.schema
include         /usr/local/etc/openldap/schema/sudo.schema
include         /usr/local/etc/openldap/schema/samba.schema
include         /usr/local/etc/openldap/schema/spamassassin.schema
include         /usr/local/etc/openldap/schema/openssh-lpk.schema
include         /usr/local/etc/openldap/schema/asterisk.schema


# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
loglevel        sync stats

# Load dynamic backend modules:
modulepath      /usr/local/libexec/openldap
moduleload      back_hdb
#moduleload     back_ldap
#moduleload     back_perl

sizelimit 5000

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read


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

#access to dn.subtree="o=company" attrs=entry
#       by dn.exact="uid=replica,ou=users,o=company" read

#access to dn="" by * read
#access to dn="cn=Subschema" by * read 

#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

# Enable TLS
TLSCACertificatePath /etc/ssl/certs
TLSCertificateFile /etc/ssl/certs/ro.devel.ldap.hostcomm.ru.crt
TLSCertificateKeyFile /etc/ssl/private/ro.devel.ldap.hostcomm.ru.key

# Here, ssf=128 tells OpenLDAP to require 128-bit encryption for all connections, both search and update.
security ssf=128
require bind LDAPv3 

#######################################################################
# BDB database definitions
#######################################################################

database        hdb
suffix          "o=company"
rootdn          "cn=ldapadm,o=company"
rootpw          password
directory       /var/db/openldap-data/o=company

overlay syncprov

index mailLocalAddress pres,eq
index mail pres,eq,sub
index objectClass eq
index uid eq,sub
index entryUUID eq
index cn eq

database config                                                                                                         
rootpw PASSW_FOR_CN=CONFIG

# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/corba.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/dyngroup.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/java.schema
include         /usr/local/etc/openldap/schema/misc.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/openldap.schema
include         /usr/local/etc/openldap/schema/ppolicy.schema
include         /usr/local/etc/openldap/schema/sudo.schema
include         /usr/local/etc/openldap/schema/samba.schema
include         /usr/local/etc/openldap/schema/spamassassin.schema
include         /usr/local/etc/openldap/schema/openssh-lpk.schema
include         /usr/local/etc/openldap/schema/asterisk.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
loglevel        sync stats

# Load dynamic backend modules:
modulepath      /usr/local/libexec/openldap
moduleload      back_bdb
moduleload      back_hdb
# moduleload    back_ldap
#moduleload     back_perl

sizelimit 5000

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to dn="" by * read
#access to dn="cn=Subschema" by * read 

#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

# Enable TLS
TLSCACertificatePath /etc/ssl/certs
TLSCertificateFile /etc/ssl/certs/ro.devel.ldap.hostcomm.ru.crt
TLSCertificateKeyFile /etc/ssl/private/ro.devel.ldap.hostcomm.ru.key

# Here, ssf=128 tells OpenLDAP to require 128-bit encryption for all connections, both search and update.
security ssf=128
require bind LDAPv3 

#######################################################################
# BDB database definitions
#######################################################################

database        hdb
suffix          "o=company"
rootdn          "cn=ldapadm,o=company"
rootpw          password
directory       /var/db/openldap-data/o=company

index mailLocalAddress pres,eq
index mail pres,eq,sub
index objectClass eq
index uid eq,sub
index entryUUID eq
index cn eq

syncrepl rid=001
                provider=ldap://ro1.devel.ldap.hostcomm.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"

database config                                                                                                         
rootpw PASSW_FOR_CN=CONFIG

Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 fd=9 ACCEPT from IP=10.14.10.194:58963 (IP=0.0.0.0:389)
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=0 STARTTLS
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=0 RESULT oid= err=0 text=
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 fd=9 TLS established tls_ssf=256 ssf=256
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=1 BIND dn="uid=replica,ou=users,o=company" method=128
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=1 BIND dn="uid=replica,ou=users,o=company" mech=SIMPLE ssf=0
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=1 RESULT tag=97 err=0 text=
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=2 SRCH base="o=company" scope=2 deref=0 filter="(objectClass=*)"
Jun 20 11:29:27 ro1 slapd[12866]: conn=1005 op=2 SRCH attr=* +
Jun 20 11:29:27 ro1 slapd[12866]: syncprov_search_response: cookie=rid=001,csn=20120620112919.905327Z#000000#000#000000
Jun 20 11:29:38 ro1 slapd[12866]: conn=1003 op=28 MODRDN dn="cn=cacti,ou=groups,ou=corp,o=company"
Jun 20 11:29:38 ro1 slapd[12866]: slap_queue_csn: queing 0x7fffff3fd1d0 20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro1 slapd[12866]: conn=1003 op=28 RESULT tag=109 err=0 text=
Jun 20 11:29:38 ro1 slapd[12866]: slap_graduate_commit_csn: removing 0x8019c2190 20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro1 slapd[12866]: syncprov_sendresp: cookie=rid=001,csn=20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro1 slapd[12866]: conn=1003 op=29 SRCH base="cn=cacti,ou=groups,ou=dev,o=company" scope=0 deref=0 filter="(objectClass=*)"
Jun 20 11:29:38 ro1 slapd[12866]: conn=1003 op=29 SRCH attr=hasSubordinates objectClass
Jun 20 11:29:38 ro1 slapd[12866]: conn=1003 op=29 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=30 MODRDN dn="cn=cacti,ou=groups,ou=dev,o=company"
Jun 20 11:29:46 ro1 slapd[12866]: slap_queue_csn: queing 0x7fffff3fd1d0 20120620112946.619489Z#000000#000#000000
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=30 RESULT tag=109 err=0 text=
Jun 20 11:29:46 ro1 slapd[12866]: slap_graduate_commit_csn: removing 0x8019c29d0 20120620112946.619489Z#000000#000#000000
Jun 20 11:29:46 ro1 slapd[12866]: syncprov_sendresp: cookie=rid=001,csn=20120620112946.619489Z#000000#000#000000
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=31 SRCH base="cn=cacti,ou=groups,ou=corp,o=company" scope=0 deref=0 filter="(objectClass=*)"
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=31 SRCH attr=hasSubordinates objectClass
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=31 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=32 SRCH base="ou=groups,ou=dev,o=company" scope=1 deref=3 filter="(objectClass=*)"
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=32 SRCH attr=hasSubordinates objectClass
Jun 20 11:29:46 ro1 slapd[12866]: conn=1003 op=32 SEARCH RESULT tag=101 err=0 nentries=0 text=

Jun 20 11:29:27 ro2 slapd[14237]: @(#) $OpenLDAP: slapd 2.4.31 (May  4 2012 15:09:01) $     root@tinderbox.host:/work/a/ports/net/openldap24-server/work/openldap-2.4.31/servers/slapd
Jun 20 11:29:27 ro2 slapd[14238]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/db/openldap-data/o=company: (2). Expect poor performance for suffix "o=company".
Jun 20 11:29:27 ro2 slapd[14238]: slapd starting
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_message_to_entry: rid=001 DN: o=company, UUID: 41a9da6c-39db-1031-9236-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 inserted UUID 41a9da6c-39db-1031-9236-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_search (32)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 o=company
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_add o=company (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_message_to_entry: rid=001 DN: ou=dev,o=company, UUID: 6318f12e-39db-1031-9237-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 inserted UUID 6318f12e-39db-1031-9237-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_search (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 ou=dev,o=company
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_add ou=dev,o=company (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_message_to_entry: rid=001 DN: ou=groups,ou=dev,o=company, UUID: e29699ec-39db-1031-923a-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 inserted UUID e29699ec-39db-1031-923a-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_search (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 ou=groups,ou=dev,o=company
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_add ou=groups,ou=dev,o=company (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_message_to_entry: rid=001 DN: ou=hosts,ou=dev,o=company, UUID: fcc63502-39db-1031-923b-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 inserted UUID fcc63502-39db-1031-923b-a7f15c1ca735
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_search (0)
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 ou=hosts,ou=dev,o=company
Jun 20 11:29:27 ro2 slapd[14238]: syncrepl_entry: rid=001 be_add ou=hosts,ou=dev,o=company (0)
Jun 20 11:29:27 ro2 slapd[14238]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
Jun 20 11:29:27 ro2 slapd[14238]: do_syncrep2: rid=001 cookie=rid=001,csn=20120620112919.905327Z#000000#000#000000
Jun 20 11:29:27 ro2 slapd[14238]: slap_queue_csn: queing 0x801977640 20120620112919.905327Z#000000#000#000000
Jun 20 11:29:27 ro2 slapd[14238]: slap_graduate_commit_csn: removing 0x801977610 20120620112919.905327Z#000000#000#000000
Jun 20 11:29:38 ro2 slapd[14238]: do_syncrep2: rid=001 cookie=rid=001,csn=20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro2 slapd[14238]: syncrepl_message_to_entry: rid=001 DN: cn=cacti,ou=groups,ou=dev,o=company, UUID: 90e9e450-4e80-1031-9b5d-3137231c3ad3
Jun 20 11:29:38 ro2 slapd[14238]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 20 11:29:38 ro2 slapd[14238]: syncrepl_entry: rid=001 be_search (0)
Jun 20 11:29:38 ro2 slapd[14238]: syncrepl_entry: rid=001 cn=cacti,ou=groups,ou=dev,o=company
Jun 20 11:29:38 ro2 slapd[14238]: slap_queue_csn: queing 0x801977550 20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro2 slapd[14238]: slap_graduate_commit_csn: removing 0x8019eb670 20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro2 slapd[14238]: syncrepl_entry: rid=001 be_add cn=cacti,ou=groups,ou=dev,o=company (0)
Jun 20 11:29:38 ro2 slapd[14238]: slap_queue_csn: queing 0x801977550 20120620112938.558156Z#000000#000#000000
Jun 20 11:29:38 ro2 slapd[14238]: slap_graduate_commit_csn: removing 0x8019eb5e0 20120620112938.558156Z#000000#000#000000
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 fd=16 ACCEPT from IP=10.10.32.66:50899 (IP=0.0.0.0:389)
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=0 STARTTLS
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=0 RESULT oid= err=0 text=
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 fd=16 TLS established tls_ssf=128 ssf=128
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=1 BIND dn="cn=ldapadm,o=company" method=128
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=1 BIND dn="cn=ldapadm,o=company" mech=SIMPLE ssf=0
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=1 RESULT tag=97 err=0 text=
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=2 SRCH base="ou=groups,ou=dev,o=company" scope=0 deref=3 filter="(objectClass=*)"
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=2 SRCH attr=*
Jun 20 11:30:04 ro2 slapd[14238]: conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 20 11:30:05 ro2 slapd[14238]: conn=1000 op=3 SRCH base="ou=groups,ou=dev,o=company" scope=1 deref=3 filter="(objectClass=*)"
Jun 20 11:30:05 ro2 slapd[14238]: conn=1000 op=3 SRCH attr=hasSubordinates objectClass
Jun 20 11:30:05 ro2 slapd[14238]: conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 20 11:30:06 ro2 slapd[14238]: conn=1000 op=4 SRCH base="ou=groups,ou=dev,o=company" scope=0 deref=3 filter="(objectClass=*)"
Jun 20 11:30:06 ro2 slapd[14238]: conn=1000 op=4 SRCH attr=*
Jun 20 11:30:06 ro2 slapd[14238]: conn=1000 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jun 20 11:30:07 ro2 slapd[14238]: conn=1000 op=5 SRCH base="cn=cacti,ou=groups,ou=dev,o=company" scope=0 deref=3 filter="(objectClass=*)"
Jun 20 11:30:07 ro2 slapd[14238]: conn=1000 op=5 SRCH attr=*
Jun 20 11:30:07 ro2 slapd[14238]: conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text=

Follow-Ups:
- Re: Replication and acl: moddn operation problem.
  - From: Nick Milas <nick@eurobjects.com>

Prev by Date: RE: Binding to openldap fails
Next by Date: Re: Binding to openldap fails
Index(es):
- Chronological
- Thread