January 2020 - openldap-technical

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl 23 Jul '20

23 Jul '20

Hi! After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted: slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted. The next line logged was: slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389) (the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice) The server is one of three MM servers that all have the same configuration and the same version. The schema knows in olcAttributeTypes (olcSchemaConfig): ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd? Regards, Ulrich

4 10

MultiMaster replication password
by Клеусов Владимир Сергеевич 03 Feb '20

03 Feb '20

Hi Can I write this question here ? I did at https://linuxlasse.net/linux/howtos/OpenLDAP_N-Way_MultiMaster_Replication Everything works. But passwords are not replicated. How to configure password replication?

3 7

termux liblmdb package available (0.9.24)
by Craig Comstock 03 Feb '20

03 Feb '20

Hello, liblmdb is available as a package for the Android app/environment Termux. You can install it with `pkg install liblmdb`. The package script and patch are here: https://github.com/termux/termux-packages/tree/master/packages/liblmdb If you wish to review them and/or improve on them. Thanks, Craig Comstock CFEngineer/digger for Northern.tech

2 1

openSUSE/SLE builds (was: OpenLDAP 2.4.49 available, LMDB 0.9.25 available)
by Michael Ströder 31 Jan '20

31 Jan '20

On 1/30/20 7:17 PM, OpenLDAP project wrote: > OpenLDAP 2.4.49 is now available for download as detailed on our > download page: For those who are impatient to get drop-in builds for openSUSE and SLE: https://build.opensuse.org/package/show/network:ldap/openldap2 These builds replace the system-wide libldap which might break version-pinning in your local installation. So you have to know what you're doing! Also I maintain builds installing in separate prefix /opt/openldap-ms and with reduced feature set (e.g. no back-bdb and no back-hdb): https://build.opensuse.org/package/show/home:stroeder:openldap/openldap-ms Please test. Feedback welcome! BTW: In OBS you can also simply branch the above packages to your own OBS home project and adjust the .spec to your own needs. Ciao, Michael.

1 0

Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
by Vijay Kumar 31 Jan '20

31 Jan '20

I could see some stats from mdb-stat tool as mentioned below, mdb_stat.exe -rne "C:\openldap\mdb\data.mdb" Environment Info Map address: 0000000000000000 Map size: 268435456 (we have set the value as *‭104,857,600,000,000‬* in mdb.c and back_mdb.h files, but it has taken only 256 MB, not sure why?) Page size: 4096 Max pages: 65536 Number of pages used: 65527 Last transaction ID: 9555 Max readers: 126 Number of readers used: 0 Reader Table Status (no active readers) when i try to increase to set the dbMaxSize it fails, *addDbMaxSize.ldif * has content as mentioned below, dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbMaxSize olcDbMaxSize: 1073741824 olcDbMaxSize: *1073741824 - stops the service in windows* openldap \bin>ldapmodify -H ldaps://localhost:6565 -D cn=admin,cn=config -w d -f addDbMaxSize.ldif modifying entry "olcDatabase={1}mdb,cn=config" *ldap_modify: Other (e.g., implementation specific) error (80) additional info: failed to reopen database, rc=87* olcDbMaxSize: ‭*536870912‬ - failed as below* openldap \bin>ldapmodify -H ldaps://localhost:6565 -D cn=admin,cn=config -w d -f addDbMaxSize.ldif modifying entry "olcDatabase={1}mdb,cn=config" *ldap_modify: Invalid syntax (21) additional info: olcDbMaxSize: value #0 invalid per syntax* *back-mdb.h - we added as below* #define DEFAULT_MAPSIZE (10 * 10 * 10 * 10 * 10 * 10 * 10 * 10 * 1048576) mdb.c - we added as below #define DEFAULT_MAPSIZE (10 * 10 * 10 * 10 * 10 * 10 * 10 * 10 * 1048576) if ((i = mdb_env_read_header(env, &meta)) != 0) { if (i != ENOENT) return i; DPUTS("new mdbenv"); newenv = 1; env->me_psize = env->me_os_psize; if (env->me_psize > MAX_PAGESIZE) env->me_psize = MAX_PAGESIZE; memset(&meta, 0, sizeof(meta)); mdb_env_init_meta0(env, &meta); meta.mm_mapsize = DEFAULT_MAPSIZE; } else { env->me_psize = meta.mm_psize; } *1. i am not getting why the size of the map (as per the stats info given above) - 256 MB (268435456) only ? please provide me a clue once to understand this.* *2. Kindly let me know how to get debug logs ? i use DPRINTF, DPUT in mdb.c but dint get see as logs printed.!* *We observed this in Windows 2012 R2 and Window10 OS x64 Arch machines.* Regards, Vijay Kumar On Thu, Jan 30, 2020 at 12:46 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, January 30, 2020 6:09 AM +0000 > pasumarthivijaykumar(a)gmail.com wrote: > > > --00000000000025b743059d554b79 > > Content-Type: text/plain; charset="UTF-8" > > Content-Transfer-Encoding: quoted-printable > > > > Thanks for your reply I do know that info for windows also is it the > > same.? I am unable to use stats tool also. > > As I already stated, the maxsize parameter specifies the maximum size the > database can reach. > > > As I don=E2=80=99t see any reply from our many mails to > > openldap-technical(a)openldap.org I have created this case to clarify. > > > The openldap-technical list is only open to subscribers, if you want to > post to it you must subscribe first. > > > > Why don=E2=80=99t you forward the query to the concerned team instead > > closi= ng. > > Your query would not be forwarded because you failed to read and/or > understand the documentation. This system is for bug reports only. > > > No reply to us.! > > I did reply. This is clearly shown in the ITS. > > > Please let us know answer to solve a issue.! > > > I already provided you the answer in my earlier response. Set an > approprate maxsize setting, the default of 10MB is clearly too low. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Thanks & Regards, Vijay Kumar *+91-94944 44009*

2 1

Re: How to fetch LDAP Server version using Java
by Vijay Kumar 31 Jan '20

31 Jan '20

Hi Quanah Thanks a lot for your reply. I tried but dint get any reply I think we need to add monitor database. Will try to add the same and let you know. Regards, Vijay Kumar On Thu, Jan 30, 2020 at 10:49 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, January 30, 2020 2:34 PM +0530 Vijay Kumar > <pasumarthivijaykumar(a)gmail.com> wrote: > > In the future, do not cross post to multiple lists. You were already told > specifically to address your questions to openldap-technical(a)openldap.org. > > supportedLDAPVersion tracks the LDAP version (LDAP version 3), it does not > track the underlying version of OpenLDAP. > > However, if you enable the monitor backend (See the man page for > slapd-monitor(5)), the OpenLDAP version is contained in the monitoredInfo > attribute: > > ldapsearch -x -LLL -H ldap:/// -s base -b cn=monitor monitoredInfo > dn: cn=Monitor > monitoredInfo: OpenLDAP: slapd 2.4.48 (Jan 29 2020 19:43:07) > > This of course requires that your program have permission to read from > that > database. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Thanks & Regards, Vijay Kumar *+91-94944 44009*

