7:16 a.m.
Hi all,
I'm testing multi-master replication between (at least 2) openldap nodes
(2.4.45, on Ubuntu 18.04) and facing a problem with replication account.
I set up configuration for node1 and node2 (see configuration below),
and rpuser account for replication (with same hashed password on both
nodes).
I can connect to node1 and node2 with rpuser account : ldapsearch -H
ldap://node1-vpn -W -D "uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar"
Then I add a group or a user to a node to test replication with
ldapadd -H ldap://node1-vpn -W -D "cn=admin,dc=foo,dc=bar" -f
/tmp/openldap/rep_test_groupadd.ldif
and rep_test_groupadd.ldif:
dn: cn=testgroup,dc=foo,dc=bar
objectClass: top
objectClass: posixGroup
gidNumber: 456
The new group or user is replicated on the other node, but then the
rpuser's password doesn't work anymore on the other node.
I can't connect anymore with ldapsearch -H ldap://node2-vpn -W -D
"uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar"
and I got errors messages for replication in /var/log/syslog
slap_client_connect: URI=ldap://node2-vpn DN="uid=rpuser,dc=foo,dc=bar"
ldap_sasl_bind_s failed (49)
rpuser's password is still valid on node1
Any idea of what could cause this problem ?
Thanks
Vincent
# config
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcDisallows: bind_anon
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcRequires: authc
olcToolThreads: 1
olcServerID: 0 ldap:///
olcServerID: 1 ldap://node1-vpn
olcServerID: 2 ldap://node2-vpn
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
# module{1}, config
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModuleLoad: {0}syncprov.la
# {0}mdb, config
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRequires: authc
olcRootDN: cn=admin,dc=nodomain
olcRootPW: {SSHA}HdZbPd66TxCjeYEIAASbAQTnvFh3GOTw
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
# {2}mdb, config
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lab/ldap
olcSuffix: dc=foo,dc=bar
olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by * none
olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
user
s read by * none
olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read
olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=rpuser,dc=foo,dc=bar" time.soft=unlimited
time.h
ard=unlimited size.soft=unlimited size.hard=unlimited
olcRequires: authc
olcRootDN: cn=admin,dc=foo,dc=bar
olcRootPW: {SSHA}zL8CSrnkBacsebLUsJ+dzva6eQ7xcyZJ
olcSyncrepl: {0}rid=101 provider=ldap://node1-vpn binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcSyncrepl: {1}rid=102 provider=ldap://node2-vpn binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcMirrorMode: TRUE
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbMaxSize: 1073741824
# {0}syncprov, {2}mdb, config
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
8:28 a.m.
Am 08.01.20 um 16:16 schrieb Vincent Ducot:
Hi all,
I'm testing multi-master replication between (at least 2) openldap nodes (2.4.45, on
Ubuntu 18.04) and facing a problem with replication account.
At some point in time I decided to create a separate database as replication-account
slapd.conf:
database ldif
directory /empty
suffix "dc=syncrepl"
access to dn.base="dc=syncrepl" by * auth
rootdn "dc=syncrepl"
rootpw "{PLAIN}secret"
This account exist per configuration even on an "empty" syncrepl consumer and is
allowed to read/write the database to be replicated.
It will not be replicated itself an avoid the issue you describe. N-way replication can
start from zero.
If this should be insecure, I hope, somebody will correct me (and the archive), please.
Andreas
10:13 a.m.
--On Wednesday, January 8, 2020 4:16 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
Hi all,
I'm testing multi-master replication between (at least 2) openldap nodes
(2.4.45, on Ubuntu 18.04) and facing a problem with replication account.
Any idea of what could cause this problem ?
# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
# {2}mdb, config
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lab/ldap
olcSuffix: dc=foo,dc=bar
olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by *
none
olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
user
s read by * none
olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read
olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write
I see multiple problems with your configuration.
a) You have two different databases storing their DBs in the same location
(/var/lib/ldap). I can't even imagine the havoc and destruction that would
cause.
b) Your ACLs are broken. The "rpuser" account has no ability to replicate
userPassword, since it can't read it. Also, ACLs #2 and #3 here will never
be evaluated, since it's already covered in ACL#1 (by users read). Since
it can't replicate userPassword, that value is getting lost from server#2,
explaining why you can't bind to it after replication starts.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:48 a.m.
Hi,
thanks for your answer.
a) It's not the same location, it's /var/lib and /var/lab (yeah, tricky)
b) I tested several possibilities but I didn't manage to make it work.
Either the problem stayed the same, either the replication didn't work
anymore, either I couldn't access to rpuser.
I understand that :
- rpuser should have read/write access to its password (to
attrs=userPassword by dn="uid=rpuser,dc=foo,dc=bar" write)
- rpuser should have read/write access to all data (to * by
dn="uid=rpuser,dc=foo,dc=bar" write)
- other users should have read access to their password (I don't want
they could change it by themselves) and anonymous should authenticate
(to attrs=userPassword by self read by anonymous auth by * none)
Am I right ?
Regards,
Vincent
Le 08/01/2020 à 19:13, Quanah Gibson-Mount a écrit :
--On Wednesday, January 8, 2020 4:16 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
>
> Hi all,
> I'm testing multi-master replication between (at least 2) openldap
> nodes
> (2.4.45, on Ubuntu 18.04) and facing a problem with replication account.
> Any idea of what could cause this problem ?
> # {1}mdb, config
> dn: olcDatabase={1}mdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcMdbConfig
> olcDatabase: {1}mdb
> olcDbDirectory: /var/lib/ldap
> olcSuffix: dc=nodomain
> olcAccess: {0}to attrs=userPassword by self write by anonymous auth
> by *
> none
> olcAccess: {1}to attrs=shadowLastChange by self write by * read
> olcAccess: {2}to * by * read
> # {2}mdb, config
> dn: olcDatabase={2}mdb,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcMdbConfig
> olcDatabase: {2}mdb
> olcDbDirectory: /var/lab/ldap
> olcSuffix: dc=foo,dc=bar
> olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by *
> none
> olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self
> write by
> user
> s read by * none
> olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read
> olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write
I see multiple problems with your configuration.
a) You have two different databases storing their DBs in the same
location (/var/lib/ldap). I can't even imagine the havoc and
destruction that would cause.
b) Your ACLs are broken. The "rpuser" account has no ability to
replicate userPassword, since it can't read it. Also, ACLs #2 and #3
here will never be evaluated, since it's already covered in ACL#1 (by
users read). Since it can't replicate userPassword, that value is
getting lost from server#2, explaining why you can't bind to it after
replication starts.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2:27 p.m.
--On Friday, January 10, 2020 5:48 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
a) It's not the same location, it's /var/lib and /var/lab
(yeah, tricky)
Ah, missed that.
b) I tested several possibilities but I didn't manage to make it
work.
Either the problem stayed the same, either the replication didn't work
anymore, either I couldn't access to rpuser.
I understand that :
- rpuser should have read/write access to its password (to
attrs=userPassword by dn="uid=rpuser,dc=foo,dc=bar" write)
- rpuser should have read/write access to all data (to * by
dn="uid=rpuser,dc=foo,dc=bar" write)
Sure, but ACLs stop processing on the first matching rule. Please review
the slapd.access(5) man page. Your ACLsforthe rpuser are never evaluated
since prior rules prevent them being reached.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7:53 a.m.
Hi,
yes, I understand the processing order. So something like this should
work, right ?
olcAccess: to attrs=userPassword by anonymous auth
olcAccess: to * by dn="uid=rpuser,dc=foo,dc=bar" write
olcAccess: to attrs=userPassword by self write by * none
olcAccess: to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
users read by * none
Actually, after an object is replicated, rpuser is deleted (and also
other objects of the same tree). Any idea why ?
In the log I get :
Jan 13 16:26:33 node5 slapd[9976]: => access_allowed: delete access to
"dc=foo,dc=bar" "children" requested
Jan 13 16:26:33 node5 slapd[9976]: <= root access granted
Jan 13 16:26:33 node5 slapd[9976]: => access_allowed: delete access
granted by manage(=mwrscxd)
Jan 13 16:26:33 node5 slapd[9976]: => access_allowed: delete access to
"uid=rpuser,dc=foo,dc=bar" "entry" requested
Jan 13 16:26:33 node5 slapd[9976]: <= root access granted
Jan 13 16:26:33 node5 slapd[9976]: => access_allowed: delete access
granted by manage(=mwrscxd)
Jan 13 16:26:33 node5 slapd[9976]: => index_entry_del( 7,
"uid=rpuser,dc=foo,dc=bar" )
Jan 13 16:26:33 node5 slapd[9976]: <= index_entry_del( 7,
"uid=rpuser,dc=foo,dc=bar" ) success
Jan 13 16:26:33 node5 slapd[9976]: mdb_delete: deleted id=00000007
dn="uid=rpuser,dc=foo,dc=bar"
Thanks
Le 10/01/2020 à 23:27, Quanah Gibson-Mount a écrit :
--On Friday, January 10, 2020 5:48 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
> a) It's not the same location, it's /var/lib and /var/lab (yeah, tricky)
Ah, missed that.
> b) I tested several possibilities but I didn't manage to make it work.
> Either the problem stayed the same, either the replication didn't work
> anymore, either I couldn't access to rpuser.
>
> I understand that :
>
>
> - rpuser should have read/write access to its password (to
> attrs=userPassword by dn="uid=rpuser,dc=foo,dc=bar" write)
>
> - rpuser should have read/write access to all data (to * by
> dn="uid=rpuser,dc=foo,dc=bar" write)
Sure, but ACLs stop processing on the first matching rule. Please
review the slapd.access(5) man page. Your ACLsforthe rpuser are never
evaluated since prior rules prevent them being reached.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:24 a.m.
--On Monday, January 13, 2020 4:53 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
Hi,
yes, I understand the processing order. So something like this should
work, right ?
No. All access to userPassword is stopped by your very first ACL, no
further ACLs for it will apply, as I already stated. Again, ACL processing
STOPs at the FIRST matching rule. Additionally, a replication user only
needs read access to read data off the master. It does not need explicit
write access to its local db.
olcAccess: to attrs=userPassword by anonymous auth
olcAccess: to * by dn="uid=rpuser,dc=foo,dc=bar" write
olcAccess: to attrs=userPassword by self write by * none
olcAccess: to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
users read by * none
So in the above, any and all access to userPassword STOPs at the "by
anonymous auth access". Any other type of request for access to
userPassword will be denied.
You most likely want something more like:
olcAccess: to attrs=userPassword by anonymous auth by self write by
dn.exact="uid=rpuser,dc=foo,dc=bar" read
olcAccess: to * by dn="cn=admin,dc=foo,dc=bar" write by self write by users
read by * none
This appears to encapsulate the permissions you're trying to set up in the
above.
Note that a "user" is *any* identity that succesfully authenticated to the
LDAP server, so the "rpuser" is already covered in the "to *" access
line
by the rule "by users read".
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
9:32 a.m.
Ok, I thought the rule matched if "by" also matched. Thanks to light it.
I apply the olcAccess you proposed.
I still have the problem of deletion of "dc=foo,dc=bar" tree on node2,
for example when I add a user on node1. Any idea why ?
Thanks,
Regards,
Vincent
Le 13/01/2020 à 17:24, Quanah Gibson-Mount a écrit :
--On Monday, January 13, 2020 4:53 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
>
> Hi,
>
> yes, I understand the processing order. So something like this should
> work, right ?
No. All access to userPassword is stopped by your very first ACL, no
further ACLs for it will apply, as I already stated. Again, ACL
processing STOPs at the FIRST matching rule. Additionally, a
replication user only needs read access to read data off the master.
It does not need explicit write access to its local db.
> olcAccess: to attrs=userPassword by anonymous auth
> olcAccess: to * by dn="uid=rpuser,dc=foo,dc=bar" write
> olcAccess: to attrs=userPassword by self write by * none
> olcAccess: to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
> users read by * none
So in the above, any and all access to userPassword STOPs at the "by
anonymous auth access". Any other type of request for access to
userPassword will be denied.
You most likely want something more like:
olcAccess: to attrs=userPassword by anonymous auth by self write by
dn.exact="uid=rpuser,dc=foo,dc=bar" read
olcAccess: to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
users read by * none
This appears to encapsulate the permissions you're trying to set up in
the above.
Note that a "user" is *any* identity that succesfully authenticated to
the LDAP server, so the "rpuser" is already covered in the "to *"
access line by the rule "by users read".
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:31 a.m.
--On Monday, January 13, 2020 6:32 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
Ok, I thought the rule matched if "by" also matched. Thanks to light it.
I apply the olcAccess you proposed.
I still have the problem of deletion of "dc=foo,dc=bar" tree on node2,
for example when I add a user on node1. Any idea why ?
Not off the top of my head. Without full configs for both servers or an
understanding of the state of the replicated databases on each server, it
would all be random speculation.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:26 a.m.
New subject: Antw: Re: Replication account problem
>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am
13.01.2020 um 20:31 in
Nachricht <1FB1DDD3A574DC1DA2F2F517(a)[192.168.1.144]>:
‑‑On Monday, January 13, 2020 6:32 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
>
> Ok, I thought the rule matched if "by" also matched. Thanks to light it.
>
> I apply the olcAccess you proposed.
>
> I still have the problem of deletion of "dc=foo,dc=bar" tree on node2,
> for example when I add a user on node1. Any idea why ?
Not off the top of my head. Without full configs for both servers or an
understanding of the state of the replicated databases on each server, it
would all be random speculation.
I'd recommend "sync" logging to see what's really going on.
‑‑Quanah
‑‑
Quanah Gibson‑Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:27 a.m.
Hi,
You can find below my full config.
To be more precise, my problem is :
- I add a user on node1, it's replicated on node2
- I add a second user (or group) on node2, it's not replicated on node2.
In the logs, I get
Jan 15 16:11:21 node2 slapd[2465]: do_syncrep2: rid=102
LDAP_RES_SEARCH_RESULT
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
LDAP_RES_SEARCH_RESULT
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
cookie=rid=101,csn=20200115102817.516155Z#000000#000#000000
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 90915624-c578-1039-97ac-bb4be13c2c82, dn dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 90952132-c578-1039-8aef-6f411f63000a, dn cn=admin,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 909a0760-c578-1039-8af0-6f411f63000a, dn ou=people,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 909b4666-c578-1039-8af1-6f411f63000a, dn ou=groups,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 9a1f5e84-c578-1039-918d-7129ec86f31a, dn
uid=appadmin,ou=people,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 9a48db24-c578-1039-918e-7129ec86f31a, dn
cn=admins-for-app,ou=groups,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101 present
UUID 3032f6b0-cbcd-1039-952e-fb0cd8c5af02, dn uid=testuser,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: slap_queue_csn: queueing
0x7f4628103420 20200115102817.516155Z#000000#000#000000
Jan 15 16:11:22 node2 slapd[2465]: slap_graduate_commit_csn: removing
0x7f4628103420 20200115102817.516155Z#000000#000#000000
What means "nonpresent_callback" ?
I also tested with replication user in a different database, as
suggested in this mailing list, but the result is the same.
Regards,
Vincent
# config
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcDisallows: bind_anon
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcRequires: authc
olcToolThreads: 1
olcServerID: 0 ldap:///
olcServerID: 1 ldap://node1-vpn
olcServerID: 2 ldap://node2-vpn
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
# module{1}, config
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModuleLoad: {0}syncprov.la
# {0}mdb, config
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRequires: authc
olcRootDN: cn=admin,dc=nodomain
olcRootPW: {SSHA}HdZbPd66TxCjeYEIAASbAQTnvFh3GOTw
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
# {2}mdb, config
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/foobar/ldap
olcSuffix: dc=foo,dc=bar
olcAccess: {0}to attrs=userPassword by anonymous auth by self write by
dn.exact="cn=rpuser,dc=foo,dc=bar" read
olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
users read by * none
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=rpuser,dc=foo,dc=bar" time.soft=unlimited
time.h
ard=unlimited size.soft=unlimited size.hard=unlimited
olcRequires: authc
olcRootDN: cn=admin,dc=foo,dc=bar
olcRootPW: {SSHA}zL8CSrnkBacsebLUsJ+dzva6eQ7xcyZJ
olcSyncrepl: {0}rid=101 provider=ldap://node1-vpn binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcSyncrepl: {1}rid=102 provider=ldap://node2-vpn binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcMirrorMode: TRUE
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbMaxSize: 1073741824
# {0}syncprov, {2}mdb, config
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
Le 13/01/2020 à 20:31, Quanah Gibson-Mount a écrit :
--On Monday, January 13, 2020 6:32 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
>
> Ok, I thought the rule matched if "by" also matched. Thanks to light it.
>
> I apply the olcAccess you proposed.
>
> I still have the problem of deletion of "dc=foo,dc=bar" tree on node2,
> for example when I add a user on node1. Any idea why ?
Not off the top of my head. Without full configs for both servers or
an understanding of the state of the replicated databases on each
server, it would all be random speculation.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6:51 a.m.
Okay, I changed olcSyncrepl type to refreshAndPersist, and remove
interval settings.
It seems to work now, although I don't really understand why.
Thanks for your help on ACLs
Regards,
Vincent
Le 15/01/2020 à 17:27, Vincent Ducot a écrit :
Hi,
You can find below my full config.
To be more precise, my problem is :
- I add a user on node1, it's replicated on node2
- I add a second user (or group) on node2, it's not replicated on node2.
In the logs, I get
Jan 15 16:11:21 node2 slapd[2465]: do_syncrep2: rid=102
LDAP_RES_SEARCH_RESULT
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
LDAP_RES_SEARCH_RESULT
Jan 15 16:11:22 node2 slapd[2465]: do_syncrep2: rid=101
cookie=rid=101,csn=20200115102817.516155Z#000000#000#000000
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 90915624-c578-1039-97ac-bb4be13c2c82, dn dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 90952132-c578-1039-8aef-6f411f63000a, dn
cn=admin,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 909a0760-c578-1039-8af0-6f411f63000a, dn
ou=people,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 909b4666-c578-1039-8af1-6f411f63000a, dn
ou=groups,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 9a1f5e84-c578-1039-918d-7129ec86f31a, dn
uid=appadmin,ou=people,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 9a48db24-c578-1039-918e-7129ec86f31a, dn
cn=admins-for-app,ou=groups,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: nonpresent_callback: rid=101
present UUID 3032f6b0-cbcd-1039-952e-fb0cd8c5af02, dn
uid=testuser,dc=foo,dc=bar
Jan 15 16:11:22 node2 slapd[2465]: slap_queue_csn: queueing
0x7f4628103420 20200115102817.516155Z#000000#000#000000
Jan 15 16:11:22 node2 slapd[2465]: slap_graduate_commit_csn: removing
0x7f4628103420 20200115102817.516155Z#000000#000#000000
What means "nonpresent_callback" ?
I also tested with replication user in a different database, as
suggested in this mailing list, but the result is the same.
Regards,
Vincent
# config
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcDisallows: bind_anon
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcRequires: authc
olcToolThreads: 1
olcServerID: 0 ldap:///
olcServerID: 1 ldap://node1-vpn
olcServerID: 2 ldap://node2-vpn
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
# module{1}, config
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModuleLoad: {0}syncprov.la
# {0}mdb, config
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb
# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth manage by * break
# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by
* none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRequires: authc
olcRootDN: cn=admin,dc=nodomain
olcRootPW: {SSHA}HdZbPd66TxCjeYEIAASbAQTnvFh3GOTw
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
# {2}mdb, config
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/foobar/ldap
olcSuffix: dc=foo,dc=bar
olcAccess: {0}to attrs=userPassword by anonymous auth by self write
by dn.exact="cn=rpuser,dc=foo,dc=bar" read
olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write
by users read by * none
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=rpuser,dc=foo,dc=bar" time.soft=unlimited
time.h
ard=unlimited size.soft=unlimited size.hard=unlimited
olcRequires: authc
olcRootDN: cn=admin,dc=foo,dc=bar
olcRootPW: {SSHA}zL8CSrnkBacsebLUsJ+dzva6eQ7xcyZJ
olcSyncrepl: {0}rid=101 provider=ldap://node1-vpn
binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd
searchbase="dc=foo,dc=bar" type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcSyncrepl: {1}rid=102 provider=ldap://node2-vpn
binddn="uid=rpuser,dc=foo,
dc=bar" bindmethod=simple credentials=rppwd
searchbase="dc=foo,dc=bar" type=r
efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcMirrorMode: TRUE
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbMaxSize: 1073741824
# {0}syncprov, {2}mdb, config
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
Le 13/01/2020 à 20:31, Quanah Gibson-Mount a écrit :
>
>
> --On Monday, January 13, 2020 6:32 PM +0100 Vincent Ducot
> <vincent.ducot(a)rubycat.eu> wrote:
>
>>
>> Ok, I thought the rule matched if "by" also matched. Thanks to light
>> it.
>>
>> I apply the olcAccess you proposed.
>>
>> I still have the problem of deletion of "dc=foo,dc=bar" tree on node2,
>> for example when I add a user on node1. Any idea why ?
>
> Not off the top of my head. Without full configs for both servers or
> an understanding of the state of the replicated databases on each
> server, it would all be random speculation.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
2:01 p.m.
--On Thursday, January 16, 2020 3:51 PM +0100 Vincent Ducot
<vincent.ducot(a)rubycat.eu> wrote:
Okay, I changed olcSyncrepl type to refreshAndPersist, and remove
interval settings.
Hi Vincent,
I would additionally strongly advise you update your configuration to use
delta-syncrepl rather than standard syncrepl. I've never had any luck with
refreshOnly, although theoretically it's supposed to work.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
1417
days inactive
1425
days old
openldap-technical@openldap.org
13 comments
5 participants
participants (5)
-
A. Schulze -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl -
Vincent Ducot