openldap-technical January 2020

openldap-technical@openldap.org

35 participants
45 discussions

RE24 testing call #2 (2.4.49) LMDB RE0.9 testing call (0.9.25)
by Quanah Gibson-Mount 30 Jan '20

30 Jan '20

This is the second testing call for OpenLDAP 2.4.49. Depending on the results, this may be the only testing call. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.49 Engineering Added slapd-monitor database entry count for slapd-mdb (ITS#9154) Fixed client tools to not add controls on cancel/abandon (ITS#9145) Fixed client tools SyncInfo message to be LDIF compliant (ITS#8116) Fixed libldap to correctly free sb (ITS#9081, ITS#8755) Fixed libldap descriptor leak if ldaps fails (ITS#9147) Fixed libldap remove unnecessary global mutex for GnuTLS (ITS#9069) Fixed slapd syntax evaluation of preferredDeliveryMethod (ITS#9067) Fixed slapd to relax domainScope control check (ITS#9100) Fixed slapd to have cleaner error handling during connection setup (ITS#9112) Fixed slapd data check when processing cancel exop (ITS#9124) Fixed slapd attribute description processing (ITS#9128) Fixed slapd-ldap to set oldctrls correctly (ITS#9076) Fixed slapd-mdb to honor unchecked limit with alias deref (ITS#7657) Fixed slapd-mdb missing final commit with slapindex (ITS#9095) Fixed slapd-mdb drop attr mappings added in an aborted txn (ITS#9091) Fixed slapd-mdb nosync FLAG configuration handling (ITS#9150) Fixed slapd-monitor global operation counter reporting (ITS#9119) Fixed slapo-ppolicy when used with slapauth (ITS#8629) Fixed slapo-ppolicy to add a missed normalised copy of pwdChangedTime (ITS#9126) Fixed slapo-syncprov fix sessionlog init (ITS#9146) Fixed slapo-unique loop termination (ITS#9077) Build Environment Fix mkdep to honor TMPDIR if set (ITS#9062) Remove ICU library detection (ITS#9144) Update config.guess and config.sub to support newer architectures (ITS#7855) Documentation admin24 - Fix inconsistent whitespace in replication section (ITS#9153) slapd-config(5)/slapd.conf(5) - Fix missing bold tag for keyword (ITS#9063) slapd-ldap(5) - Document "tls none" option (ITS#9071) slapo-ppolicy(5) - Correctly document pwdGraceAuthnLimit (ITS#9065) LMDB 0.9.25 Engineering ITS#9068 fix mdb_dump/load backslashes in printable content ITS#9118 add MAP_NOSYNC for FreeBSD ITS#9155 free mt_spill_pgs in non-nested txn on end Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 4

CentOS drops OpenLDAP servers package starting with 8.1
by Quanah Gibson-Mount 30 Jan '20

30 Jan '20

The CentOS project has now also elected to drop support for the OpenLDAP server package starting with 8.1: <https://bugs.centos.org/view.php?id=16959> I will note that Symas continues to offer free packages for Centos8/RHEL8 users based off of the Centos8.0 package. We will likely move this to mirror the Fedora package (which is what the CentOS package was based on). <https://symas.com/linuxopenldap/> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: RE24 testing call #2 (2.4.49) LMDB RE0.9 testing call (0.9.25)
by Lucio De Re 29 Jan '20

29 Jan '20

On 1/28/20, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the second testing call for OpenLDAP 2.4.49. Depending on the > results, this may be the only testing call. > Under NetBSD 8.1 (i386) compilation was eventually successful: - SASL is not in the distribution, so the "/usr/pkg" prefix was needed in a few places; - HDB and BDB need to be disabled as at least one of them is not compatible. When executing "make test", one of LD_LIBRARY_PATH or LD_RUN_PATH (the former, I think) had to be set to /usr/pkg/lib. Perhaps the "rpath" can be set during compilation, I'm not that familiar with the details. Finally, a lot of tests succeeded, albeit slowly (it's an old host), they stopped with this last stanza: >>>>> Starting test060-mt-hot for mdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... /home/lucio/tmp/openldap-OPENLDAP_REL_ENG_2_4-c5ea2bb/tests/../servers/slapd/slapd -s0 -f /home/lucio/tmp/openldap-OPENLDAP_REL_ENG_2_4-c5ea2bb/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats Testing basic monitor search... Monitor searches Testing basic mt-hot search: 1 threads (1 x 50000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000 Testing basic mt-hot search: 5 threads (1 x 10000) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000 Testing basic mt-hot search: 100 threads (5 x 100) loops... ./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100 slapd-mtread failed (1)! >>>>> test060-mt-hot failed for mdb (exit 1) *** Error code 1 Stop. make[2]: stopped in /home/lucio/tmp/openldap-OPENLDAP_REL_ENG_2_4-c5ea2bb/tests *** Error code 1 Stop. make[1]: stopped in /home/lucio/tmp/openldap-OPENLDAP_REL_ENG_2_4-c5ea2bb/tests *** Error code 1 Stop. make: stopped in /home/lucio/tmp/openldap-OPENLDAP_REL_ENG_2_4-c5ea2bb I'm afraid I don't see anything else that you may find useful. Lucio.

3 3

cn=config replication stops after adding olcAccess entries
by Jan Hugo Prins 28 Jan '20

28 Jan '20

Hello, I'm trying to setup a new MMR cluster. I started the installation using the documentation from: https://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master OS: CentOS 7.7. CentOS RPM packages OpenLDAP version 2.4.44-21 The base installation works fine, all schema's loaded etc. At first I was thinking everything was fine, until I started testing failure scenario's. When I tried to rebuild a failed node I noticed that it wouldn't be populated. cn=config was empty except for the base config and only some data was replicated. After a lot of searching I found that adding any olcAccess rules would destroy the replication. With the olcAccess lines in the config below only the schemas are replicated. When I remove all olcAccess lines all replication works. The base config I use for a node looks like this: dn: cn=config objectClass: olcGlobal cn: config olcServerID: 1 ldap://ldap01.internal olcServerID: 2 ldap://ldap02.internal olcServerID: 3 ldap://ldap03.internal olcPidFile: /var/run/openldap/slapd.pid olcLogLevel: 16512 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=config olcRootPW: eich4mieceeB6ma9ehah olcSyncRepl: rid=001 provider=ldap://ldap01.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncRepl: rid=002 provider=ldap://ldap02.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncRepl: rid=003 provider=ldap://ldap03.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcMirrorMode: TRUE dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap/ olcModuleLoad: syncprov.la dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov The complete config on a running node looks like this: dn: cn=config objectClass: olcGlobal objectClass: olcConfig objectClass: top cn: config olcLogLevel: 16512 olcPidFile: /var/run/openldap/slapd.pid olcServerID: 1 ldap://ldap01.internal olcServerID: 2 ldap://ldap02.internal olcServerID: 3 ldap://ldap03.internal dn: cn=module{0},cn=config objectClass: olcModuleList objectClass: olcConfig objectClass: top cn: module{0} olcModuleLoad: {0}syncprov.la olcModulePath: /usr/lib64/openldap/ dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: olcFrontendConfig objectClass: top olcAccess: {0}to dn.subtree="dc=domain,dc=com" attrs=userPassword,shadowLastChange by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=domain,dc=com" attrs=sambaNTPassword by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {2}to dn.subtree="dc=domain,dc=com" attrs=sambaLMPassword by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth by * none olcAccess: {3}to dn.subtree="dc=domain,dc=com" by dn.base="cn=bbsyncrepl,dc=domain,dc=com" read by self write by * read olcAddContentAcl: FALSE olcDatabase: {-1}frontend olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: TRUE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {0}config olcMirrorMode: TRUE olcMonitoring: TRUE olcRootDN: cn=config olcRootPW: XXXXXX olcSyncrepl: {0}rid=001 provider=ldap://ldap01.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://ldap02.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: {2}rid=003 provider=ldap://ldap03.internal binddn="cn=config" bindmethod=simple credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1 dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {1}syncprov dn: olcDatabase={1}bdb,cn=config objectClass: olcBdbConfig objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcAddContentAcl: FALSE olcDatabase: {1}bdb olcDbCacheFree: 1 olcDbCacheSize: 1000000 olcDbCheckpoint: 512 5 olcDbDirectory: /var/lib/ldap olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 0 olcDbIndex: default sub olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,subinitial olcDbIndex: uid pres,eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: mailLocalAddress pres,eq olcDbIndex: memberUid eq olcDbIndex: mail eq,subinitial olcDbIndex: mailRoutingAddress pres,eq olcDbIndex: sambaSID eq olcDbIndex: sn eq,subinitial olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: givenName eq,subinitial olcDbIndex: sendmailMTAHost pres,eq,sub olcDbIndex: sambaDomainName eq olcDbIndex: sendmailMTAKey pres,eq,sub olcDbIndex: sendmailMTAMapName pres,eq olcDbIndex: sendmailMTAAliasValue pres,eq olcDbIndex: sendmailMTAMapValue pres,eq olcDbIndex: sendmailMTAAliasGrouping pres,eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbSearchStack: 16 olcDbShmKey: 0 olcLastMod: TRUE olcLimits: {0}dn.exact="cn=Manager,dc=domain,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited olcLimits: {1}dn.exact="cn=bbsyncrepl,dc=domain,dc=com" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited olcLimits: {2}dn.exact="cn=incontrol,dc=domain,dc=com" size.soft=unlimited size.hard=unlimited time.soft=unlimited time.hard=unlimited olcMaxDerefDepth: 15 olcMirrorMode: TRUE olcMonitoring: TRUE olcReadOnly: FALSE olcRootDN: cn=Manager,dc=domain,dc=com olcRootPW: XXXXXX olcSuffix: dc=domain,dc=com olcSyncrepl: {0}rid=004 provider=ldap://ldap01.internal binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0 starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off olcSyncrepl: {1}rid=005 provider=ldap://ldap02.internal binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0 starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off olcSyncrepl: {2}rid=006 provider=ldap://ldap03.internal binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0 starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov In the logging I see the following: Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "entry" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "objectClass" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "entry" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "objectClass" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "entry" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access to "cn=config" "objectClass" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: search access granted by manage(=mwrscxd) Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e => access_allowed: read access to "cn=config" "entry" requested Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access granted But also: Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2: rid=003 (53) Server is unwilling to perform Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrepl: rid=003 rc -2 retrying Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2: rid=002 (53) Server is unwilling to perform Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrepl: rid=002 rc -2 retrying Something else I see, when I use jxplorer to look at the content of a server using the cn=config credentials I would expect to see all values including the empty values. On a server without olcAccess lines I see this, but when there are olcAccess lines I only see the configured values. All unset values are not visible. Any help is appreciated. Thank you very much. Jan Hugo Prins

2 3

Re: LDAPS Multi-master replication
by Quanah Gibson-Mount 28 Jan '20

28 Jan '20

Hello, Please keep replies on the list. --On Tuesday, January 28, 2020 8:06 AM +0000 Клеусов Владимир Сергеевич <Kleusov.Vladimir(a)wildberries.ru> wrote: > Fixed Not sure what you're saying was fixed. There was not really any errors discussed in your prior email, simply a note that the replication you were configurating would only replicate the cn=config database. Your modification appears to keep that behavior. > dn: olcDatabase={0}config,cn=config > changetype: modify > replace: olcSyncRepl > olcSyncRepl: rid=001 provider=ldaps://infra-ldap-m9.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=002 provider=ldaps://infra-ldap.dl.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" credentials=5fX?BLR2 starttls=no > tls_cert="/etc/ldap/sasl2/w.ru.crt" tls_key="/etc/ldap/sasl2/wb.ru.key" > tls_cacert="/etc/ldap/sasl2/commercial_ca.crt" tls_reqcert=allow > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=003 provider=ldaps://infra-ldap.dp.wb.ru > searchbase="cn=config" bindmethod=simple credentials=5fX?BLR2 > binddn="cn=admin,cn=config" starttls=no > tls_cert="/etc/ldap/sasl2/wb.ru.crt" > tls_key="/etc/ldap/sasl2/wb.ru.key"tls_cacert="/etc/ldap/sasl2/commercial > _ca.crt" tls_reqcert=allow type=refreshAndPersist retry="5 5 300 5" > timeout=1 Your above configuration seems very odd. You are not doing client cert authentication via SASL EXTERNAL, and yet you've specified a client cert and key. I would expect the only TLS configuration bits to be for the CA cert. > But in logs on each server > slap_client_connect: URI=ldaps://infra-ldap.dl.wb.ru > DN="cn=admin,cn=config" ldap_sasl_bind_s failed So it's not able to bind with the configuration to the other server. > openssl s_client -connect infra-ldap.dp.wb.ru:636 > Verify return code: 0 (ok) > Do I need to specify port 636 in steps 5 and 7 ? For example, it was > ldaps:/ / infra-ldap-m9.wb. ru and will become ldaps://infra-ldap-m9.wb. > ru:636 No, port 636 is the default for ldaps. > And how else can you figure out what's wrong ? I would use the ldapwhoami utility to ensure you can bind with the specified identity to each server. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

LDAPS Multi-master replication
by Клеусов Владимир Сергеевич 27 Jan '20

27 Jan '20

Hi I plan to configure Multi-master replication LDAPS on 3 servers. Are my steps correct ? 1) On each server dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov 2) On server 1 dn: cn=config changeType: modify add: olcServerID olcServerID: 1 3) On server 2 dn: cn=config changeType: modify add: olcServerID olcServerID: 2 4) On server 3 dn: cn=config changeType: modify add: olcServerID olcServerID: 3 4) On each server dn: olcDatabase={0}config,cn=config changetype: modify add: olcRootPW olcRootPW: 5fX?BLR2 5) On each server dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldaps://infa1.domain.com olcServerID: 2 ldaps://infra2.domain.com olcServerID: 3 ldaps://infra3.domain.<ldaps://infra3.test.local>com 6) On each server dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov 7) On each server dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://infra1.domain.com binddn="cn=admin,cn=config" bindmethod=sasl saslmech=EXTERNAL starttls=no tls_cert="/etc/ldap/sasl2/cert.ru.crt" tls_key="/etc/ldap/sasl2/cert.ru.crt" tls_cacert="/etc/ldap/sasl2/comodo.crt" tls_reqcert=allow credentials=5fX?BLR2 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://infra2.domain.comn binddn="cn=admin,cn=config" bindmethod=sasl saslmech=EXTERNAL starttls=no tls_cert="/etc/ldap/sasl2/cert.ru.crt" tls_key="/etc/ldap/sasl2/cert.ru.crt" tls_cacert="/etc/ldap/sasl2/comodo.crt" tls_reqcert=allow credentials=5fX?BLR2 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://infra3.domain.com binddn="cn=admin,cn=config" bindmethod=sasl saslmech=EXTERNAL starttls=no tls_cert="/etc/ldap/sasl2/cert.ru.crt" tls_key="/etc/ldap/sasl2/cert.ru.crt" tls_cacert="/etc/ldap/sasl2/comodo.crt" tls_reqcert=allow credentials=5fX?BLR2 searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE Is this correct ?