1 0

Re: How to use mdb_stat.c - memory-mapped database status tool
by Vijay Kumar 30 Jan '20

30 Jan '20

On Thu, Jan 30, 2020 at 11:29 AM Vijay Kumar <pasumarthivijaykumar(a)gmail.com> wrote: > Hi Team, > > Can i request to let me know how to use > mdb_stat.c - memory-mapped database status tool > > google and docs of openldap dint help me.! > > Thank you. > -- > Thanks & Regards, > > Vijay Kumar > *+91-94944 44009* > -- Thanks & Regards, Vijay Kumar *+91-94944 44009*

2 1

Re: How to fetch LDAP Server version using Java
by Vijay Kumar 30 Jan '20

30 Jan '20

Hi Team, >From my Java Program i am in need to find the LDAP Server version. i am able to get supportedLDAPVersion using below search query, LDAPSearchResults ldapSearchResults = ldapConn.search("", LDAPConnection.SCOPE_BASE, "(objectclass=*)", new String[] {"supportedLDAPVersion"}, false); No results found, when i try to use vendorVersion and vendorName (like that queried like below) ldapSearchResults = ldapConn.search("", LDAPConnection.SCOPE_BASE, "(objectclass=*)", new String[] {"vendorVersion"}, false) is there any approach that can follow, please let me know. i am need to get info as below, root@docker_container:/etc/ldap/slapd.d# ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Jul 30 2019 16:24:19) $ Debian OpenLDAP Maintainers < pkg-openldap-devel(a)lists.alioth.debian.org> * (LDAP library: OpenLDAP *20448*)* root@docker_container:/etc/ldap/slapd.d# Thank you. -- Thanks & Regards, Vijay Kumar *+91-94944 44009*

2 1

Re: CentOS drops OpenLDAP servers package starting with 8.1
by Dave Macias 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/> > That was expected! Testing CentOS8 distro is my next project since 7 will eventually reach EOL....gotta get ready Thank you for the continued support!!

1 0

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 30 Jan '20

30 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

LMDB: "non-cached" reads
by Dmitri Shubin 22 Jan '20

22 Jan '20

Hi, Our application uses LMDB and sometimes we need to perform scan of old ("cold") data. The problem here is that this data can/will remove "hot" data from page-cache. Ideally to prevent this from happening we'd like to somehow mark cursor as "streaming"/"non-temporal". But AFAICS there is no such feature currently. We're experimenting with marking pages returned by cursor with madvise(MADV_DONTNEED) and this at least prevents RSS from growing. But maybe there are some downsides of this approach? Thanks! -- ______________________________ itiviti.com <https://www.itiviti.com/> <https://www.linkedin.com/company/itiviti> Follow Itiviti on Linkedin <https://www.linkedin.com/company/10438325/> The information contained in or attached to this email is strictly confidential. If you are not the intended recipient, please notify us immediately by telephone and return the message to us. Email communications by definition contain personal information. The Itiviti group of companies is subject to European data protection regulations. Itiviti’s Privacy Notice is available at www.itiviti.com <http://www.itiviti.com/>. Itiviti expects the recipient of this email to be compliant with Itiviti’s Privacy Notice and applicable regulations. Please advise us immediately at dataprotectionteam(a)Itiviti.com if you are not compliant with these.

2 2

Re: [External] Re: Replication suddenly broken
by Prentice Bisbal 22 Jan '20

22 Jan '20

On 1/16/20 8:05 PM, Quanah Gibson-Mount wrote: > > --On Thursday, January 16, 2020 9:03 PM +0000 Prentice Bisbal > <pbisbal(a)princeton.edu> wrote: > >> One of my coworkers just noticed that replication is broken between our >> primary and secondary LDAP servers. It appears to have been broken for >> about 1 week now. Nothing has changed relative to the LDAP configuration >> on either of our servers, so this is an odd thing to suddenly happen. >> When I look at the consumer with some debugging on, I see these messages >> (/usr/sbin/slapd -d 1638 was used to get these messages): >> >> It looks like the consumer >> host/voltron-b.pppl.gov,cn=pppl.gov,cn=gssapi,cn=auth,is being rejected >> as not being authorized, but this has been working for years w/o issue. >> Any idea what has changed and how I may fix it? > > Well, the error came from cyrus-sasl rather than OpenLDAP. This would > indicate to me that the not authorized came from the KDC. Have you checked > to ensure the keys in the keytab file haven't expired inside the KDC? > That's exactly what I suspected. We're using AD for our Kerberos Client, and one of our AD admins insists that it couldn't be expired credentials. I did use a utility called msktutil to make sure the kerberos tickets in /etc/krb5.keytab were up to date, but I'm still getting that error. Any ideas on how to prove/disprove what you suggest, so I can go back to my AD admins with more information? -- Prentice

3 5

mdb_put failed: MDB_MAP_FULL
by Prentice Bisbal 21 Jan '20

21 Jan '20

I've temporarily fixed my Kerberos problem (I think) by using k5start to start slapd in debug mode: k5start -f /etc/krb5.keytab host/voltron-b.pppl.gov -- /usr/sbin/slapd -d 1634 When I do this, I no longer see the SASL auth failures, but now I'm seeing this error. Does this mean there are too many members in the group "trbatch"? mdb_id2entry_put: mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792) "cn=trbatch,ou=groups,dc=unix,dc=pppl,dc=gov" 5e27700b null_callback : error code 0x50 5e27700b syncrepl_entry: rid=001 be_modify failed (80) sasl_generic_write: want=71, written=71 -- Prentice

2 1

implementing changlog in openldap
by nomit babraa 21 Jan '20

21 Jan '20

Hi We are using open ldap (sorry don't have access to the version at the moment) and were wondering if there is any support for creating a changelog that is available at cn=changelog? We have a third party system that could use this changelog for monitoring event driven changes and I've had difficulty googling anything that sounds officially supported? Thanks for any advice. n

2 1

consistency expectations for 3 node multimaster deltasyncrepl
by Zach Hanson Hart 18 Jan '20

18 Jan '20

Hello list, TL;DR With multimaster deltasyncrepl, when the cluster is partitioned (no replication) and conflicting values are added to an entry for a single-valued attribute, after the nodes are reconnected and replication commences, is it expected for all nodes to end up with the same value for the attribute, or is it expected that they may be inconsistent? The long version: I'm following test063-delta-multimaster in a local test cluster, with 3 master nodes, and I wanted to confirm that I'm not misunderstanding before moving forward. The test test063-delta-multimaster breaks replication and does conflicting adds of a single-valued attribute (employeeNumber) with different values on the two nodes. It then restores replication, gives it a bit to replicate, and then confirms that the "filtered" ldif is the same. My confusion is about this filtering. In the test, it does $LDIFFILTER -s a < $TESTDIR/server$n.out > $TESTDIR/server$n.flt and then compares the filtered files. Does this simply sort the attributes and values, or does it strip values? Essentially, is this testing that the value of the employeeNumber is the same on both nodes, or is it simply testing that the employeeNumber is present on both nodes? Thanks! Zach

2 1

Re: two slapd processes accessing one MDB env
by Ondřej Kuzník 17 Jan '20

17 Jan '20

On Fri, Jan 17, 2020 at 11:07:01AM +0100, Ondřej Kuzník wrote: > On Thu, Jan 16, 2020 at 04:08:28PM +0100, Michael Ströder wrote: > > HI! > > > > I vaguely remember that it's possible that two slapd processes can > > access a single MDB env. > > > > Is that supported? > > Any pre-cautions needed? > > I think if you were to configure both of them as a syncrepl consumer, > that might cause some headaches? (reply to list this time) Also if either of them is a syncrepl provider, probably make sure that no other server is accepting writes to this db file, I can imagine (refreshAndPersist) scenarios that might leave you unhappy otherwise. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

2 2

direct MDB access for counting entries from Python
by Michael Ströder 17 Jan '20

17 Jan '20

HI! In my monitoring check I'd like to indicate how many entries are in a database. Currently I'm using the no-op search control without any filtering to count the entries which is obviously a huge waste of CPU and I/O ressources for just retrieving the raw number of DB entries. Is it easily possible to access the id2e sub-DB and query number of entries? Something like mdb_stat -s id2e -e <db-path> | grep Entries but from Python with python-lmdb or a similar module. (Yes, I know subprocess module but I really hate invoking command-line tools from Python.) Ciao, Michael.

2 5

Question about OpenLDAP and rwm overlay
by Vandenburgh, Steve Y 17 Jan '20

17 Jan '20

I'm attempting to use OpenLDAP as a proxy to an Active Directory domain. Using the ldap backend, I'm able to configure the proxy and that configuration seems to be working well. But account entries are frequently moved from ou to ou in a domain and Microsoft permits the bind DN to be a userPrincipalName attribute value of the entry instead of the full DN of the account; this features avoids having to make many bind DN application configuration changes. With just the ldap backend configured, OpenLDAP rejects the userPrincipalName (UPN) bind DN as an invalid DN. To work around this error, I was trying to see if I could use the rwm overlay to detect the UPN and convert to the actual domain entry DN using an attribute map. If I use the form mail=UPN the map works as expected; however, if I only provide the UPN as the bind DN, OpenLDAP still rejects it as an invalid DN. I suspect that the rwm overlay manipulations to not take effect until after the bind DN syntax is checked. I wanted to confirm my suspicion and see if any one else has been able to get a UPN-based bind to work through OpenLDAP. For reference my slapd.conf configuration is below: ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload rwm # Main settings ############################################################### loglevel 8 sizelimit unlimited idletimeout 600 writetimeout 30 allow bind_v2 pidfile /var/openldap/mycompany/var/slapd.pid argsfile /var/openldap/mycompany/var/slapd.args logfile /var/openldap/mycompany/logs/access TLSCertificateFile /var/openldap/mycompany/certs/Server.pem TLSCertificateKeyFile /var/openldap/mycompany/certs/Server.key TLSCACertificateFile /var/openldap/mycompany/certs/ServerCA.pem ### Rewrite rules ############################################################# # Bind with UPN instead of full DN: we first need # an ldap map that turns attributes into a DN (the # argument used when invoking the map is appended to # the URI and acts as the filter portion) overlay rwm rwm-suffixMassage "" "dc=mycompany,dc=com" rwm-rewriteMap ldap attr2dn "ldaps://mycompany.com/ou=Domain%20Users,dc=mycompany,dc=com?dn?sub" bindwhen=now version=3 binddn="CN=mybindacct,ou=Domain Users,DC=mycompany,DC=com" credentials=****** # Then we need to detect UPN DN # note that the rule in case of match stops rewriting # In case we are mapping virtual # to real naming contexts, we also need to rewrite # regular DNs, because the definition of a bindDN # rewrite context overrides the default definition. rwm-rewriteContext bindDN rwm-rewriteRule "^[^=,]+(a)mycompany.com$" "mail=$0" ":" rwm-rewriteRule "^mail=[^,]+(a)mycompany.com$" "${attr2dn($0)}" ":@" ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user uri "ldaps://mycompany.com" suffix "dc=mycompany,dc=com" Thanks, Steve Vandenburgh This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

6 9

Replication suddenly broken
by Prentice Bisbal 17 Jan '20

17 Jan '20

One of my coworkers just noticed that replication is broken between our primary and secondary LDAP servers. It appears to have been broken for about 1 week now. Nothing has changed relative to the LDAP configuration on either of our servers, so this is an odd thing to suddenly happen. When I look at the consumer with some debugging on, I see these messages (/usr/sbin/slapd -d 1638 was used to get these messages): It looks like the consumer host/voltron-b.pppl.gov,cn=pppl.gov,cn=gssapi,cn=auth,is being rejected as not being authorized, but this has been working for years w/o issue. Any idea what has changed and how I may fix it? ldap_write: want=22, written=22 0000: 30 14 02 01 02 60 0f 02 01 03 04 00 a3 08 04 06 0....`.......... 0010: 47 53 53 41 50 49 GSSAPI ldap_read: want=8, got=8 0000: 30 4a 02 01 02 61 45 0a 0J...aE. ldap_read: want=68, got=68 0000: 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 3a 20 73 ......SASL(0): s 0010: 75 63 63 65 73 73 66 75 6c 20 72 65 73 75 6c 74 uccessful result 0020: 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 : . ............ 0030: 3a f9 e0 c9 07 00 00 00 fd e6 0d 82 df 31 29 00 :............1). 0040: a7 27 90 6a .'.j ldap_write: want=116, written=116 0000: 30 72 02 01 03 60 6d 02 01 03 04 00 a3 66 04 06 0r...`m......f.. 0010: 47 53 53 41 50 49 04 5c 05 04 04 ff 00 0c 00 00 GSSAPI.\........ 0020: 00 00 00 00 36 3c fc 1d 04 ff ff ff 64 6e 3a 75 ....6<......dn:u 0030: 69 64 3d 68 6f 73 74 2f 76 6f 6c 74 72 6f 6e 2d id=host/voltron- 0040: 62 2e 70 70 70 6c 2e 67 6f 76 2c 63 6e 3d 70 70 b.pppl.gov,cn=pp 0050: 70 6c 2e 67 6f 76 2c 63 6e 3d 67 73 73 61 70 69 pl.gov,cn=gssapi 0060: 2c 63 6e 3d 61 75 74 68 c2 5d 9b 4a ce d9 d6 8b ,cn=auth.].J.... 0070: 23 5f b4 1d #_.. ldap_read: want=8, got=8 0000: 30 3c 02 01 03 61 37 0a 0<...a7. ldap_read: want=54, got=54 0000: 01 32 04 00 04 30 53 41 53 4c 28 2d 31 34 29 3a .2...0SASL(-14): 0010: 20 61 75 74 68 6f 72 69 7a 61 74 69 6f 6e 20 66 authorization f 0020: 61 69 6c 75 72 65 3a 20 6e 6f 74 20 61 75 74 68 ailure: not auth 0030: 6f 72 69 7a 65 64 orized 5e20cedc slap_client_connect: URI=ldap://ldap1.pppl.gov ldap_sasl_interactive_bind_s failed (50) ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. 5e20cedc do_syncrepl: rid=001 rc 50 retrying -- Prentice