2 1

RE24 testing call (2.4.49) LMDB RE0.9 testing call (0.9.25)
by Quanah Gibson-Mount 27 Jan '20

27 Jan '20

This is the first testing call for OpenLDAP 2.4.49. Depending on the results, this may be the only testing call. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.49 Engineering Fixed client tools to not add controls on cancel/abandon (ITS#9145) Fixed libldap to correctly free sb (ITS#9081, ITS#8755) Fixed libldap descriptor leak if ldaps fails (ITS#9147) Fixed libldap remove unnecessary global mutex for GnuTLS (ITS#9069) Fixed slapd syntax evaluation of preferredDeliveryMethod (ITS#9067) Fixed slapd to relax domainScope control check (ITS#9100) Fixed slapd to have cleaner error handling during connection setup (ITS#9112) Fixed slapd data check when processing cancel exop (ITS#9124) Fixed slapd attribute description processing (ITS#9128) Fixed slapd-ldap to set oldctrls correctly (ITS#9076) Fixed slapd-mdb to honor unchecked limit with alias deref (ITS#7657) Fixed slapd-mdb missing final commit with slapindex (ITS#9095) Fixed slapd-mdb drop attr mappings added in an aborted txn (ITS#9091) Fixed slapd-mdb nosync FLAG configuration handling (ITS#9150) Fixed slapd-monitor global operation counter reporting (ITS#9119) Fixed slapo-ppolicy when used with slapauth (ITS#8629) Fixed slapo-syncprov fix sessionlog init (ITS#9146) Fixed slapo-unique loop termination (ITS#9077) Build Environment Fix mkdep to honor TMPDIR if set (ITS#9062) Remove ICU library detection (ITS#9144) Documentation slapd-config(5)/slapd.conf(5) - Fix missing bold tag for keyword (ITS#9063) slapd-ldap(5) - Document "tls none" option (ITS#9071) slapo-ppolicy(5) - Correctly document pwdGraceAuthnLimit (ITS#9065) LMDB 0.9.25 Engineering ITS#9068 fix mdb_dump/load backslashes in printable content ITS#9118 add MAP_NOSYNC for FreeBSD Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 6

multimaster delta syncrepl inconsistent attribute values
by Zach Hanson Hart 27 Jan '20

27 Jan '20

I am seeing inconsistent values for an attribute after conflicting writes. I mostly followed https://mishikal.wordpress.com/2019/04/23/configuring-mmr-using-delta-syncr… for the setup, and mostly followed test063-delta-multimaster from the source code for the test scenario. The problem is that when I do conflicting writes while replication is broken, after replication is restored, the entry ends up with different values for an employeeNumber but everything else the same. My cluster has 3 nodes When all is said and done, the entry looks like the following on two nodes: dn: cn=fakeentryfortesting,ou=people,dc=temple,dc=edu objectClass: inetOrgPerson cn: fakeentryfortesting sn: fakeentryfortesting givenName: fakeentryfortesting carLicense: 123-XYZ description: take two from 16 description: take two from 17 description: written on 16 description: written on 17 employeeNumber: from16 employeeType: deadwood entryCSN: 20200124200603.270449Z#000000#075#000000 entryDN: cn=fakeentryfortesting,ou=people,dc=temple,dc=edu entryUUID: 737fddce-d330-1039-89fc-4599653df8c5 hasSubordinates: FALSE modifiersName: cn=admin,dc=temple,dc=edu modifyTimestamp: 20200124200603Z createTimestamp: 20200124200419Z creatorsName: cn=admin,dc=temple,dc=edu structuralObjectClass: inetOrgPerson subschemaSubentry: cn=Subschema BUT, on one node, it has employeeNumber: from17 as the only difference. >From an earlier post, this is not expected behavior. I'm including some info here in hopes that it's enough to get a workaround. If not, I can provide whatever debugging info is needed. This is a source compiled slapd 2.4.48 running on RHEL 7.7 with a preloaded libtcmalloc.so.4. I experienced the same behavior with 2.4.45. Some gory details... -------------- Overview -------------- I initially set up a single node as standalone. I then added a small ldif to give a tree to replicate. Then, I made the node do delta multimaster. Details of this are further down. I wrote an entry and verified that it got the correct Server ID in the contextCSN. I did ldapsearch -H ldapi:// -Y external -LLL -b cn=config >config.ldif to save the resulting configuration. Then I did a slapadd of that to another fresh node with empty slapd.d and database folders. It synced the data as expected. I repeated on another node. So, I have 3 nodes with identical configurations, call them 16, 17 and 18. Replication seems to be working as expected. slapd is run with: -h ldapi:/// ldaps://pre-ldapr16.temple.edu (or pre-ldapr17 or 18, depending on the node). I verified many, many times that these are identical to what's in the olcServerID, and identical to the provider in the olcSyncrepl attribute. I'm the only one accessing these nodes right now, and certainly the only one using this test DN. ------------- TEST SCENARIO ------------- My test for this mostly follows test063-delta-multimaster. Below, $TESTDN is cn=fakeentryfortesting,ou=people,dc=temple,dc=edu. It seeds a test entry and makes sure it is the same on each node: dn: $TESTDN objectClass: inetorgperson cn: fakeentryfortesting sn: fakeentryfortesting givenName: $TESTCN description: test It breaks replication on each node by replacing the password in the olcSyncrepl values with a wrong password. Below, $X is 16, 17 or 18, depending on the node. For each of the three nodes, it applies: dn: $TESTDN changetype: modify add: description description: written on $X Then for each node it applies: dn: $TESTDN changetype: modify delete: description description: test - add: description description: take two from $X Then on 16, it applies: dn: $TESTDN changetype: modify add: carLicense carLicense: 123-XYZ - add: employeeNumber employeeNumber: from$X and on a different node it applies: dn: $TESTDN changetype: modify add: employeeType employeeType: deadwood - add: employeeNumber employeeNumber: from$X It then restores replication and checks the entry on the different nodes. ------------------ INITIAL STANDALONE CONFIG ------------------ dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcAuthzPolicy: to olcAuthzRegexp: {0}uid=ldap/([^,]*),cn=PREKDC.TEMPLE.EDU,cn=gssapi,cn=auth $1 olcConnMaxPending: 101 olcLogLevel: stats stats2 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcSecurity: simple_bind=128 olcSecurity: tls=0 olcSecurity: ssf=71 olcSockbufMaxIncoming: 22143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 8 olcTLSCACertificateFile: /etc/ssl/certs/intermediate.crt olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: /etc/ssl/certs/ldap.pem olcTLSCertificateKeyFile: /etc/ssl/private/ldap.key.pem olcTLSCipherSuite: ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+ AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS:!RC4:!3DES:!eNULL:!PSK olcTLSDHParamFile: /etc/ssl/private/dhparam.bin olcTLSProtocolMin: 3.2 olcToolThreads: 2 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/libexec/openldap olcModuleLoad: {0}back_mdb olcModuleLoad: {1}auditlog olcModuleLoad: {2}unique dn: cn=schema,cn=config # ... entry and subtree omitted for brevity 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=externa l,cn=auth manage by dn.base="cn=replicator,dc=temple,dc=edu" manage by * brea k olcAccess: {1}to dn.base="cn=Subschema" by * read olcAccess: {2}to dn.exact="" by * read olcLastMod: TRUE olcReadOnly: FALSE olcSizeLimit: size.soft=2000 size.hard=1000000 olcTimeLimit: time.soft=300 time.hard=3600 olcPasswordHash: {SSHA} olcSortVals: hasMember 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 dn.base="cn=replicator,dc=temple,dc=edu" read by dn.exact= "cn=admin,dc=temple,dc=edu" manage by * break olcAccess: {1}to dn.base="cn=Subschema" by * read olcAccess: {2}to dn.exact="" by * read olcAccess: {3}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}.......... olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/var/lib/ldap/rootdb olcSuffix: dc=temple,dc=edu olcAccess: {0} to dn.exact="cn=Subschema" by * read olcAccess: {1} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=externa l,cn=auth manage by dn.base="cn=replicator,dc=temple,dc=edu" manage by * brea k olcAccess: {2} to attrs=userPassword by * auth olcAccess: {3} to dn.exact="" by * read olcLastMod: TRUE olcLimits: {0}dn.base="cn=replicator,dc=temple,dc=edu" size=unlimited time=unl imited olcRootDN: cn=admin,dc=temple,dc=edu olcRootPW: {SSHA}................. olcMonitoring: TRUE olcDbEnvFlags: nosync olcDbIndex: default eq olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: templeEduTUID eq,sub olcDbIndex: templeEduTUNIC eq # other indexes omitted olcDbIndex: cn,sn pres,eq,approx,sub olcDbIndex: mail pres,eq,sub olcDbIndex: objectClass pres,eq olcDbIndex: loginShell pres,eq olcDbIndex: entryCSN,entryUUID olcDbIndex: givenName,o,name,ou,displayName,eduPersonNicknameeq,sub olcDbIndex: hasMember eq olcDbIndex: mailAlternateAddress eq,sub olcDbIndex: manager eq olcDbIndex: owner eq olcDbIndex: uniqueMember eq olcDbMaxSize: 17179869184 dn: olcOverlay={0}auditlog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAuditLogConfig olcOverlay: {0}auditlog olcAuditlogFile: /var/log/ldap/audit.ldif dn: olcOverlay={1}unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: {1}unique olcUniqueAttribute: templeEduTUNA olcUniqueAttribute: templeEduTUid -------------- INITIAL DATA -------------- dn: dc=temple,dc=edu objectClass: dcObject objectClass: organization o: temple.edu dc: temple dn: cn=replicator,dc=temple,dc=edu objectClass: simpleSecurityObject objectClass: organizationalRole cn: replicator description: LDAP replicator userPassword: {SSHA}.... dn: ou=people,dc=temple,dc=edu objectClass: top objectClass: organizationalUnit ou: people ------------------ MODIFICATION TO MAKE IT DELTA MMR ------------------ dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov olcModuleLoad: accesslog dn: cn=config changetype: modify replace: olcServerID olcServerID: 116 ldaps://pre-ldapr16.temple.edu olcServerID: 117 ldaps://pre-ldapr17.temple.edu olcServerID: 118 ldaps://pre-ldapr18.temple.edu dn: olcDatabase={2}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /usr/local/var/lib/ldap/accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="cn=replicator,dc=temple,dc=edu" read by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcLimits: dn.exact="cn=replicator,dc=temple,dc=edu" time=unlimited size=unlimited olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCheckpoint: 0 0 olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart,reqDN,entryUUID eq olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxsize: 85899345920 dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 20 10 olcSpSessionlog: 10000000 olcSpReloadHint: TRUE dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 00+04:00 dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=306 provider=ldaps://pre-ldapr16.temple.edu bindmethod=simple binddn="cn=replicator,dc=temple,dc=edu" credentials=password keepalive=0:5:0 tls_reqcert=allow searchbase="dc=temple,dc=edu" scope=sub schemachecking=on type=refreshAndPersist retry="5 5 5 +" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog syncdata=accesslog olcSyncrepl: {1}rid=307 provider=ldaps://pre-ldapr17.temple.edu bindmethod=simple binddn="cn=replicator,dc=temple,dc=edu" credentials=password keepalive=0:5:0 tls_reqcert=allow searchbase="dc=temple,dc=edu" scope=sub schemachecking=on type=refreshAndPersist retry="5 5 5 +" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog syncdata=accesslog olcSyncrepl: {2}rid=308 provider=ldaps://pre-ldapr18.temple.edu bindmethod=simple binddn="cn=replicator,dc=temple,dc=edu" credentials=password keepalive=0:5:0 tls_reqcert=allow searchbase="dc=temple,dc=edu" scope=sub schemachecking=on type=refreshAndPersist retry="5 5 5 +" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog syncdata=accesslog - replace: olcMirrorMode olcMirrorMode: TRUE You really see this far down? Awesome! Maybe there's somethig that jumped out at you as wrong with this? Thanks for any help, Zach

2 1

Mirrormode activ server
by Stefan Kania 24 Jan '20

24 Jan '20

Hi, maybe I can't find it or I forgot it :-), but is there a way to find out which of my two servers in a mirrormode setup is active and which one is passive? Thanks for any hint Stefan

2 2

Making changes to olc configuration
by Prentice Bisbal 23 Jan '20

23 Jan '20

Thanks to your help, I've discovered I need to increase the size of my mdb MaxSize. I created the following LDIF file to increase it by a factor of 10: dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbMaxSize olcDbMaxSize: 104857600 Now I can make changes to the LDAP directory itself, but when I try to make changes to the OLC data, like this change, I get an Insufficient access error: $ ldapmodify -v -f mdb.ldif add olcDbMaxSize: 104857600 modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Insufficient access (50) How can I overcome this and give myself access to make these changes in the future? In the past I was advised to do a slapcat of the OLC database, make my changes, and then do a slapadd of the modified LDIF file.. Unfortunately, I forget details of that magical incantation, and I'd also like to make so I have the necessary privileges to make these changes in the future through LDIF changes like the one above. All you help is greatly appreciated. I know these answers are probably in the manual, and "RTFM" might be justified, but I'm a little under the gun trying to get a formerly working system up and running again, and I still haven't fully grasped OLC yet. -- Prentice

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2020