2 1

two slapd processes accessing one MDB env
by Michael Ströder 17 Jan '20

17 Jan '20

HI! I vaguely remember that it's possible that two slapd processes can access a single MDB env. Is that supported? Any pre-cautions needed? Ciao, Michael.

2 1

Replication account problem
by Vincent Ducot 16 Jan '20

16 Jan '20

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

5 13

Re: Openldap support SHA-256 or SHA-3.
by Quanah Gibson-Mount 15 Jan '20

15 Jan '20

--On Tuesday, January 7, 2020 11:52 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Quanah, > > > Thanks for the quick reply, is there any plans to make SSHA512 default? No. As I said, SHA1 is mandated by RFC. > also is there any migration steps to move from SHA-1 to SSHA512 ? After deploying the sha2 module, all users must change their password so the hash gets updated. There is no way to magically convert existing hashes from SSHA1 to another scheme. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 19

Segmentation Fault on ldap_chain_op
by Jeremy Diaz 14 Jan '20

14 Jan '20

Hi everyone, I am currently looking into an issue with an environment that consists of 3 producers and 6 consumers all on OpenLdap 2.4.48. All the masters share an identical master config and all of the consumers share an identical consumer config. One consumer server in particular is crashing on a random time interval with no obvious reason. Each ldap server has sasl pass through auth setup and there is an additional slapd process on each server being used as a ldap meta to AD. One server in particular, is crashing at seemingly random intervals. Upon initial inspection, we noticed that around the time of a crash, saslauthd logs would have an increase in failed write messages: Dec 11 07:23:20 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:30 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:40 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:56 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2719]: user ldap_search_st() failed: Timed out Dec 11 07:24:05 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:24:06 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write: Broken pipe Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write failure Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write: Broken pipe Initially we thought this meant that the crashes were caused by performance issues with AD, saslauthd or the ldap meta instance. We also ran slapd in full debugging mode to see if the logs have some kind of hints to the source of the issue. The resulting slapd logs were normal. To obtain further information we obtained the following trace of the segfault using gdb: starting [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". frames-invalid [New Thread 0x7ffbf19be700 (LWP 22956)] new-thread [New Thread 0x7ffbf11bd700 (LWP 22957)] new-thread [New Thread 0x7ffbf09bc700 (LWP 22958)] new-thread [New Thread 0x7ffbebfff700 (LWP 22959)] new-thread [New Thread 0x7ffbeb7fe700 (LWP 22963)] new-thread [New Thread 0x7ffbe9cfb700 (LWP 22965)] new-thread [New Thread 0x7ffbd3fff700 (LWP 22966)] new-thread signal Program received signal signal-name SIGSEGV signal-name-end , signal-string Segmentation fault signal-string-end . [Switching to Thread 0x7ffbf09bc700 (LWP 22958)] thread-changed frame-begin 0 0x4e52e3 frame-function-name ldap_chain_op frame-args ( arg-begin op=op@entry arg-name-end = arg-value * 0x7ffbe41f0870 arg-end , arg-begin rs=rs@entry arg-name-end = arg-value * 0x7ffbf09bbb20 arg-end , arg-begin op_f arg-name-end = arg-value * 0x4a845e <ldap_back_search> arg-end , arg-begin ref=ref@entry arg-name-end = arg-value * 0x0 arg-end , arg-begin depth=depth@entry arg-name-end = arg-value - 0 arg-end ) frame-source-begin at frame-source-file chain.c frame-source-file-end : frame-source-line 422 frame-source-end source ${REDACTED DIR}/chain.c:422:11629:beg:0x4e52e3 frame-end stopped post-prompt #0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422 #1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090 #2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237 #3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508 #4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583 #5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861 #6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558 #7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211 #11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251 #12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677 #13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402 #16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247 #20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158 #21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307 #23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbd3ffdc10 " aaf9: 04 3a 75 69 64 3d 53 49 41 53 47 52 50 2c 6f 75 .:uid=SIASGRP,ou \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbcd83df04 "0\203\n\036\273\004\funiqueMember1\203\n\036\250\004\071uid=wtso732,ou={REDACTED}“…, len=len@entry=663561) at bprint.c:202 #5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:276 #6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:247 #7 0x00000000005894c1 in ber_scanf (ber=0x7ffbcc122e20, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723 #8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbd3ffdf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbd3ffe320, msg=<optimized out>, op=0x7ffbd3ffe510, si=0xa3e9e0) at syncrepl.c:2658 #9 do_syncrep2 (op=op@entry=0x7ffbd3ffe510, si=si@entry=0xa3e9e0) at syncrepl.c:1043 #10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3e670) at syncrepl.c:1571 #11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbd3fff700) at pthread_create.c:307 #13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff673e16d in write () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007ffff66c91a3 in _IO_new_file_write (f=0x937c20, data=0x7ffff7ff8000, n=162) at fileops.c:1258 #2 0x00007ffff66ca9be in new_do_write (to_do=162, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., fp=0x937c20) at fileops.c:519 #3 _IO_new_do_write (fp=0x937c20, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., to_do=162) at fileops.c:495 #4 0x00007ffff66c87f8 in _IO_new_file_sync (fp=0x937c20) at fileops.c:869 #5 0x00007ffff66bd5f3 in __GI__IO_fflush (fp=0x937c20) at iofflush.c:40 #6 0x000000000058c21a in lutil_debug (debug=<optimized out>, level=level@entry=1, fmt=fmt@entry=0x59c7a6 ">>> dnPretty: <%s>\n") at debug.c:81 #7 0x000000000044c792 in dnPretty (syntax=syntax@entry=0x8c4810, val=val@entry=0x7ffbe9cf9d00, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at dn.c:539 #8 0x000000000046c614 in nameUIDPretty (syntax=0x8c4810, val=0x7ffbd9845600, out=0x7ffbe9cf9de0, ctx=0x0) at schema_init.c:1350 #9 0x000000000045383d in ordered_value_pretty (ad=ad@entry=0xa40470, val=0x7ffbd9845600, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at value.c:511 #10 0x000000000044f676 in slap_mods_check (op=op@entry=0x7ffbe9cfa510, ml=0x7ffbd992c410, text=text@entry=0x7ffbe9cf9f60, textbuf=textbuf@entry=0x7ffbe9cfa180 "H\034\032\330\373\177", textlen=textlen@entry=256, ctx=ctx@entry=0x0) at modify.c:575 #11 0x0000000000492e10 in syncrepl_message_to_entry (syncUUID=0x7ffbe9cf9f40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbe9cfa320, msg=<optimized out>, op=0x7ffbe9cfa510, si=0xa3fb20) at syncrepl.c:2715 #12 do_syncrep2 (op=op@entry=0x7ffbe9cfa510, si=si@entry=0xa3fb20) at syncrepl.c:1043 #13 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa40060) at syncrepl.c:1571 #14 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #15 0x00007ffff754cdd5 in start_thread (arg=0x7ffbe9cfb700) at pthread_create.c:307 #16 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbeb7fcc10 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbd576fee7 "0\027\004\002cn1\021\004\017CSC User Access0-\004\025structuralObjectClass1\024\004\022groupOfUniqueNames03\004\tentryUUID1&\004$13257271-b706-49bc-a2a9-a5f3e7f4a0dd0L\004\fcreatorsName1<\004:cn={REDACTED}”…, len=len@entry=61665) at bprint.c:202 #5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:276 #6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:247 #7 0x00000000005894c1 in ber_scanf (ber=0x7ffbd4319130, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723 #8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbeb7fcf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbeb7fd320, msg=<optimized out>, op=0x7ffbeb7fd510, si=0xa3f3b0) at syncrepl.c:2658 #9 do_syncrep2 (op=op@entry=0x7ffbeb7fd510, si=si@entry=0xa3f3b0) at syncrepl.c:1043 #10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3f8b0) at syncrepl.c:1571 #11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbeb7fe700) at pthread_create.c:307 #13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbebe6cf20 " b6c6: 03 0a 01 04 30 22 02 03 02 38 56 17 0d 31 38 30 ....0\"...8V..180 \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbe04282a0 "0\203UK\275\002\001\001d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202 #5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175 #6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe17f55b0, ber=ber@entry=0x7ffbebe6d0f0, freeit=freeit@entry=0) at io.c:240 #7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe41bd940, ber=ber@entry=0x7ffbebe6d0f0) at result.c:339 #8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe41bd940, rs=<optimized out>) at result.c:1430 #9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbebffeaa0) at search.c:1085 #10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #11 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #13 0x000000000043c33f in fe_op_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:402 #14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #15 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #17 0x000000000043bef6 in do_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:247 #18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbebffebd0, arg_v=arg_v@entry=0x7ffbe41bd940) at connection.c:1158 #19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbebffebd0, argv=<optimized out>) at connection.c:1294 #20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbebfff700) at pthread_create.c:307 #22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422 #1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090 #2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237 #3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508 #4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583 #5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861 #6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558 #7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211 #11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251 #12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677 #13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402 #16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247 #20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158 #21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307 #23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6 #2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39 #3 0x000000000058bbc6 in ber_error_print (data=0x7ffbf102af20 " e54c: 33 5a 30 0c 30 0a 06 03 55 1d 15 04 03 0a 01 04 3Z0.0...U....... \n") at bprint.c:87 #4 0x000000000058be41 in ber_bprint (data=0x7ffbe42cc110 "0\203UK\275\002\001\021d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202 #5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175 #6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe422daa0, ber=ber@entry=0x7ffbf102b0f0, freeit=freeit@entry=0) at io.c:240 #7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe42197b0, ber=ber@entry=0x7ffbf102b0f0) at result.c:339 #8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe42197b0, rs=<optimized out>) at result.c:1430 #9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbf11bcaa0) at search.c:1085 #10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677 #11 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #13 0x000000000043c33f in fe_op_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:402 #14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677 #15 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #17 0x000000000043bef6 in do_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:247 #18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbf11bcbd0, arg_v=arg_v@entry=0x7ffbe42197b0) at connection.c:1158 #19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbf11bcbd0, argv=<optimized out>) at connection.c:1294 #20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696 #21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf11bd700) at pthread_create.c:307 #22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff674d603 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 #1 0x000000000043618b in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2539 #2 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf19be700) at pthread_create.c:307 #3 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 #0 0x00007ffff754df47 in pthread_join (threadid=140720067045120, thread_return=thread_return@entry=0x0) at pthread_join.c:90 #1 0x00000000005642b8 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197 #2 0x0000000000437766 in slapd_daemon () at daemon.c:2932 #3 0x0000000000420b84 in main (argc=<optimized out>, argv=0x7fffffffe408) at main.c:1017 The above trace seems to suggest the source of the segfault is coming from the ldap_chain_op function at chain.c:422. We use chain forwarding for ppolicy operations on the consumers. This is the line: for ( ; !BER_BVISNULL( ref ); ref++ ) { BER_BVISNULL is not a function but a macro which is defined (lber_pvt.h:216) as follows: #define BER_BVISNULL(bv) ((bv)->bv_val == NULL) The above seems suggests that ref is set to null at the time of the check. When I double checked my chain configs I noticed there was an entry that did not contain the olcDbURI attribute that I did not create. It seems that this particular entry was created by the cn=config conversion for the following slapd.conf configuration: Overlay chain chain-proxy-whoami yes chain-uri {REDACTED URI 1} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 chain-uri {REDACTED URI 2} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 chain-uri {REDACTED URI 3} Chain-cache-uri FALSE Chain-max-depth 1 Chain-return-error TRUE Chain-idassert-bind bindmethod=“simple” binddn={REDACTED} credentials={REDACTED} Chain-protocol-version 3 After the conversion to cn=config: dn: olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {1}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: ldaps starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: “{REDACTED URI 1}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={2}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {2}ldap olcDbURI: “{REDACTED URI 2}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={3}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {3}ldap olcDbURI: “{REDACTED URI 3}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 I am wondering if the following is causing the segfaults: When setting up the configs during the slapd.d conversion, the slapd.conf -> cn=config converter added an extra unnecessary entry for the chain config (there are 4 ldap proxy entries instead of 3). This particular entry that was added does not have an olcDbURI value. Since the referral string is set by the olcDbURI attribute value the missing value results in NULL being set for ref. However, I have not yet been able to manually trigger the segfault by invoking ppolicy. I also found a red hat ticket that seemd to detail the same issue (see https://bugzilla.redhat.com/show_bug.cgi?id=1644654). Any ideas on this? I can also obtain a trace of all the threads if needed. Jeremy -- Jeremy Diaz Rex Consulting, Inc 5652 Florence Terrace, Oakland, CA 94611 email: jeremy.diaz(a)rexconsulting.net web: [ http://www.rexconsulting.net/ | http://www.rexconsulting.net ] phone, toll-free: +1 (888) 403-8996 EXT: 5 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. has been a California Corporation since 2001.

2 1

what the error "ldap_sasl_interactive_bind_s: Unknown authentication method (-6)" means?
by Peter Sui 13 Jan '20

13 Jan '20

I'm trying to test SASL EXTERNAL to an AD server, which saying support EXTERNAL. the command I ran is: ldapwhoami -H ldap://example.com:389 -YEXTERNAL but it returned: ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: what does this error message mean? I already installed the necessary package, here is my dpkg return: ~$ dpkg -l | grep sasl ii libauthen-sasl-perl 2.1600-1 all Authen::SASL - SASL Authentication framework ii libsasl2-2:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - authentication abstraction library ii libsasl2-dev 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - development files for authentication abstraction library ii libsasl2-modules:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules ii libsasl2-modules-db:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules (DB) ii libsasl2-modules-gssapi-mit:amd64 2.1.27~101-g0780600+dfsg-3ubuntu2 amd64 Cyrus SASL - pluggable authentication modules (GSSAPI) and I can run ldapwhoami with SASL GSSAPI against the above mentioned AD server successfully. the error seems the "EXTERNAL" is not even supported, is not about invalid credential. I also tried to created a new certificate with the server credential, and modified the .ldaprc to point to the new certificate. still does not work. who can tell me how ? Thanks ahead! Peter

4 4

Replication of olcAccess
by Stefan Kania 13 Jan '20

13 Jan '20

Hello, I try to replicate the olcAccess, olcLimits and olcDbIndex Attributes here is the Database where the olcx Attributes located on the Master ---------------- dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to dn.exact="" by * read olcAccess: {1}to attr=entry,uid by anonymous auth by * break ... ---------------- I created an ldif to add there olcSyncrepl to the slave: ---------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=001 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="olcDatabase={1}mdb,cn=config" attrs="olcAccess,olcLimits,olcDbIndex" bindmethod=simple binddn="cn=admin,cn=config" credentials=***** ---------------- When I try to add it to my config i always get: ---------------- root@ldapserver-02:/daten# ldapmodify -Y EXTERNAL -H ldapi:/// -f sync-config.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={1}mdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: Base DN "olcDatabase={1}mdb,cn=config" is not within the database naming context ---------------- Here are all dn-entries from the master: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config dn: olcDatabase={2}mdb,cn=config ---------------- And from the slave: ---------------- dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}kerberos,cn=schema,cn=config dn: cn={5}sshkey,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config ---------------- What do I have to put into the "searchbase"? Replication of the object-DB is working. But I want the ACLs to be replicated too. Here is the ldif-file I used to set up the object-db replication --------------- dn: olcDatabase={1}mdb,cn=config changetype: modify add:olcSyncrepl olcSyncrepl: rid=000 provider=ldap://ldapserver.example.net type=refreshandpersist retry="60 10 120 5" searchbase="dc=example,dc=net" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=admin,dc=example,dc=net" credentials=***** --------------- thank's for any help Stefan

4 9

structural objectclass checking
by Markus.Storm＠t-systems.com 11 Jan '20

11 Jan '20

Hi, is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL objectclasses? I know it's illegal per standard to have either no or multiple objectclasses of STRUCTURAL type on an entry. Unfortunately in the enterprise world it is very common that you have to deal with existing data which is even beyond your control. Our LDAP is full of such 'bad' records, making imports into OpenLDAP fail for 50% of our entries. I'm trying to present OpenLDAP as an alternative to the commercial LDAP software my company is currently running but I need to come up with a solution to this in order to convince our managers and engineering. Competition such as Oracle Unified Dir have an option to selectively disable this type of checking. Is there a way to do it in OpenLDAP via config? If no, would it be rather easy or hard to add that to the code myself ? I once made a similar patch but it had to be applied in a single location within the source only. Thanks Best regards Markus

5 6

Re: ldapsearch utility
by Peter Sui 08 Jan '20

08 Jan '20

Hi Quanah, Thanks for your response, another question about the SASL. I know for the ldap server, some settings must be done, what about for the client side? If I only installed the open ldap library and client tools, and if I want to use SASL GSSAPI, will this be enough ? do I need to install other modules like Kerberos V? Thank you in advance! Peter On Tue, Jan 7, 2020 at 2:15 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, January 7, 2020 7:49 AM -0500 Peter Sui <peters(a)qnext.com> > wrote: > > so question here, what password it asked here? since it's not asking for > > a DN. There could be many credentials here, will the server figure out > > the user by the password input? > > Hi Peter, > > The OpenLDAP admin guide specifically discusses in detail how to set up > and > configure SASL/DIGEST-MD5. Please see > <https://www.openldap.org/doc/admin24/sasl.html#DIGEST-MD5> > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Re: Openldap support SHA-256 or SHA-3.
by Quanah Gibson-Mount 08 Jan '20

08 Jan '20

--On Tuesday, January 7, 2020 10:44 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > Does openldap support SHA-256 or SHA-3 schemes? to address the below > issues? There is a module in contrib that is included with most vendor builds that allows up to SSHA512. I've long suggested using it. The default of SSHA1 is mandated by RFC (which IMHO needs updating at this point). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 3

Re: Openldap support SHA-256 or SHA-3.
by Giuseppe De Marco 08 Jan '20

08 Jan '20

This Is quite cute, https://github.com/P-H-C/phc-winner-argon2 Regards Il mer 8 gen 2020, 03:08 Quanah Gibson-Mount <quanah(a)symas.com> ha scritto: > > > --On Tuesday, January 7, 2020 11:25 PM +0100 Michael Ströder > <michael(a)stroeder.com> wrote: > > > AFAICS RFC 3112 was never implemented in OpenLDAP. Thus I'd consider > > this to be rather irrelevant here. > > Incorrect, it's clearly implemented in slapd. Whether it's enabled is a > different question, as it's IFDEF'd behind SLAPD_AUTHPASSWD. ;) > > In any case, I've been advocating for several years now to get rid of SSHA > as the default hashing mechanism and replace it with something that may > actually have some security value. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Openldap support SHA-256 or SHA-3.
by Giuseppe De Marco 07 Jan '20

07 Jan '20

Ho I made SSHA512 as default this way dn: olcDatabase={-1}frontend,cn=config replace: olcPasswordHash olcPasswordHash: SSHA512 EOF Once pw-sha2 module was loaded https://github.com/peppelinux/ansible-slapd-eduperson2016/blob/master/roles… Il mar 7 gen 2020, 21:24 Quanah Gibson-Mount <quanah(a)symas.com> ha scritto: > > > --On Tuesday, January 7, 2020 11:52 AM -0800 rammohan ganapavarapu > <rammohanganap(a)gmail.com> wrote: > > > > > Quanah, > > > > > > Thanks for the quick reply, is there any plans to make SSHA512 default? > > No. As I said, SHA1 is mandated by RFC. > > > also is there any migration steps to move from SHA-1 to SSHA512 ? > > After deploying the sha2 module, all users must change their password so > the hash gets updated. There is no way to magically convert existing > hashes from SSHA1 to another scheme. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: ldapsearch utility
by Peter Sui 07 Jan '20

07 Jan '20

Hi Quanah, Thank you for your response. I figured what you said in your response, and I have another question about the SASL. I have a ldap testing server, let's say the url is test.sample.net, and when I run the following command: ldapsearch -H ldap://test.sample.net:389 -x -b "" -s base -LLL supportedSASLMechanisms it returned: dn: supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: NTLM then I run the command: ldapsearch -H ldap://test.sample.net:389 -Y DIGEST-MD5 then it prompt: SASL/DIGEST-MD5 authentication started Please enter your password: I give a password, then it prompt: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): user not found: no secret in database so question here, what password it asked here? since it's not asking for a DN. There could be many credentials here, will the server figure out the user by the password input? Thank you! Peter On Mon, Jan 6, 2020 at 8:17 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, December 31, 2019 10:44 AM -0500 Peter Sui <peters(a)qnext.com> > > wrote: > > > if I run: > > ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)" > -D > > "cn=read-only-admin,dc=example,dc=com" -w password -Z > > It is not valid to combine startTLS with port 636. Also, you should > update > your options to match modern standards. > > > Example against ldaps:/// > > ldapsearch -H ldaps://ldap.forumsys.com:636 > > as opposed to > > ldapsearch -h ldap.forumsys.com -p 636 > > Example against ldap:/// > > ldapsearch -H ldap://ldap.forumsys.com:389 > > as opposed to > > ldapsearch -h ldap.forumsys.com -p 389 > > > I would note that the -Z(Z) options are for startTLS (generally against > port 389). It is not valid to mix startTLS with ldaps:// URIs. You've > not > provided any useful information about your setup, so it's not possible to > give you much help past that. > > As for your SASL question, as documented in the ldapsearch man page, you > provide the SASL Mech as a parameter to the -Y option. For example: > > ldapsearch -Y GSSAPI -H ldap://ldap.forumsys.com:389 > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

RE: ldapsearch utility
by Peter Sui 07 Jan '20

07 Jan '20

Hi, I'm trying to use ldapsearch to do some tests, lets say the testing ldap server host is: ldap.forumsys.com , test 1: if I run: ldapsearch -h ldap.forumsys.com -p 389 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password it seems successful, but if I add ssl flag, like run: ldapsearch -h ldap.forumsys.com -p 389 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password -Z I got error: ldap_start_tls: Connect error (-11) additional info: (unknown error code) ldap_result: Can't contact LDAP server (-1) if I run: ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)" -D "cn=read-only-admin,dc=example,dc=com" -w password -Z I got error: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) so how can I do a search with ssl? test 2: this is about SASL authentication. Lets say the SASL mech is DIGEST-MD5, or EXTERNAL, or GSSAPI, what ldapsearch command should I run? I tried many, it did not work. Thanks! Peter Sui

2 1

please repost link to question "How to build OpenLDAP against specific OpenSSL install"
by Dunne, Kenneth 07 Jan '20

07 Jan '20

I found this, but get a 404 error following it: >The new OpenSSL 1.0.1e header files are located under /usr/local/include/openssl and the >libs are in /usr/local/lib64. <https://github.com/Zimbra-Community/zimbra-sources/blob/master/main/ThirdPa…> --Quanah

2 1

Issues with OpenLdap using OpenTLS
by Dunne, Kenneth 04 Jan '20

04 Jan '20

All I am able to connect to my home-built OpenSSL installation (from Dec-19 sources) on CentOS-7 without the TLS bind. I am now trying to use OpenTLS with OpenSSL, which is not currently working. From searching the internet I find this, Which indicates that maybe RH-based-unixes have unique issues with OpenTLS/OpenLdap: https://serverfault.com/questions/437546/centos-openldap-cert-trust-issues My slapd.conf now holds (as differs from the default installed slapd.conf) ... snip... ############### TLS # added per http://www.openldap.org/faq/data/cache/185.html TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /usr/local/etc/openldap/servercrt.pem TLSCertificateKeyFile /usr/local/etc/openldap/serverkey.pem TLSCipherSuite DES-CBC3-SHA ... snip... And my ldap.conf holds: ... snip... ############### TLS ############### TLS # added per http://www.openldap.org/faq/data/cache/185.html TLS_CACERT /etc/pki/tls/certs/ca-bundle.crt ### fails: ## TLS_CACERT /usr/local/etc/openldap/ cacert.pem URI ldaps://localhost:636 ############### TLS ... snip... .... Having added the 'cacert.pem' into the file " /etc/pki/tls/certs/ca-bundle.crt" I get farther in the authentication than using "/usr/local/etc/openldap/ cacert.pem": [root@kdunne-dev openldap]# /usr/local/bin/ldapsearch -Z -D "cn=Manager,dc=my-domain,dc=com" -d -1 ldap_create ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect errno: 111 ldap_close_socket: 3 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before/connect initialization tls_write: want=289, written=289 0000: 16 03 01 01 1c 01 00 01 18 03 03 51 03 78 81 fc ...........Q.x.. 0010: 66 89 9c 91 10 b6 e9 3d f1 12 66 27 c7 f5 80 e4 f......=..f'.... 0020: fb f6 5f 9d f8 bb 37 3b 84 cb 17 00 00 ac c0 30 .._...7;.......0 0030: c0 2c c0 28 c0 24 c0 14 c0 0a 00 a5 00 a3 00 a1 .,.(.$.......... 0040: 00 9f 00 6b 00 6a 00 69 00 68 00 39 00 38 00 37 ...k.j.i.h.9.8.7 0050: 00 36 00 88 00 87 00 86 00 85 c0 32 c0 2e c0 2a .6.........2...* 0060: c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 2f .&.......=.5.../ 0070: c0 2b c0 27 c0 23 c0 13 c0 09 00 a4 00 a2 00 a0 .+.'.#.......... 0080: 00 9e 00 67 00 40 00 3f 00 3e 00 33 00 32 00 31 ...g.@.?.>.3.2.1 0090: 00 30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 .0.........E.D.C 00a0: 00 42 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c .B.1.-.).%...... 00b0: 00 3c 00 2f 00 96 00 41 c0 12 c0 08 00 16 00 13 .<./...A........ 00c0: 00 10 00 0d c0 0d c0 03 00 0a 00 07 c0 11 c0 07 ................ 00d0: c0 0c c0 02 00 05 00 04 00 ff 01 00 00 43 00 0b .............C.. 00e0: 00 04 03 00 01 02 00 0a 00 0a 00 08 00 17 00 19 ................ 00f0: 00 18 00 16 00 23 00 00 00 0d 00 20 00 1e 06 01 .....#..... .... 0100: 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 ................ 0110: 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 ................ 0120: 01 . TLS trace: SSL_connect:SSLv2/v3 write client hello A tls_read: want=7, got=0 TLS: can't connect: . ldap_err2string ldap_start_tls: Can't contact LDAP server (-1) ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Additionally: I am reading the FAQ http://www.openldap.org/faq/data/cache/185.html to generate the certs but am wondering if I am correctly understanding the instruction "Remember that the Common Name for this cert should be the fully qualified domain name of the server:" If I run my ldap server as: /usr/local/libexec/slapd -F /usr/local/etc/openldap/slapd.d -h 'ldaps://127.0.0.1:636 ldap://127.0.0.1:389' -d -1 Then would the 'common name' for use in the certificate be: cn=localhost:636 Any assistance is greatly appreciated. Thanks! Ken Dunne

4 5

RE: mdb_stat() crashes under DB_STALE
by Peter Zhu (pezhu) 02 Jan '20

02 Jan '20

Hi, Quanah Thanks for your info. I am forwarding my info to the mailing-list. Cheers, Peter From: Quanah Gibson-Mount <quanah.gibsonmount(a)gmail.com> Sent: Thursday, January 2, 2020 12:18 PM To: Peter Zhu (pezhu) <pezhu(a)cisco.com> Subject: Re: mdb_stat() crashes under DB_STALE I would advise you use the correct methods for asking for assistance. I would start with the openldap-technical mailing list (https://www.openldap.org/lists/) Regards, Quanah On Mon, Dec 23, 2019 at 3:18 PM Peter Zhu (pezhu) <pezhu(a)cisco.com<mailto:pezhu@cisco.com>> wrote: Hi, Folks I am using LMDB 9.24, and have experienced the following crashes: warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/ngfw/usr/local/sf/bin/sfhassd -c /etc/sf/sfhassd.conf'. Program terminated with signal SIGSEGV, Segmentation fault. #0 mdb_node_search (mc=mc@entry=0x2b794dbf7320, key=0x560ed4785f30, exactp=exactp@entry=0x2b794dbf730c) at mdb.c:5322 5322 mdb.c: No such file or directory. [Current thread is 1 (LWP 12824)] (gdb) (gdb) bt #0 mdb_node_search (mc=mc@entry=0x2b794dbf7320, key=0x560ed4785f30, exactp=exactp@entry=0x2b794dbf730c) at mdb.c:5322 #1 0x00002b792c57c79f in mdb_page_search (mc=0x2b794dbf74e0, key=key@entry=0x0, flags=flags@entry=2) at mdb.c:5617 #2 0x00002b792c57c960 in mdb_cursor_init (mc=mc@entry=0x2b794dbf74e0, txn=txn@entry=0x2b79600332c0, dbi=dbi@entry=5, mx=mx@entry=0x2b794dbf7670) at mdb.c:7623 #3 0x00002b792c58713d in mdb_stat (txn=0x2b79600332c0, dbi=5, arg=0x2b794dbf7a10) at mdb.c:9856 #4 0x00002b792c798c17 in LMDBCache::GetMstByType (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, mst=0x2b794dbf7a10, idx=CACHE_TABLE_FIFO) at lmdbCache.cpp:1408 #5 0x00002b792c7946df in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key=0x2b794dbf7b60, data=0x2b794dbf7d00, idx=CACHE_TABLE_FIFO, asyncWrite=0) at lmdbCache.cpp:820 #6 0x00002b792c795aae in LMDBCache::InsertFiFoKeyValue (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, appKey=0x2b794dbf7d00) at lmdbCache.cpp:1007 #7 0x00002b792c795143 in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key=0x2b794dbf7d00, data=0x2b794dbf7cf0) at lmdbCache.cpp:907 #8 0x00002b792c7957c4 in LMDBCache::InsertKeyValuePair (this=0x560ed4782fb0, type=SSL_CACHE_ORIG_CERT, key_=0x2b7960033abe "37364826527", value=0x2b7960033ada "moredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredead"...) at lmdbCache.cpp:953 #9 0x00002b792c79a228 in lmdb_insert_to_cache (type=3, key=0x2b7960033abe "37364826527", value=0x2b7960033ada "moredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredeadbeefmoremoredead"...) at lmdbCacheCWrapper.cpp:38 #10 0x0000560ed2c37155 in LocalInputThread (thread_handle=thread_handle@entry=0x2b79600008c0, arg=arg@entry=0x2b7950000b40) at local.c:473 #11 0x0000560ed2c38aa2 in _threadlist_create_stub (arg=0x2b794d3f3cc0) at ThreadList.c:174 #12 0x00002b792b8243d4 in ?? () from /lib64/libpthread.so.0 #13 0x00002b792ca8791d in clone () from /lib64/libc.so.6 Can you folks let me know if you can help. Or please forward my email to Howard Chu. Thanks and have Happy Holidays. Peter

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2020