- openldap-technical - openldap.org

Re: 2.4.45 slapadd segfault
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Thursday, August 31, 2017 4:49 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > Christopher Wood wrote: >> Good morning, long time no list. >> >> For backstory, I downloaded the 2.4.45 source tarball from >> https://www.openldap.org/software/download/, compiled, ran "make test" >> (which was fine as near as I can tell), but doing a slapadd of cn=config >> caused a segfault. >> >> I used the points on http://www.openldap.org/faq/data/cache/59.html to >> create the following backtrace: >> >> https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e >> >> And this is the ldif (temporary password is fakepass333): >> >> https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e >> >> Does anything jump out at you as obviously wrong or a good place to >> look? I've chopped the ldif down from the original with confidential >> data and am still reducing, but it's still segfaulting. > > Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if > it's still not obvious to you. > > Granted it shouldn't SEGV but the backtrace shows it was shutting itself > down already because it (correctly) rejected your input. There are a number of errors with that LDIF file, outside of what Howard already pointed out. ;) The objects in 54 & 62 are also missing their RDN as a value too. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: 2.4.45 slapadd segfault
by Howard Chu 31 Aug '17

31 Aug '17

Christopher Wood wrote: > Good morning, long time no list. > > For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. > > I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: > > https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e > > And this is the ldif (temporary password is fakepass333): > > https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e > > Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. Yes. Look at your LDIF line 62 more carefully. Compare it to line 65 if it's still not obvious to you. Granted it shouldn't SEGV but the backtrace shows it was shutting itself down already because it (correctly) rejected your input. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

2.4.45 slapadd segfault
by Christopher Wood 31 Aug '17

31 Aug '17

Good morning, long time no list. For backstory, I downloaded the 2.4.45 source tarball from https://www.openldap.org/software/download/, compiled, ran "make test" (which was fine as near as I can tell), but doing a slapadd of cn=config caused a segfault. I used the points on http://www.openldap.org/faq/data/cache/59.html to create the following backtrace: https://gist.github.com/christopherwood/701fbc70ef352a3bf2d2893a9ae0a65e And this is the ldif (temporary password is fakepass333): https://gist.github.com/christopherwood/2cf46f5a3384f9edc89e7eabbefc465e Does anything jump out at you as obviously wrong or a good place to look? I've chopped the ldif down from the original with confidential data and am still reducing, but it's still segfaulting. More details: OpenLDAP 2.4.45 Release (2017/06/01) [root@poc209 ~]# uname -a Linux poc209 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [root@poc209 ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core) / and /var are ext4. Configure was like this, albeit on one line: ./configure --enable-debug --enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local --enable-slapd --enable-dynacl --enable-aci --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --disable-slp --enable-wrappers --enable-backends=mod --enable-bdb=yes --enable-hdb=yes --enable-mdb=yes --enable-monitor=yes --disable-ndb --enable-overlays=mod --disable-static --enable-shared --with-cyrus-sasl --without-fetch --with-threads --with-pic --with-tls=openssl --with-gnu-ld --prefix=/opt/openldap

1 0

Re: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
by Quanah Gibson-Mount 31 Aug '17

31 Aug '17

--On Wednesday, August 30, 2017 3:51 PM +0200 Sven Mäder <maeder(a)phys.ethz.ch> wrote: > SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is > newer than provider! This would generally indicate that the accesslog DB was empty at startup, and it generated a new CSN. This is a general problem with delta-syncrepl -- If the accesslog DB goes empty, there are a host of issues that can ensue (See ITS#8100 for example). Generally you need a script that writes a change on all masters in your cluster on a regular interval so that the DB is never purged, and there is always an active contextCSN value that's stored in the DB for each serverID. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Removing Berkeley DB Log Files
by Douglas Duckworth 31 Aug '17

31 Aug '17

Thanks for the reply, Howard. Thanks for pointing me in the right direction. From what I have read there are two options. 1) Copy /usr/share/openldap-servers/DB_CONFIG.example to /var/lib/domain then rebuild the database. 2) Enable checkpointing in slapd.conf Does enabling checkpointing in slapd.conf require rebuilding the database or can I simply restart slapd.conf? We are not using online configuration. Best Doug Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Fri, Aug 25, 2017 at 8:55 AM, Howard Chu <hyc(a)symas.com> wrote: > Douglas Duckworth wrote: > > Hi > > > > I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos > 6.9. My > > /var/lib/ldap directory contains many 10MB log files. /var partition > rather > > small... > > > > I've read they can be removed either by running "sudo db_archive -d -h > > /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file > > "DB_CONFIG." That file does not presently exist whereas the db_archive > > command does not actually remove any of the log files. > > If the db_archive command doesn't remove anything, that means it thinks > all of > the log files are still in active use. > > Read the docs more carefully. > https://urldefense.proofpoint.com/v2/url?u=http-3A__docs. > oracle.com_cd_E17076-5F05_html_programmer-5Freference_ > transapp-5Flogfile.html&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > Kfi27b4v7vABZjPQYMkeo4xBqUyDGZeyB8pHAFin8xY&e= > > > > > Can I remove the old log files manually using rm? > > Not if the above is true, you will corrupt the logs and the DB will fail to > open on a subsequent restart. > > > If not should I create > > /var/lib/ldap/DB_CONFIG then restart slapd to make this removal > automatic? > > > Do you have any idea why db_archive does not work or produce any helpful > error > > to stdout? > > There's no error message because there's no error, everything is working as > designed. > > You need to do periodic checkpoints to allow log files to be closed, and > then > db_archive will be able to remove some of them. > > -- > -- Howard Chu > CTO, Symas Corp. https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.symas.com&d=DwICaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=IT7tNF72SCugdO8WpRd- > oNsk4nPNpdjE2aUFL4R4X_M&e= > Director, Highland Sun https://urldefense.proofpoint. > com/v2/url?u=http-3A__highlandsun.com_hyc_&d=DwICaQ& > c=lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s= > XqfYCnjG9ibPbeW05QZOlWdl9u0ZH-7IXkxx0gh238k&e= > Chief Architect, OpenLDAP https://urldefense.proofpoint. > com/v2/url?u=http-3A__www.openldap.org_project_&d=DwICaQ&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=WP95x8mwSiEHHqUWRqJv6WdpfcTtJDAUAKN756yEEDA&s=- > tGdeTJRpeaRbljBBUq49XgfNWzVElqiGEgv0LeqspU&e= >

2 5

Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 30 Aug '17

30 Aug '17

--On Wednesday, August 30, 2017 1:03 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Yeah, that worked. You might find <https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_5.0#Configuring_th…> useful as well as a guideline on how to tune BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: pwdfailuretime with multi-sync
by Quanah Gibson-Mount 30 Aug '17

30 Aug '17

--On Wednesday, August 30, 2017 2:49 PM +0800 Chris Leung <chris(a)q-station.net> wrote: > Sometime, the user password is replicated without problem after switched > to REFRESH, however, sometime password can't be sync. Error 16 means "no such attribute exists". My guess would be you have ACLs that block your replica from replicating userPassword. I'd also guess that you originally loaded the replica via a slapcat of the other master, so some accounts have passwords, and others don't. This is all guesswork of course, but it would match the behavior you're seeing. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

pwdfailuretime with multi-sync
by Chris Leung 30 Aug '17

30 Aug '17

Dear all, I have 2 openldap (2.4.42+dfsg-2ubuntu3.2) bundled with Ubuntu 16 LTS running multi-master mode. The data could be replicated to each other without problem, excpect when updating user password thru admin user. If user entry with pwdFailureTime, then the sync will be fail to REFRESH mode e.g, logged: Aug 29 10:35:41 openldap2 slapd[5277]: do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: slap_queue_csn: queueing 0x7f849c1049ce 20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: null_callback : error code 0x10 Aug 29 10:35:41 openldap2 slapd[5277]: slap_graduate_commit_csn: removing 0x7f849c104b80 20170829023541.693544Z#000000#001#000000 Aug 29 10:35:41 openldap2 slapd[5277]: syncrepl_message_to_op: rid=001 be_modify uid=xxxxxx.... (16) Aug 29 10:35:41 openldap2 slapd[5277]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170829023541.000002Z,cn=xxxxxx), switching to REFRESH Sometime, the user password is replicated without problem after switched to REFRESH, however, sometime password can't be sync. When I google the problem, it seem the incidence is report as http://www.openldap.org/lists/openldap-technical/201304/msg00195.html I would like to know any advise on the issue? Thanks. Chris

1 0

Re: Antw: Re: RedHat dropping OpenLDAP server support
by Quanah Gibson-Mount 29 Aug '17

29 Aug '17

--On Tuesday, August 29, 2017 9:54 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Hi! > > I don't know what Redhat is thinking, but obviously too many users had > problems with OpenLDAP, so they dropped support of it ;-) BTW: Redhat > also dropped support for BtrFS by not including it any longer (is what I > read)... There is a good article somewhere discussing why RH is dropping BtrFS. As for RedHat, I would hazard two reasons: Money and control For the first, RHDS requires a subscription, so having people move to it brings RedHat more money. For the second, RedHat clearly has control of the RHDS & 389 projects, and doesn't have to deal with other developers who may not be fond of their proposed changes, such as the debacle of the MozNSS support for OpenLDAP that caused numerous issues. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: delta syncrepl errors
by Quanah Gibson-Mount 29 Aug '17

29 Aug '17

--On Tuesday, August 22, 2017 12:36 PM +0200 Gerard Ranke <gerard.ranke(a)hku.nl> wrote: > 2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001 > got search entry without Sync State control > (reqStart=20170815125023.000001Z,cn=accesslog) You appear to be missing the syncprov overlay from the accesslog DB. I would suggest revisting the configuration on your master. Both the primary database and the accesslog database require having syncprov present, with different options set. It should be something along the lines of: dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE as can be found in test063 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: RedHat dropping OpenLDAP server support
by Howard Chu 29 Aug '17

29 Aug '17

Robert Heller wrote: > At Mon, 28 Aug 2017 11:44:27 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > >> >> Hello All, >> >> As noted in the RHEL7.4 release notes >> (<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht…>), >> RedHat will no longer support OpenLDAP Server starting with RHEL8. > > Will RedHat be supporting an alternitive Lightweight Directory Access Protocol > server? Or is RedHat dropping all sopport for Lightweight Directory Access > Protocol servers? RedHat is supporting their commercial server, RedHat Directory Server. It's the commercial version of 389DS, derived from the old Netscape LDAP server. Worth noting that that lineage of code has been abandoned by everyone else (e.g. Sun/Oracle DSEE has also been EOL'd). > >> >> This is likely a good time to start planning your migration plans if you >> currently rely on RedHat's build of OpenLDAP. I would note that Symas >> provides certified builds for OpenLDAP with various support options >> available. An alternative for those who do not require support and do not >> wish to build OpenLDAP themselves would be to use the LTB project builds. >> >> Regards, >> Quanah >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: RedHat dropping OpenLDAP server support
by Douglas Duckworth 28 Aug '17

28 Aug '17

They want you to buy their identity management server which is based upon 389 directory server. Or you could go with freeipa https://www.freeipa.org/page/Main_Page Will this change also affect centos? Doug Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Mon, Aug 28, 2017 at 4:19 PM, Robert Heller <heller(a)deepsoft.com> wrote: > At Mon, 28 Aug 2017 11:44:27 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > > > Hello All, > > > > As noted in the RHEL7.4 release notes > > (<https://urldefense.proofpoint.com/v2/url?u=https- > 3A__access.redhat.com_documentation_en-2DUS_Red- > 5FHat-5FEnterprise-5FLinux_7_html_7.4-5FRelease-5FNotes_ > chap-2DRed-5FHat-5FEnterprise-5FLinux-2D7.4-5FRelease- > 5FNotes-2DDeprecated-5FFunctionality.html-23idp12778832&d=DwIBAg&c= > lb62iw4YL4RFalcE2hQUQealT9-RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e- > CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P-9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6 > lhNQAiY&s=rcOr9W4Z0-adDX11ERL8Oq5r0dEwVwaS9V-qnhKeslA&e=>), > > RedHat will no longer support OpenLDAP Server starting with RHEL8. > > Will RedHat be supporting an alternitive Lightweight Directory Access > Protocol > server? Or is RedHat dropping all sopport for Lightweight Directory Access > Protocol servers? > > > > > This is likely a good time to start planning your migration plans if you > > currently rely on RedHat's build of OpenLDAP. I would note that Symas > > provides certified builds for OpenLDAP with various support options > > available. An alternative for those who do not require support and do > not > > wish to build OpenLDAP themselves would be to use the LTB project builds. > > > > Regards, > > Quanah > > > > -- > > > > Quanah Gibson-Mount > > Product Architect > > Symas Corporation > > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P- > 9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6lhNQAiY&s=oU0KzuQoUpgOc_GP- > Td3CN9qNf1XHk2_Z2zUALSywxg&e=> > > > > > > > > -- > Robert Heller -- 978-544-6933 > Deepwoods Software -- Custom Software Services > https://urldefense.proofpoint.com/v2/url?u=http-3A__www. > deepsoft.com_&d=DwIBAg&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m=-nX2P- > 9jJkqd2VhDD2sJ3alWs9cDEp6jpNb6lhNQAiY&s=s5sTP_ > 3py5Bv17Mc1dePXqoepTBDYF9TXZuokHV3Thw&e= -- Linux Administration Services > heller(a)deepsoft.com -- Webhosting Services > > >

1 0

RedHat dropping OpenLDAP server support
by Quanah Gibson-Mount 28 Aug '17

28 Aug '17

Hello All, As noted in the RHEL7.4 release notes (<https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ht…>), RedHat will no longer support OpenLDAP Server starting with RHEL8. This is likely a good time to start planning your migration plans if you currently rely on RedHat's build of OpenLDAP. I would note that Symas provides certified builds for OpenLDAP with various support options available. An alternative for those who do not require support and do not wish to build OpenLDAP themselves would be to use the LTB project builds. 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: DB Indexing
by Quanah Gibson-Mount 28 Aug '17

28 Aug '17

--On Saturday, August 26, 2017 2:18 PM +0000 openldap.org(a)jrogers.org wrote: > In other words, does OpenLDAP consider them both options to be the same, > where each (uidNumber and gidNumber) are indexed separately into separate > indices? The same, indexed separately. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

DB Indexing
by openldap.org＠jrogers.org 26 Aug '17

26 Aug '17

To Whom It May Concern: Is there a difference in indexing between the following two OLC config options: Option 1: olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq Option 2: olcDbIndex: uidNumber,gidNumber eq In other words, does OpenLDAP consider them both options to be the same, where each (uidNumber and gidNumber) are indexed separately into separate indices? Or, does option 2 index the possible combinations of uidNumber/gidNumber, whereas option 1 indexes them separately? Thank you for you help. Thx, Jeff

1 0

accesslog contextcsn isn't always updated
by btb 26 Aug '17

26 Aug '17

hi, i am seeing a symptom where the accesslog contextcsn is not always updated when a new entry is added to the accesslog. i have a test setup [config is below], with a content database using the accesslog and syncprov overlays, and an accesslog database using the syncprov overlay. for the purposes of testing, i'm not using it as a provider for any consumers. just running by itself, and watching its behavior. when a modification is made to an entry in the content db, the contextcsn value for the content db is always updated, and a new entry is always added to the accesslog db. but when the accesslog db gets a new entry, the accesslog contextcsn does not always update to match the new entry [see example below]. ldap_accesslog_noop is just a small shell script which updates the info attribute for an entry. it's somewhat anecdotal, but there may be a timing factor involved. if there is no activity for a little while [as little as a few minutes, sometimes], then a modification performed, that does not update the accesslog contextcsn. but if subsequent modifications are done within a few moments, it then eventually updates the accesslog contextcsn correctly, typically as of the second modification, but sometimes the third. if modifications then continue, with little delay between them, then the contextcsn seems to stay consistently up to date. if activity then stops, and some time passes as before, the symptom reappears. this is version 2.4.44 on freebsd 10.3-release, built from ports. i'm hoping someone can offer some guidance on how to troubleshoot this further, or what i might be doing wrong. i can provide more config details, logs, debugging ,etc., if needed. apologies for the long collections of details following, and thanks! ###### first mod, after some time of inactivity: ###### >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170825225855.866010Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503221460 entryCSN: 20170825225855.866010Z#000000#001#000000 >./ldap_accesslog_noop >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717700 entryCSN: 20170826032140.674259Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b dc=example,dc=com -s base contextcsn dn: dc=example,dc=com contextCSN: 20170826032140.674259Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 (reqdn=uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com) entrycsn dn: reqStart=20170825034142.000004Z,cn=accesslog2 entryCSN: 20170825034142.304465Z#000000#001#000000 dn: reqStart=20170825034147.000004Z,cn=accesslog2 entryCSN: 20170825034147.248214Z#000000#001#000000 dn: reqStart=20170825034238.000004Z,cn=accesslog2 entryCSN: 20170825034238.430123Z#000000#001#000000 dn: reqStart=20170825034239.000004Z,cn=accesslog2 entryCSN: 20170825034239.815833Z#000000#001#000000 dn: reqStart=20170825034320.000004Z,cn=accesslog2 entryCSN: 20170825034320.198025Z#000000#001#000000 dn: reqStart=20170825034321.000004Z,cn=accesslog2 entryCSN: 20170825034321.767124Z#000000#001#000000 dn: reqStart=20170825225347.000004Z,cn=accesslog2 entryCSN: 20170825225347.344528Z#000000#001#000000 dn: reqStart=20170825225849.000007Z,cn=accesslog2 entryCSN: 20170825225849.109615Z#000000#001#000000 dn: reqStart=20170825225855.000007Z,cn=accesslog2 entryCSN: 20170825225855.866010Z#000000#001#000000 dn: reqStart=20170826032140.000007Z,cn=accesslog2 entryCSN: 20170826032140.674259Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170825225855.866010Z#000000#001#000000 ###### second mod, a few seconds later: ###### ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170825225855.866010Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717700 entryCSN: 20170826032140.674259Z#000000#001#000000 >./ldap_accesslog_noop >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717721 entryCSN: 20170826032201.236788Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b dc=example,dc=com -s base contextcsn dn: dc=example,dc=com contextCSN: 20170826032201.236788Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 (reqdn=uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com) entrycsn dn: reqStart=20170825034142.000004Z,cn=accesslog2 entryCSN: 20170825034142.304465Z#000000#001#000000 dn: reqStart=20170825034147.000004Z,cn=accesslog2 entryCSN: 20170825034147.248214Z#000000#001#000000 dn: reqStart=20170825034238.000004Z,cn=accesslog2 entryCSN: 20170825034238.430123Z#000000#001#000000 dn: reqStart=20170825034239.000004Z,cn=accesslog2 entryCSN: 20170825034239.815833Z#000000#001#000000 dn: reqStart=20170825034320.000004Z,cn=accesslog2 entryCSN: 20170825034320.198025Z#000000#001#000000 dn: reqStart=20170825034321.000004Z,cn=accesslog2 entryCSN: 20170825034321.767124Z#000000#001#000000 dn: reqStart=20170825225347.000004Z,cn=accesslog2 entryCSN: 20170825225347.344528Z#000000#001#000000 dn: reqStart=20170825225849.000007Z,cn=accesslog2 entryCSN: 20170825225849.109615Z#000000#001#000000 dn: reqStart=20170825225855.000007Z,cn=accesslog2 entryCSN: 20170825225855.866010Z#000000#001#000000 dn: reqStart=20170826032140.000007Z,cn=accesslog2 entryCSN: 20170826032140.674259Z#000000#001#000000 dn: reqStart=20170826032201.000007Z,cn=accesslog2 entryCSN: 20170826032201.236788Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170825225855.866010Z#000000#001#000000 ###### third mod, a few seconds after second mod: ###### ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170825225855.866010Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717721 entryCSN: 20170826032201.236788Z#000000#001#000000 >./ldap_accesslog_noop >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717758 entryCSN: 20170826032238.330244Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b dc=example,dc=com -s base contextcsn dn: dc=example,dc=com contextCSN: 20170826032238.330244Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 (reqdn=uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com) entrycsn dn: reqStart=20170825034142.000004Z,cn=accesslog2 entryCSN: 20170825034142.304465Z#000000#001#000000 dn: reqStart=20170825034147.000004Z,cn=accesslog2 entryCSN: 20170825034147.248214Z#000000#001#000000 dn: reqStart=20170825034238.000004Z,cn=accesslog2 entryCSN: 20170825034238.430123Z#000000#001#000000 dn: reqStart=20170825034239.000004Z,cn=accesslog2 entryCSN: 20170825034239.815833Z#000000#001#000000 dn: reqStart=20170825034320.000004Z,cn=accesslog2 entryCSN: 20170825034320.198025Z#000000#001#000000 dn: reqStart=20170825034321.000004Z,cn=accesslog2 entryCSN: 20170825034321.767124Z#000000#001#000000 dn: reqStart=20170825225347.000004Z,cn=accesslog2 entryCSN: 20170825225347.344528Z#000000#001#000000 dn: reqStart=20170825225849.000007Z,cn=accesslog2 entryCSN: 20170825225849.109615Z#000000#001#000000 dn: reqStart=20170825225855.000007Z,cn=accesslog2 entryCSN: 20170825225855.866010Z#000000#001#000000 dn: reqStart=20170826032140.000007Z,cn=accesslog2 entryCSN: 20170826032140.674259Z#000000#001#000000 dn: reqStart=20170826032201.000007Z,cn=accesslog2 entryCSN: 20170826032201.236788Z#000000#001#000000 dn: reqStart=20170826032238.000007Z,cn=accesslog2 entryCSN: 20170826032238.330244Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170826032238.330244Z#000000#001#000000 ###### fourth mod, after ~5 minutes have passed ###### >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170826032238.330244Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503717758 entryCSN: 20170826032238.330244Z#000000#001#000000 >./ldap_accesslog_noop >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com -s base info entrycsn dn: uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com info: 1503718313 entryCSN: 20170826033153.554034Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b dc=example,dc=com -s base contextcsn dn: dc=example,dc=com contextCSN: 20170826033153.554034Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 (reqdn=uid=accesslog_noop,ou=replication,ou=system,ou=accounts,dc=example,dc=com) entrycsn dn: reqStart=20170825034142.000004Z,cn=accesslog2 entryCSN: 20170825034142.304465Z#000000#001#000000 dn: reqStart=20170825034147.000004Z,cn=accesslog2 entryCSN: 20170825034147.248214Z#000000#001#000000 dn: reqStart=20170825034238.000004Z,cn=accesslog2 entryCSN: 20170825034238.430123Z#000000#001#000000 dn: reqStart=20170825034239.000004Z,cn=accesslog2 entryCSN: 20170825034239.815833Z#000000#001#000000 dn: reqStart=20170825034320.000004Z,cn=accesslog2 entryCSN: 20170825034320.198025Z#000000#001#000000 dn: reqStart=20170825034321.000004Z,cn=accesslog2 entryCSN: 20170825034321.767124Z#000000#001#000000 dn: reqStart=20170825225347.000004Z,cn=accesslog2 entryCSN: 20170825225347.344528Z#000000#001#000000 dn: reqStart=20170825225849.000007Z,cn=accesslog2 entryCSN: 20170825225849.109615Z#000000#001#000000 dn: reqStart=20170825225855.000007Z,cn=accesslog2 entryCSN: 20170825225855.866010Z#000000#001#000000 dn: reqStart=20170826032140.000007Z,cn=accesslog2 entryCSN: 20170826032140.674259Z#000000#001#000000 dn: reqStart=20170826032201.000007Z,cn=accesslog2 entryCSN: 20170826032201.236788Z#000000#001#000000 dn: reqStart=20170826032238.000007Z,cn=accesslog2 entryCSN: 20170826032238.330244Z#000000#001#000000 dn: reqStart=20170826033153.000007Z,cn=accesslog2 entryCSN: 20170826033153.554034Z#000000#001#000000 >ldapsearch -xLLLH ldap://localhost/ -D uid=admin,dc=example,dc=com -w xxxxxx -b cn=accesslog2 -s base contextcsn dn: cn=accesslog2 contextCSN: 20170826032238.330244Z#000000#001#000000 ###### configuration ###### dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcLogLevel: stats sync olcPasswordCryptSaltFormat: $6$rounds=8000$%.16s olcPidFile: /var/run/openldap/slapd.pid olcSaslSecProps: noanonymous olcServerID: 1 olcTLSCACertificateFile: /usr/local/etc/pki/trusted_root_authorities/example_roo t_ca-cert.pem olcTLSCertificateFile: /usr/local/etc/openldap/pki/dsa0.example.com-cert.pe m olcTLSCertificateKeyFile: /usr/local/etc/openldap/pki/dsa0.example.com-key. pem olcTLSVerifyClient: never structuralObjectClass: olcGlobal entryUUID: 5e961a2a-290d-1036-96af-778fc97ab8bc creatorsName: cn=config createTimestamp: 20161017233001Z entryCSN: 20170520231408.133014Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20170520231408Z dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/libexec/openldap olcModuleLoad: {0}back_monitor.la olcModuleLoad: {1}back_mdb.la olcModuleLoad: {2}nssov.la olcModuleLoad: {3}ppolicy.la olcModuleLoad: {4}refint.la olcModuleLoad: {5}unique.la olcModuleLoad: {6}constraint.la olcModuleLoad: {7}memberof.la olcModuleLoad: {8}dynlist.la olcModuleLoad: {9}translucent.la olcModuleLoad: {10}valsort.la olcModuleLoad: {11}pw-sha2.la olcModuleLoad: {12}syncprov.la olcModuleLoad: {13}accesslog.la structuralObjectClass: olcModuleList entryUUID: 5e962542-290d-1036-96b0-778fc97ab8bc creatorsName: cn=config createTimestamp: 20161017233001Z entryCSN: 20161017233001.558726Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20161017233001Z [...] dn: olcDatabase={4}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {4}mdb olcDbDirectory: /var/db/openldap-data/example.com olcSuffix: dc=example,dc=com olcAccess:: ezB9dG8gYXR0cnM9dXNlclBhc3N3b3JkCglieSBhbm9ueW1vdXMgYXV0aAoJYnkg c2VsZiA9eHcKCWJ5ICogbm9uZQ== olcAccess:: ezF9dG8gKg0JYnkgc2VsZiB3cml0ZQ0JYnkgdXNlcnMgcmVhZA0JYnkgKiBub25l olcRootDN: uid=admin,dc=example,dc=com structuralObjectClass: olcMdbConfig entryUUID: 4801edee-14ed-1037-9fb8-99e8705e53d3 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com createTimestamp: 20170814033454Z entryCSN: 20170814035744.555520Z#000000#001#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com modifyTimestamp: 20170814035744Z dn: olcOverlay={0}syncprov,olcDatabase={4}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov olcSpCheckpoint: 10 5 olcSpSessionlog: 500 olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 198df6be-14ee-1037-9fbd-99e8705e53d3 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com createTimestamp: 20170814034045Z entryCSN: 20170814034045.759202Z#000000#001#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com modifyTimestamp: 20170814034045Z dn: olcOverlay={1}accesslog,olcDatabase={4}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog2 olcAccessLogOps: writes olcAccessLogPurge: 14+00:00 1+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: 0a21a20c-14ee-1037-9fbc-99e8705e53d3 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com createTimestamp: 20170814034019Z entryCSN: 20170814034019.883417Z#000000#001#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com modifyTimestamp: 20170814034019Z dn: olcDatabase={5}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top olcDatabase: {5}mdb olcDbDirectory: /var/db/openldap-data/accesslog2 olcSuffix: cn=accesslog2 olcRootDN: uid=admin,dc=example,dc=com structuralObjectClass: olcMdbConfig entryUUID: 16132114-14ec-1037-9fb7-99e8705e53d3 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com createTimestamp: 20170814032620Z entryCSN: 20170814034648.206981Z#000000#001#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com modifyTimestamp: 20170814034648Z dn: olcOverlay={0}syncprov,olcDatabase={5}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: e2927c2a-14ed-1037-9fbb-99e8705e53d3 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com createTimestamp: 20170814033913Z entryCSN: 20170814033913.514143Z#000000#001#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com modifyTimestamp: 20170814033913Z

2 1

OpenLDAP Replication Error
by Zpyro . 25 Aug '17

25 Aug '17

Hi All - I am trying to setup replication between a Centos 5 (2.3) and Centos 7 (2.4) server. Partial replication is working - however it has not fully replicated. I am receiving an error of "syncrepl_message_to_entry: rid=123 mods check (postalAddress: value #0 invalid per syntax)" in the logs. >From the research I was doing, it looks like this is a reference to a missing schema - however I am pretty sure they are all in place. Below are the results from querying the schemas on both - ldapsearch -H ldap://localhost -x -s base -b "cn=subschema" objectclasses as well as the slapd.conf files from both hosts. Any insight into what I am missing would be greatly appreciated!! Please let me know if you need any more information. Thank You!! ----- PRIMARY SERVER ---- # # # base <cn=subschema> with scope baseObject dn: cn=Subschema # extended LDIF # filter: (objectclass=*) # LDAPv3 # numEntries: 1 # numResponses: 2 objectClasses: ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST domainComponent MAY ( associatedName $ organizationName $ description $ businessCategory $ seeAlso $ searchGuide $ userPassword $ localityName $ stateOrProvinceName $ streetAddress $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) objectClasses: ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart' SUP domain STRUCTURAL MAY ( commonName $ surname $ description $ seeAlso $ telephoneNumber $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) objectClasses: ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) objectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' DESC 'RFC1274: an object related to an domain' SUP top AUXILIARY MUST associatedDomain ) objectClasses: ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country STRUCTURAL MUST friendlyCountryName ) objectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'RFC1274: simple security object' SUP top AUXILIARY MUST userPassword ) objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization $ organizationalUnit ) STRUCTURAL MAY buildingName ) objectClasses: ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA' SUP dsa STRUCTURAL MAY dSAQuality ) objectClasses: ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData' SUP top AUXILIARY MUST dsaQuality MAY ( subtreeMinimumQuality $ subtreeMaximumQuality ) ) objectClasses: ( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilotPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelephoneNumber $ organizationalStatus $ mailPreferenceOption $ personalSignature ) ) objectClasses: ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ host ) ) objectClasses: ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP top STRUCTURAL MUST documentIdentifier MAY ( commonName $ description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ documentTitle $ documentVersion $ documentAuthor $ documentLocation $ documentPublisher ) ) objectClasses: ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST commonName MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) objectClasses: ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL MUST commonName MAY ( description $ seeAlso $ telephonenumber $ localityName $ organizationName $ organizationalUnitName ) ) objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.10 NAME 'nisObject' DESC 'An entry in a NIS map' SUP top STRUCTURAL MUST ( cn $ nisMapEntry $ nisMapName ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a MAC address' SUP top AUXILIARY MAY macAddress ) objectClasses: ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' DESC 'A device with boot parameters' SUP top AUXILIARY MAY ( bootFile $ bootParameter ) ) objectClasses: ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' DESC 'Additional attributes for shadow passwords' SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top STRUCTURAL MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.3 NAME 'ipService' DESC 'Abstraction an Internet Protocol service' SUP top STRUCTURAL MUST ( cn $ ipServicePort $ ipServiceProtocol ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' DESC 'Abstraction of an IP protocol' SUP top STRUCTURAL MUST ( cn $ ipProtocolNumber $ description ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' DESC 'Abstraction of an ONC/RPC binding' SUP top STRUCTURAL MUST ( cn $ oncRpcNumber $ description ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.6 NAME 'ipHost' DESC 'Abstraction of a host, an IP device' SUP top AUXILIARY MUST ( cn $ ipHostNumber ) MAY ( l $ description $ manager ) ) objectClasses: ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' DESC 'Abstraction of an IP network' SUP top STRUCTURAL MUST ( cn $ ipNetworkNumber ) MAY ( ipNetmaskNumber $ l $ description $ manager ) ) objectClasses: ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' DESC 'Abstraction of a netgroup' SUP top STRUCTURAL MUST cn MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.9 NAME 'nisMap' DESC 'A generic abstraction of a NIS map' SUP top STRUCTURAL MUST nisMapName MAY description ) objectClasses: ( 1.3.6.1.1.3.1 NAME 'uidObject' DESC 'RFC2377: uid object' SUP top AUXILIARY MUST uid ) objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC 'RFC2252: extensible object' SUP top AUXILIARY ) objectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' DESC 'RFC2247: domain component object' SUP top AUXILIARY MUST dc ) objectClasses: ( 1.3.6.1.4.1.16331.2.2.2.1 NAME 'contactPerson' DESC 'Contact - Addressbook entry' AUXILIARY MAY ( anniversary $ marker $ birthday $ sendHolidayCard $ externalUID $ externalUIDSyncTimestamp $ modifyObjectTimestamp $ prefix $ middleName $ suffix $ custom1 $ custom2 $ custom3 $ custom4 $ country ) ) objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' DESC 'RFC2079: object that contains the URI attribute type' SUP top AUXILIARY MAY labeledURI ) objectClasses: ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotDSE' ) DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL MAY cn ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.0 NAME 'olcConfig' DESC 'OpenLDAP configuration object' SUP top ABSTRACT ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.1 NAME 'olcGlobal' DESC 'OpenLDAP Global configuration options' SUP olcConfig STRUCTURAL MAY ( cn $ olcConfigFile $ olcConfigDir $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcDisallows $ olcGentleHUP $ olcIdleTimeout $ olcIndexSubstrIfMaxLen $ olcIndexSubstrIfMinLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcLocalSSF $ olcLogLevel $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPluginLogFile $ olcReadOnly $ olcReferral $ olcReplicaPidFile $ olcReplicaArgsFile $ olcReplicationInterval $ olcReplogFile $ olcRequires $ olcRestrict $ olcReverseLookup $ olcRootDSE $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcSizeLimit $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcSrvtab $ olcThreads $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcToolThreads $ olcObjectIdentifier $ olcAttributeTypes $ olcObjectClasses $ olcDitContentRules ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.2 NAME 'olcSchemaConfig' DESC 'OpenLDAP schema object' SUP olcConfig STRUCTURAL MAY ( cn $ olcObjectIdentifier $ olcAttributeTypes $ olcObjectClasses $ olcDitContentRules ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.3 NAME 'olcBackendConfig' DESC 'OpenLDAP Backend-specific options' SUP olcConfig STRUCTURAL MUST olcBackend ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.4 NAME 'olcDatabaseConfig' DESC 'OpenLDAP Database-specific options' SUP olcConfig STRUCTURAL MUST olcDatabase MAY ( olcSuffix $ olcSubordinate $ olcAccess $ olcLastMod $ olcLimits $ olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcReplica $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ olcSchemaDN $ olcSecurity $ olcSizeLimit $ olcSyncrepl $ olcTimeLimit $ olcUpdateDN $ olcUpdateRef ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.5 NAME 'olcOverlayConfig' DESC 'OpenLDAP Overlay-specific options' SUP olcConfig STRUCTURAL MUST olcOverlay ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.6 NAME 'olcIncludeFile' DESC 'OpenLDAP configuration include file' SUP olcConfig STRUCTURAL MUST olcInclude MAY ( cn $ olcRootDSE ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.7 NAME 'olcFrontendConfig' DESC 'OpenLDAP frontend configuration' AUXILIARY MAY ( olcDefaultSearchBase $ olcPasswordHash ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.8 NAME 'olcModuleList' DESC 'OpenLDAP dynamic module info' SUP olcConfig STRUCTURAL MAY ( cn $ olcModulePath $ olcModuleLoad ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.1.1 NAME 'olcBdbConfig' DESC 'BDB backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ olcDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.1.2 NAME 'olcHdbConfig' DESC 'HDB backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ olcDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.2.1 NAME 'olcLdifConfig' DESC 'LDIF backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.3.1 NAME 'olcLDAPConfig' DESC 'LDAP backend configuration' SUP olcDatabaseConfig STRUCTURAL MAY ( olcDbURI $ olcDbStartTLS $ olcDbACLAuthcDn $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertAuthcDn $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbRebindAsUser $ olcDbChaseReferrals $ olcDbTFSupport $ olcDbProxyWhoAmI $ olcDbTimeout $ olcDbIdleTimeout $ olcDbSingleConn $ olcDbCancel $ olcDbQuarantine $ olcDbUseTemporaryConn $ olcDbConnectionPoolMax ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.4.1 NAME 'olcMonitorConfig' DESC 'Monitor backend configuration' SUP olcDatabaseConfig STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.1.1 NAME 'olcSyncProvConfig' DESC 'SyncRepl Provider configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcSpCheckpoint $ olcSpSessionlog $ olcSpNoPresent ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.12.1 NAME 'olcPPolicyConfig' DESC 'Password Policy configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcPPolicyDefault $ olcPPolicyHashCleartext $ olcPPolicyUseLockout ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.3.1 NAME 'olcChainConfig' DESC 'Chain configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcChainCacheURI $ olcChainMaxReferralDepth $ olcChainReturnError ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.3.2 NAME 'olcChainDatabase' DESC 'Chain remote server configuration' AUXILIARY ) objectClasses: ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXILIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) objectClasses: ( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top AUXILIARY MAY pwdCheckModule ) objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'RFC2798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) objectClasses: ( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'namedref: named subordinate referral' SUP top STRUCTURAL MUST ref ) objectClasses: ( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL MUST ( cn $ subtreeSpecification ) ) objectClasses: ( 2.5.20.1 NAME 'subschema' DESC 'RFC2252: controlling subschema (sub)entry' AUXILIARY MAY ( dITStructureRules $ nameForms $ dITContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) ) objectClasses: ( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' ABSTRACT MUST objectClass ) objectClasses: ( 2.5.6.10 NAME 'residentialPerson' DESC 'RFC2256: an residential person' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description ) ) objectClasses: ( 2.5.6.12 NAME 'applicationEntity' DESC 'RFC2256: an application entity' SUP top STRUCTURAL MUST ( presentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) objectClasses: ( 2.5.6.13 NAME 'dSA' DESC 'RFC2256: a directory system agent (a server)' SUP applicationEntity STRUCTURAL MAY knowledgeInformation ) objectClasses: ( 2.5.6.14 NAME 'device' DESC 'RFC2256: a device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) objectClasses: ( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'RFC2256: a strong authentication user' SUP top AUXILIARY MUST userCertificate ) objectClasses: ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP certificationAuthority AUXILIARY MAY deltaRevocationList ) objectClasses: ( 2.5.6.16 NAME 'certificationAuthority' DESC 'RFC2256: a certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a group of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectClasses: ( 2.5.6.18 NAME 'userSecurityInformation' DESC 'RFC2256: a user security information' SUP top AUXILIARY MAY supportedAlgorithms ) objectClasses: ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST cn MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'RFC2256: an alias' SUP top STRUCTURAL MUST aliasedObjectName ) objectClasses: ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST dmdName MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.21 NAME 'pkiUser' DESC 'RFC2587: a PKI user' SUP top AUXILIARY MAY userCertificate ) objectClasses: ( 2.5.6.22 NAME 'pkiCA' DESC 'RFC2587: PKI certificate authority' SUP top AUXILIARY MAY ( authorityRevocationList $ certificateRevocationList $ cACertificate $ crossCertificatePair ) ) objectClasses: ( 2.5.6.23 NAME 'deltaCRL' DESC 'RFC2587: PKI user' SUP top AUXILIARY MAY deltaRevocationList ) objectClasses: ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) ) objectClasses: ( 2.5.6.3 NAME 'locality' DESC 'RFC2256: a locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) objectClasses: ( 2.5.6.4 NAME 'organization' DESC 'RFC2256: an organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.5 NAME 'organizationalUnit' DESC 'RFC2256: an organizational unit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) objectClasses: ( 2.5.6.7 NAME 'organizationalPerson' DESC 'RFC2256: an organizational person' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) objectClasses: ( 2.5.6.8 NAME 'organizationalRole' DESC 'RFC2256: an organizational role' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) objectClasses: ( 2.5.6.9 NAME 'groupOfNames' DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) # requesting: objectclasses result: 0 Success search: 2 # search result # Subschema ---- REPLICA SERVER ---- # # # base <cn=subschema> with scope baseObject dn: cn=Subschema # extended LDIF # filter: (objectclass=*) # LDAPv3 # numEntries: 1 # numResponses: 2 objectClasses: ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST domainComponent MAY ( associatedName $ organizationName $ description $ businessCategory $ seeAlso $ searchGuide $ userPassword $ localityName $ stateOrProvinceName $ streetAddress $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) objectClasses: ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart' SUP domain STRUCTURAL MAY ( commonName $ surname $ description $ seeAlso $ telephoneNumber $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ streetAddress $ facsimileTelephoneNumber $ internationalISDNNumber $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ preferredDeliveryMethod $ destinationIndicator $ registeredAddress $ x121Address ) ) objectClasses: ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) objectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' DESC 'RFC1274: an object related to an domain' SUP top AUXILIARY MUST associatedDomain ) objectClasses: ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country STRUCTURAL MUST friendlyCountryName ) objectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'RFC1274: simple security object' SUP top AUXILIARY MUST userPassword ) objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization $ organizationalUnit ) STRUCTURAL MAY buildingName ) objectClasses: ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA' SUP dsa STRUCTURAL MAY dSAQuality ) objectClasses: ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData' SUP top AUXILIARY MUST dsaQuality MAY ( subtreeMinimumQuality $ subtreeMaximumQuality ) ) objectClasses: ( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilotPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelephoneNumber $ organizationalStatus $ mailPreferenceOption $ personalSignature ) ) objectClasses: ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ host ) ) objectClasses: ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP top STRUCTURAL MUST documentIdentifier MAY ( commonName $ description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ documentTitle $ documentVersion $ documentAuthor $ documentLocation $ documentPublisher ) ) objectClasses: ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST commonName MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) objectClasses: ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL MUST commonName MAY ( description $ seeAlso $ telephonenumber $ localityName $ organizationName $ organizationalUnitName ) ) objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.10 NAME 'nisObject' DESC 'An entry in a NIS map' SUP top STRUCTURAL MUST ( cn $ nisMapEntry $ nisMapName ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.11 NAME 'ieee802Device' DESC 'A device with a MAC address' SUP top AUXILIARY MAY macAddress ) objectClasses: ( 1.3.6.1.1.1.2.12 NAME 'bootableDevice' DESC 'A device with boot parameters' SUP top AUXILIARY MAY ( bootFile $ bootParameter ) ) objectClasses: ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' DESC 'Additional attributes for shadow passwords' SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Abstraction of a group of accounts' SUP top STRUCTURAL MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.3 NAME 'ipService' DESC 'Abstraction an Internet Protocol service' SUP top STRUCTURAL MUST ( cn $ ipServicePort $ ipServiceProtocol ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.4 NAME 'ipProtocol' DESC 'Abstraction of an IP protocol' SUP top STRUCTURAL MUST ( cn $ ipProtocolNumber $ description ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.5 NAME 'oncRpc' DESC 'Abstraction of an ONC/RPC binding' SUP top STRUCTURAL MUST ( cn $ oncRpcNumber $ description ) MAY description ) objectClasses: ( 1.3.6.1.1.1.2.6 NAME 'ipHost' DESC 'Abstraction of a host, an IP device' SUP top AUXILIARY MUST ( cn $ ipHostNumber ) MAY ( l $ description $ manager ) ) objectClasses: ( 1.3.6.1.1.1.2.7 NAME 'ipNetwork' DESC 'Abstraction of an IP network' SUP top STRUCTURAL MUST ( cn $ ipNetworkNumber ) MAY ( ipNetmaskNumber $ l $ description $ manager ) ) objectClasses: ( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' DESC 'Abstraction of a netgroup' SUP top STRUCTURAL MUST cn MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) ) objectClasses: ( 1.3.6.1.1.1.2.9 NAME 'nisMap' DESC 'A generic abstraction of a NIS map' SUP top STRUCTURAL MUST nisMapName MAY description ) objectClasses: ( 1.3.6.1.1.3.1 NAME 'uidObject' DESC 'RFC2377: uid object' SUP top AUXILIARY MUST uid ) objectClasses: ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC 'RFC2252: extensible object' SUP top AUXILIARY ) objectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' DESC 'RFC2247: domain component object' SUP top AUXILIARY MUST dc ) objectClasses: ( 1.3.6.1.4.1.16331.2.2.2.1 NAME 'contactPerson' DESC 'Contact - Addressbook entry' AUXILIARY MAY ( anniversary $ marker $ birthday $ sendHolidayCard $ externalUID $ externalUIDSyncTimestamp $ modifyObjectTimestamp $ prefix $ middleName $ suffix $ custom1 $ custom2 $ custom3 $ custom4 $ country ) ) objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' DESC 'RFC2079: object that contains the URI attribute type' SUP top AUXILIARY MAY labeledURI ) objectClasses: ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotDSE' ) DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL MAY cn ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.0 NAME 'olcConfig' DESC 'OpenLDAP configuration object' SUP top ABSTRACT ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.1 NAME 'olcGlobal' DESC 'OpenLDAP Global configuration options' SUP olcConfig STRUCTURAL MAY ( cn $ olcConfigFile $ olcConfigDir $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcDisallows $ olcGentleHUP $ olcIdleTimeout $ olcIndexSubstrIfMaxLen $ olcIndexSubstrIfMinLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcLocalSSF $ olcLogLevel $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPluginLogFile $ olcReadOnly $ olcReferral $ olcReplicaPidFile $ olcReplicaArgsFile $ olcReplicationInterval $ olcReplogFile $ olcRequires $ olcRestrict $ olcReverseLookup $ olcRootDSE $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcSizeLimit $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcSrvtab $ olcThreads $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcToolThreads $ olcObjectIdentifier $ olcAttributeTypes $ olcObjectClasses $ olcDitContentRules ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.2 NAME 'olcSchemaConfig' DESC 'OpenLDAP schema object' SUP olcConfig STRUCTURAL MAY ( cn $ olcObjectIdentifier $ olcAttributeTypes $ olcObjectClasses $ olcDitContentRules ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.3 NAME 'olcBackendConfig' DESC 'OpenLDAP Backend-specific options' SUP olcConfig STRUCTURAL MUST olcBackend ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.4 NAME 'olcDatabaseConfig' DESC 'OpenLDAP Database-specific options' SUP olcConfig STRUCTURAL MUST olcDatabase MAY ( olcSuffix $ olcSubordinate $ olcAccess $ olcLastMod $ olcLimits $ olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcReplica $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ olcSchemaDN $ olcSecurity $ olcSizeLimit $ olcSyncrepl $ olcTimeLimit $ olcUpdateDN $ olcUpdateRef ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.5 NAME 'olcOverlayConfig' DESC 'OpenLDAP Overlay-specific options' SUP olcConfig STRUCTURAL MUST olcOverlay ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.6 NAME 'olcIncludeFile' DESC 'OpenLDAP configuration include file' SUP olcConfig STRUCTURAL MUST olcInclude MAY ( cn $ olcRootDSE ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.7 NAME 'olcFrontendConfig' DESC 'OpenLDAP frontend configuration' AUXILIARY MAY ( olcDefaultSearchBase $ olcPasswordHash ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.0.8 NAME 'olcModuleList' DESC 'OpenLDAP dynamic module info' SUP olcConfig STRUCTURAL MAY ( cn $ olcModulePath $ olcModuleLoad ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.1.1 NAME 'olcBdbConfig' DESC 'BDB backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ olcDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.1.2 NAME 'olcHdbConfig' DESC 'HDB backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ olcDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.2.1 NAME 'olcLdifConfig' DESC 'LDIF backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.3.1 NAME 'olcLDAPConfig' DESC 'LDAP backend configuration' SUP olcDatabaseConfig STRUCTURAL MAY ( olcDbURI $ olcDbStartTLS $ olcDbACLAuthcDn $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertAuthcDn $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbRebindAsUser $ olcDbChaseReferrals $ olcDbTFSupport $ olcDbProxyWhoAmI $ olcDbTimeout $ olcDbIdleTimeout $ olcDbSingleConn $ olcDbCancel $ olcDbQuarantine $ olcDbUseTemporaryConn $ olcDbConnectionPoolMax ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.2.4.1 NAME 'olcMonitorConfig' DESC 'Monitor backend configuration' SUP olcDatabaseConfig STRUCTURAL ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.1.1 NAME 'olcSyncProvConfig' DESC 'SyncRepl Provider configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcSpCheckpoint $ olcSpSessionlog $ olcSpNoPresent ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.12.1 NAME 'olcPPolicyConfig' DESC 'Password Policy configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcPPolicyDefault $ olcPPolicyHashCleartext $ olcPPolicyUseLockout ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.3.1 NAME 'olcChainConfig' DESC 'Chain configuration' SUP olcOverlayConfig STRUCTURAL MAY ( olcChainCacheURI $ olcChainMaxReferralDepth $ olcChainReturnError ) ) objectClasses: ( 1.3.6.1.4.1.4203.666.11.1.4.3.3.2 NAME 'olcChainDatabase' DESC 'Chain remote server configuration' AUXILIARY ) objectClasses: ( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXILIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) ) objectClasses: ( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top AUXILIARY MAY pwdCheckModule ) objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'RFC2798: Internet Organizational Person' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) ) objectClasses: ( 2.16.840.1.113730.3.2.6 NAME 'referral' DESC 'namedref: named subordinate referral' SUP top STRUCTURAL MUST ref ) objectClasses: ( 2.5.17.0 NAME 'subentry' SUP top STRUCTURAL MUST ( cn $ subtreeSpecification ) ) objectClasses: ( 2.5.20.1 NAME 'subschema' DESC 'RFC2252: controlling subschema (sub)entry' AUXILIARY MAY ( dITStructureRules $ nameForms $ dITContentRules $ objectClasses $ attributeTypes $ matchingRules $ matchingRuleUse ) ) objectClasses: ( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' ABSTRACT MUST objectClass ) objectClasses: ( 2.5.6.10 NAME 'residentialPerson' DESC 'RFC2256: an residential person' SUP person STRUCTURAL MUST l MAY ( businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l ) ) objectClasses: ( 2.5.6.11 NAME 'applicationProcess' DESC 'RFC2256: an application process' SUP top STRUCTURAL MUST cn MAY ( seeAlso $ ou $ l $ description ) ) objectClasses: ( 2.5.6.12 NAME 'applicationEntity' DESC 'RFC2256: an application entity' SUP top STRUCTURAL MUST ( presentationAddress $ cn ) MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $ description ) ) objectClasses: ( 2.5.6.13 NAME 'dSA' DESC 'RFC2256: a directory system agent (a server)' SUP applicationEntity STRUCTURAL MAY knowledgeInformation ) objectClasses: ( 2.5.6.14 NAME 'device' DESC 'RFC2256: a device' SUP top STRUCTURAL MUST cn MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) ) objectClasses: ( 2.5.6.15 NAME 'strongAuthenticationUser' DESC 'RFC2256: a strong authentication user' SUP top AUXILIARY MUST userCertificate ) objectClasses: ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP certificationAuthority AUXILIARY MAY deltaRevocationList ) objectClasses: ( 2.5.6.16 NAME 'certificationAuthority' DESC 'RFC2256: a certificate authority' SUP top AUXILIARY MUST ( authorityRevocationList $ certificateRevocationList $ cACertificate ) MAY crossCertificatePair ) objectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames' DESC 'RFC2256: a group of unique names (DN and Unique Identifier)' SUP top STRUCTURAL MUST ( uniqueMember $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) objectClasses: ( 2.5.6.18 NAME 'userSecurityInformation' DESC 'RFC2256: a user security information' SUP top AUXILIARY MAY supportedAlgorithms ) objectClasses: ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST cn MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) objectClasses: ( 2.5.6.1 NAME 'alias' DESC 'RFC2256: an alias' SUP top STRUCTURAL MUST aliasedObjectName ) objectClasses: ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST dmdName MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.21 NAME 'pkiUser' DESC 'RFC2587: a PKI user' SUP top AUXILIARY MAY userCertificate ) objectClasses: ( 2.5.6.22 NAME 'pkiCA' DESC 'RFC2587: PKI certificate authority' SUP top AUXILIARY MAY ( authorityRevocationList $ certificateRevocationList $ cACertificate $ crossCertificatePair ) ) objectClasses: ( 2.5.6.23 NAME 'deltaCRL' DESC 'RFC2587: PKI user' SUP top AUXILIARY MAY deltaRevocationList ) objectClasses: ( 2.5.6.2 NAME 'country' DESC 'RFC2256: a country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) ) objectClasses: ( 2.5.6.3 NAME 'locality' DESC 'RFC2256: a locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) ) objectClasses: ( 2.5.6.4 NAME 'organization' DESC 'RFC2256: an organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.5 NAME 'organizationalUnit' DESC 'RFC2256: an organizational unit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) ) objectClasses: ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) objectClasses: ( 2.5.6.7 NAME 'organizationalPerson' DESC 'RFC2256: an organizational person' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) ) objectClasses: ( 2.5.6.8 NAME 'organizationalRole' DESC 'RFC2256: an organizational role' SUP top STRUCTURAL MUST cn MAY ( x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l $ description ) ) objectClasses: ( 2.5.6.9 NAME 'groupOfNames' DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) # requesting: objectclasses result: 0 Success search: 2 # search result # Subschema -------SLAPD - PRIMARY---------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/ldapab.schema include /etc/openldap/schema/ppolicy.schema #include /etc/openldap/schema/apple.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/lib64/openldap moduleload ppolicy.la TLSCertificateFile /etc/openldap/ldap.cert TLSCertificateKeyFile /etc/openldap/ldap.key ####################################################################### # ldbm and/or bdb database definitions ####################################################################### sizelimit 100000 database bdb suffix "dc=domainname,dc=com" rootdn "uid=rootdn,ou=People,dc=domainname,dc=com" rootpw secret_here overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=domainname,dc=com" ppolicy_use_lockout # sync stuff overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 loglevel 256 directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub replogfile /var/lib/ldap/openldap-master-replog access to attrs=userPassword by anonymous auth by self write by * none access to dn.regex="(.*,)?ou=Contacts,uid=([^,]+),ou=People,(.*)$" by dn.regex="uid=$2,ou=People,$3" write by * none access to dn.subtree="ou=Contacts,dc=domainname,dc=com" by users write by users read access to * by users read by peername="IP=192\.168\.200\.5" read access to * by users read by peername="IP=192\.168\.201\.12" read ----------SLAPD - REPLICA ---------- Same as above with sync repl at the bottom: index entryCSN eq index entryUUID eq syncrepl rid=123 provider=ldap://192.168.200.12:389 type=refreshAndPersist interval=00:00:00:01 searchbase="dc=domainname,dc=com" filter="(objectClass=*)" scope=sub retry="5 5 300 +" attrs="*,+" bindmethod=simple binddn="uid=rootdn,ou=People,dc=domainname,dc=com" credentials=secret_here updateref ldap://primaryLDAP.domainname.com

2 1

Re: Removing Berkeley DB Log Files
by Howard Chu 25 Aug '17

25 Aug '17

Douglas Duckworth wrote: > Hi > > I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos 6.9. My > /var/lib/ldap directory contains many 10MB log files. /var partition rather > small... > > I've read they can be removed either by running "sudo db_archive -d -h > /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file > "DB_CONFIG." That file does not presently exist whereas the db_archive > command does not actually remove any of the log files. If the db_archive command doesn't remove anything, that means it thinks all of the log files are still in active use. Read the docs more carefully. http://docs.oracle.com/cd/E17076_05/html/programmer_reference/transapp_logf… > > Can I remove the old log files manually using rm? Not if the above is true, you will corrupt the logs and the DB will fail to open on a subsequent restart. > If not should I create > /var/lib/ldap/DB_CONFIG then restart slapd to make this removal automatic? > Do you have any idea why db_archive does not work or produce any helpful error > to stdout? There's no error message because there's no error, everything is working as designed. You need to do periodic checkpoints to allow log files to be closed, and then db_archive will be able to remove some of them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Removing Berkeley DB Log Files
by Douglas Duckworth 25 Aug '17

25 Aug '17

Hi I am running openldap-servers-2.4.40-16.el6.x86_64 cluster on Centos 6.9. My /var/lib/ldap directory contains many 10MB log files. /var partition rather small... I've read they can be removed either by running "sudo db_archive -d -h /var/lib/ldap/domain" or by defining "DB_LOG_AUTOREMOVE" within the file "DB_CONFIG." That file does not presently exist whereas the db_archive command does not actually remove any of the log files. Can I remove the old log files manually using rm? If not should I create /var/lib/ldap/DB_CONFIG then restart slapd to make this removal automatic? Do you have any idea why db_archive does not work or produce any helpful error to stdout? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690

1 0

Re: mdb fragmentation
by Quanah Gibson-Mount 25 Aug '17

25 Aug '17

Hi Geert, If I could, I would delete 8664 from the ITS system entirely as it was filed based on invalid information that was provided to me. It generally should be ignored. When a write operation is performed with LMDB, the freelist is scanned for available space to reuse if possible. The larger the size of the freelist, the longer amount of time it will take for the operation to complete successfully. When the database has gotten to a certain point of fragmentation (This differs based on any individual use case), it will be start taking a noticeable amount of time for those write operations to complete and the server processing the write operation does essentially come to a halt during this process. Once the write operation completes, things go back to normal. The only solution is to dump and reload the database (slapcat/slapadd or mdb_copy -c). Eventually, you will get back into the same situation and have to do this again. A recent option was added to the slapd-mdb configuration (rtxnsize) that can also help reduce the rate of fragmentation. There are some performance related issues you can find discussed on the -devel list from when it was added. Whether or not you are affected by them and whether or not the setting will help you in particular depends on whether or not your searches result in a large number of entries being returned. You can find some guidelines around tuning the parameter that I came up with in that thread. If you do not have an unlimited Zimbra License, the license check performed by the store servers will definitely affect this, since the result set is all active accounts which can be quite large. Additionally, I had at one point had a patch for the Zimbra build of OpenLDAP that made it very aggressive in finding freespace to reuse. I don't recall if it is still applied (I don't believe it currently is based on what I saw in github). It basically meant that in Zimbra, it would work extra hard to find reusable freespace, which would reduce the rate at which the database would fragment, but it also meant that once the DB was fragmented enough, it would amplify the amount of time it took for a write op to complete. I.e., it was a tradeoff of a longer time to reach a catastrophic state, but the state was more catastrophic once achieved. This is one area where LMDB differs significantly from back-hdb/bdb. You could have back-bdb/hdb databases that endured a high rate of write operations be in effect for years w/o needing maintenance. With LMDB, you get better read & write rates, but it requires periodic reloads. Hope this helps! --Quanah ----- Original Message ----- > From: "Geert Hendrickx" <geert(a)hendrickx.be> > To: "openldap-technical" <openldap-technical(a)openldap.org> > Sent: Thursday, August 24, 2017 4:53:32 AM > Subject: mdb fragmentation > Hi > > We have an OpenLDAP 2.4.44 based, 4-way MMR setup with 4 M entries, > which is fairly write intensive (Zimbra). > > Lately we've seen very frequent lockups of the master that receives > the updates (only 1 out of 4), whereas the replicas stay responsive. > According to -d stats logs, all threads suddenly take a long time to > answer any queries, and slapd can no longer accept new connections. > The issue always disappears again without intervention, but usually > hits a number of times in a row, on an almost daily basis. > > We tested a lot of things, but eventually "solved" the issue with a > slapcat and slapadd of the database - the master server has been > completely stable again since. The mdb was also reduced 50% in size. > > Looking at the old mdb (prior to the dump), mdb_stat -f shows it had > over 3.7 M free pages. Could it be an issue of database fragmentation > similar to ITS#8664? > > Is it natural that the freelist (and thus the mdb) gets this big over > time, I would expect those free pages to get reused constantly? > And in that case would it make sense to monitor the number of free > pages? Is there a threshold to look for, before things get problematic > again? (ITS#7770 would come handy here, as we already monitor/graph > various metrics from the monitor backend) > > > Geert > > > -- > geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F > This e-mail was composed using 100% recycled spam messages! -- -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Re: lock.mdb taking lots of space
by Howard Chu 24 Aug '17

24 Aug '17

Muhammed Muneer wrote: > Hi, > > Is there any particular reason why my lock.mdb is taking above 600 MB. The > data.mdb size is around 4.5 GB. The lock.mdb size is proportional to the maxreaders config setting. > Is this normal? Depending on what you set maxreaders to, probably. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

lock.mdb taking lots of space
by Muhammed Muneer 24 Aug '17

24 Aug '17

Hi, Is there any particular reason why my lock.mdb is taking above 600 MB. The data.mdb size is around 4.5 GB. Is this normal?

1 0

OpenLDAP as Proxy
by Palacios, Christian 24 Aug '17

24 Aug '17

Hi there, We need to find out if OpenLDAP will allow us to use it as a proxy so it can retrieve users from three different Windows Active Directory Domains? These three domains do not have any similar users. The user retrieval process needs to work like this: - The application that needs this LDAP connection will point to the OpenLDAP server using an LDAP address such as ldap://server.example.com:389/OU=users...etc - This application will also need to retrieve the sAMAccountName from each user retrieved via the OpenLDAP server - The application's LDAP connection settings also need to specify an Administrator's DN and password, but I'm confused about this because I don't know what Administrator account to use. Like I said, each domain has their own set of users so they don't have any Administrator accounts in common. How would this work? If you need any more information, please let me know!! Thanks, - Christian This email and any accompanying attachments are confidential. If you received this email by mistake, please delete it from your system. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited.

2 1

LDAPCon 2017 programme now online
by Andrew Findlay 24 Aug '17

24 Aug '17

The programme for the 2017 LDAP Conference has just been published: https://ldapcon.org/2017/conference-program/ It's looking good, so get your booking in quickly to get early-bird tickets and start thinking about where you want to stay in Brussels! The conference runs 19th and 20th October 2017. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

2 1

mdb fragmentation
by Geert Hendrickx 24 Aug '17

24 Aug '17

Hi We have an OpenLDAP 2.4.44 based, 4-way MMR setup with 4 M entries, which is fairly write intensive (Zimbra). Lately we've seen very frequent lockups of the master that receives the updates (only 1 out of 4), whereas the replicas stay responsive. According to -d stats logs, all threads suddenly take a long time to answer any queries, and slapd can no longer accept new connections. The issue always disappears again without intervention, but usually hits a number of times in a row, on an almost daily basis. We tested a lot of things, but eventually "solved" the issue with a slapcat and slapadd of the database - the master server has been completely stable again since. The mdb was also reduced 50% in size. Looking at the old mdb (prior to the dump), mdb_stat -f shows it had over 3.7 M free pages. Could it be an issue of database fragmentation similar to ITS#8664? Is it natural that the freelist (and thus the mdb) gets this big over time, I would expect those free pages to get reused constantly? And in that case would it make sense to monitor the number of free pages? Is there a threshold to look for, before things get problematic again? (ITS#7770 would come handy here, as we already monitor/graph various metrics from the monitor backend) Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

delta syncrepl errors
by Gerard Ranke 22 Aug '17

22 Aug '17

Hello all, I'm trying to set up delta-syncrepl on a test setup, consisting of a producer plus consumer running openldap 2.4.45. ( I'll put relevant parts of both producer and consumer config at the end of this post. ) I'm following the instructions from the openldap manual ( chapter 18.3.2 ) as much as possible. Both slapd's start up but replication isn't happening. I get the following messages in the logs: producer: 2017-08-18T14:54:39.153754+02:00 pro slapd[10098]: send_search_entry: conn 1278 ber write failed. 2017-08-18T14:54:44.157627+02:00 pro slapd[10098]: send_search_entry: conn 1279 ber write failed. 2017-08-18T14:54:49.368758+02:00 pro slapd[10098]: send_search_entry: conn 1281 ber write failed. 2017-08-18T14:55:09.390341+02:00 pro slapd[10098]: send_search_entry: conn 1283 ber write failed. 2017-08-18T14:55:19.395091+02:00 pro slapd[10098]: send_search_entry: conn 1284 ber write failed. consumer: 2017-08-18T14:54:39.153660+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:39.154089+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying (1 retries left) 2017-08-18T14:54:44.157539+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:44.158156+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:54:49.368843+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:49.369446+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:54:59.383750+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:54:59.384369+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:55:09.390382+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) 2017-08-18T14:55:09.390971+02:00 del slapd[25530]: do_syncrepl: rid=001 rc -1 retrying 2017-08-18T14:55:19.395206+02:00 del slapd[25530]: do_syncrep2: rid=001 got search entry without Sync State control (reqStart=20170815125023.000001Z,cn=accesslog) When I do a search on the producer from the consumer I get results that look like I would expect to see: ldapsearch -x -h pro.hku.nl -b "cn=accesslog" -D cn=dsyncuser,dc=hku,dc=nl -w ****** "(&(objectClass=auditWriteObject)(reqResult=0))" (...) # 20170817170609.000001Z, accesslog dn: reqStart=20170817170609.000001Z,cn=accesslog objectClass: auditAdd reqStart: 20170817170609.000001Z reqEnd: 20170817170610.000000Z reqType: add reqSession: 1 reqAuthzID: cn=root,dc=hku,dc=nl reqDN: nlHkuID=77454,ou=People,dc=hku,dc=nl reqResult: 0 reqMod: objectClass:+ top reqMod: objectClass:+ posixAccount reqMod: objectClass:+ shadowAccount reqMod: objectClass:+ inetOrgPerson reqMod: objectClass:+ nlHkuPerson reqMod: objectClass:+ eduPerson reqMod: objectClass:+ apple-user reqMod: objectClass:+ sambaSamAccount reqMod: ou:+ People reqMod: authAuthority:+ ;basic; reqMod: nlHkuID:+ 77454 reqMod: loginShell:+ /bin/false reqMod: gidNumber:+ 300 (...) reqMod: structuralObjectClass:+ nlHkuPerson reqMod: entryUUID:+ 1b7405d0-17ba-1037-98e3-99bbae3c2a53 reqMod: creatorsName:+ cn=root,dc=hku,dc=nl reqMod: createTimestamp:+ 20170817170608Z reqMod: entryCSN:+ 20170817170608.603041Z#000000#000#000000 reqMod: modifiersName:+ cn=root,dc=hku,dc=nl reqMod: modifyTimestamp:+ 20170817170608Z reqEntryUUID: 1b7405d0-17ba-1037-98e3-99bbae3c2a53 (...) The producer config has: (...) dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}dynlist.so olcModuleLoad: {2}accesslog.so olcModuleLoad: {3}syncprov.so olcModuleLoad: {4}smbk5pwd.so structuralObjectClass: olcModuleList (...) dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hku,dc=nl olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read by * break (...) olcAccess: {15}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.exact="cn=root,dc=hku,dc=nl" size=unlimited time=unlimited olcLimits: {1}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=root,dc=hku,dc=nl olcRootPW:: *** olcSyncUseSubentry: FALSE olcMonitoring: TRUE (...) dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcAccessLogConfig objectClass: olcOverlayConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE (...) dn: olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: {2}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig (...) dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap-accesslog olcSuffix: cn=accesslog olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read olcLimits: {0}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcRootDN: cn=accesslog olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart olcDbMaxSize: 1047483648 structuralObjectClass: olcMdbConfig (...) Parts from the consumer config: (...) dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}back_mdb.so olcModuleLoad: {1}dynlist.so structuralObjectClass: olcModuleList (...) dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=hku,dc=nl olcAccess: {0}to * by dn.base="cn=dsyncuser,dc=hku,dc=nl" read by * break (...) olcAccess: {15}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.exact="cn=root,dc=hku,dc=nl" size=unlimited time=unlimited olcLimits: {1}dn.exact="cn=dsyncuser,dc=hku,dc=nl" size=unlimited time=unlim ited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=replroot,dc=hku,dc=nl olcRootPW:: ***** olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=001 provider=ldap://pro.hku.nl bindmethod=simple binddn= "cn=dsyncuser,dc=hku,dc=nl" credentials="****" tls_cert="/etc/ssl/certs /del_cert.pem" tls_key="/etc/ssl/private/del_key.pem" tls_cacertdir="/etc/s sl/certs" tls_reqcert=demand tls_crlcheck=none logbase="cn=accesslog" logfi lter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog se archbase="dc=hku,dc=nl" schemachecking=on type=refreshAndPersist retry="5 5 10 +" olcMonitoring: TRUE olcDbIndex: default pres,eq olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn eq,sub (...) olcDbMaxReaders: 0 olcDbMaxSize: 12147483648 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig Thank you for taking the time to read all this, any remarks on how to get this going will be very much appreciated! Best regards, gerard

1 0

How to enable memberOf overlay with posixGroup?
by MegaBrutal 16 Aug '17

16 Aug '17

Hi all, I've spent days trying to figure out how could I enable the memberOf overlay, and it doesn't seem to be easy for an LDAP-noob. I've read like 50+ tutorials which didn't help me get it working. Use case: I want to have 2 main groups which control access to different services on my network. A "unixusers" which is a minimum to log in to Linux servers (having a hostObject entry for the user is another requirement, which is irrelevant to this question, as I already solved that problem); and a "cloudusers" group which enables log in to my ownCloud instance. The groups should enforce the following rules: – Only users in "cloudusers" should be allowed to log in to ownCloud. – Users in "unixusers" are allowed to log in to a set of Linux servers controlled by "host" (hostObject) entries. – Users not in the "unixusers" group may not log in to any Linux systems, even if they have "host" entries. Problems: – ownCloud complains that the memberOf overlay is not enabled, hence it doesn't let me restrict access to the "cloudusers" group. It would allow any users regardless of any group memberships, which is not acceptable. – I have a similar problem on Linux with PAM: I can't really get it to consider "unixusers" membership for user logins, although I got the "host" entries working correctly, so at least I can already restrict access with that. My guess is that it all boils down to the lack of memberOf overlay. I also figured that memberOf would need groupOfNames groups, while I need posixGroup type groups. I evaluated the possibility to use groupOfNames, but it lacks the necessary gidNumber attribute which is a requirement for Unix groups. But anyway, I can't enable memberOf even for groupOfNames. I can't enable memberOf by any means. My OpenLDAP uses the new configuration method and it completely ignores slapd.conf, so the config must be injected with ldapadd to cn=config. Could you please help me with this? Regards, MegaBrutal

5 6

Re: syncprov
by Quanah Gibson-Mount 15 Aug '17

15 Aug '17

--On Tuesday, August 15, 2017 3:39 PM +0100 Philip Colmer <philip.colmer(a)linaro.org> wrote: > If I am correct and there only needs to be one, what is the best way > to remove the extraneous ones? You'll have to stop the server, slapcat the cn=config DB, delete the extra overlays, and then slapadd the cn=config DB back in. I would suggest adding logic to your process that checks for the existence of the syncprov overlay prior to attempting to add it to the stack. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

syncprov
by Philip Colmer 15 Aug '17

15 Aug '17

I'm adding a third server to an existing multi-server configuration and I think the LDIF files I'm using to configure the replication have some errors in them. dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov The above is a snippet from the LDIF file and I'm concerned that it keeps on adding a new syncprov overlay when there only needs to be one. On the current three-server configuration, there are four instances of syncprov! If I am correct and there only needs to be one, what is the best way to remove the extraneous ones? Thanks. Philip

1 0

Search against multiple databases under
by JOSE L MARTINEZ-AVIAL 10 Aug '17

10 Aug '17

Hello, I'm trying to combine my test openldap (MDB database) with my production AD installation, so I can have the production users access my test systems. In order to do that I've created two databases in my slapd.conf, as follows: ####################################################################### # database definitions ####################################################################### include /usr/local/etc/openldap/slapd-meta-ad-prd.conf include /usr/local/etc/openldap/slapd-mdb.conf The configuration file for the AD connection is as follows: database meta suffix "dc=bsi,dc=test,dc=com" uri "ldap://miadc01.mia.usa.sinvest/dc=bsi,dc=test,dc=com" suffixmassage "dc=bsi,dc=test,dc=com" "dc=mia,dc=usa,dc=sinvest" idassert-bind bindmethod=simple binddn="cn=Test User,cn=users,dc=mia,dc=usa,dc=sinvest" credentials=xxxxx The configurtion file for the MDB is: database mdb maxsize 1073741824 suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # Added by pplu to support root authentication rootpw xxxxxxx # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data/mdb # Indices to maintain index objectClass eq overlay memberof memberof-group-oc groupOfUniqueNames memberof-member-ad uniquemember So the first database uses the sufix "dc=bsi,dc=test,dc=com", and the second one uses "dc=test,dc=com". The idea is that the AD would appear as a branch of the development database. I've found that I can search the AD by using the search DN "dc=bsi,dc=test,dc=com", but if I try to look with DN "dc=test,dc=com", only the test database is searched. The search does not combine both databases. How can I do it? thanks JL

2 1

Re: problem with syncrepl and STARTTLS
by Ryan Tandy 09 Aug '17

09 Aug '17

On Wed, Aug 09, 2017 at 07:47:06PM +0200, r0m5 wrote: >Yes so far "TLS_REQCERT allow" on the PHP applications' OS because the >OpenLDAP consumers certs are still self-signed. > >Indeed I saw #8385 linked in ITS#8427. From my understanding #8385 deals >with certificate validation using libldap. php5-ldap depends on libldap >and the versions of libldap install on our php frontends are old >(jessie...). I'm actually about to propose an update for stretch including that fix along with some others (and will update jessie-backports once it's released for stretch). I hadn't intended to backport it as far as jessie, but I have some other changes pending for jessie as well so I may as well include it. >So I will also make sure that the PHP frontends trust the CA that will >sign the new LDAP consumer's certificates. I guess that should solve the >STARTTLS problems from application to consumer the same way it (looks >like it) solved the STARTTLS problems from consumers to providers. Yes, it should.

1 0

Re: problem with syncrepl and STARTTLS
by Quanah Gibson-Mount 09 Aug '17

09 Aug '17

--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)r0m5.eu> wrote: > > Hello, > > I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of > problem happening only sometimes, and disappearing "by itself". I use > Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. 2.4.40 is 2.5 years old, 5 point releases behind, and had significant known replication issues. I believe there is a build of 2.4.44 in backports for Jessie. I would advise using that instead. As far as debug logging, you would need to use "-d -1" to slapd, rather than attempting to set the loglevel to -1, as some debug logging is only possible via the slapd daemon. But your first step is to move to a current release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 6

Re: SASL EXTERNAL binds and sasl-secprops minssf > 0
by Quanah Gibson-Mount 08 Aug '17

08 Aug '17

--On Saturday, August 05, 2017 3:05 PM -0400 David Hawes <dhawes(a)gmail.com> wrote: > With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS > client auth) bind on a connection succeeds, but subsequent SASL > EXTERNAL binds on the same connection fail with: > > slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): > mechanism too weak for this user: mech EXTERNAL is too weak Please file an ITS for this, thanks. I would think the expected behavior for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS encrypted connection. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ppolicy issues
by r0m5 08 Aug '17

08 Aug '17

Hello ! I have two issues regarding ppolicy. I use debian jessie backports (slapd 2.4.44). 1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext passwords and slapd hashes it before writing in database for security reasons (and slapd can perform password quality checks). But I need exceptions for that. Indeed for some reason I have to use EAP-MD5 and EAP-MD5 makes it mandatory to store cleartext passwords in LDAP. So I would like to find a way to use "olcPPolicyHashCleartext: TRUE" on some OUs, but not on others. Any way to do that ? Maybe setting up a second mdb database with a different ppolicy overlay configuration ("olcPPolicyHashCleartext: FALSE") and the same olcSuffix than the existing database ? A search on the base DN would then need to cover the two databases. 2) syncrepl of (for example) pwdChangedTime. This attribute is not synced to my consumers, even though the schema is imported on the consumer, the module is configured and the overlay is also configured. Syncrepl for attributes non related to ppolicy works fine. Somehow ppolicy is working on the consumers though, since after a failed bindind on the consumer I can see pwdFailureTime on this consumer. Any idea ? (I tried slapd -d -1 but didn't find something relevant, I can paste the resuslts here if needed) Regards, ********* provider # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fb6dde8c dn: olcOverlay={1}ppolicy objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr olcPPolicyHashCleartext: TRUE structuralObjectClass: olcPPolicyConfig entryUUID: 3528350a-0f9a-1037-89da-e5a4ba1189f6 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170807085738Z entryCSN: 20170807085738.529346Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170807085738Z ********* provider # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 295fad94 dn: cn=module{2} objectClass: olcModuleList cn: module{2} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 6e4da4de-0a3e-1037-9174-b1e488f02d8a creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170731131804Z entryCSN: 20170731131804.891811Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170731131804Z ********* consumer # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 4758a296 dn: olcOverlay={0}ppolicy objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=acme,dc=fr olcPPolicyHashCleartext: TRUE structuralObjectClass: olcPPolicyConfig entryUUID: e5a3785a-0d8c-1037-908e-d903a2095e18 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170804181719Z entryCSN: 20170804181719.336420Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170804181719Z ********* consumer # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 d0060305 dn: cn=module{1} objectClass: olcModuleList cn: module{1} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}ppolicy.la structuralObjectClass: olcModuleList entryUUID: e560e800-0d8c-1037-908d-d903a2095e18 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170804181718Z entryCSN: 20170804181718.900179Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170804181718Z ********* consumer olcSyncrepl: {0}rid=2 provider=ldap://ldap-provider-dev.acme starttls=critical tls_reqcert=demand bindmethod=simple binddn="cn=replication,ou=Applications ,dc=acme,dc=fr" credentials=xxx searchbase="dc=acme,dc=fr" schemache cking=off type=refreshAndPersist filter="(objectClass=*)" attrs="*" scope=s ub retry="60 +"

3 2

Re: SASL EXTERNAL binds and sasl-secprops minssf > 0
by David Hawes 08 Aug '17

08 Aug '17

On 7 August 2017 at 11:37, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, August 05, 2017 3:05 PM -0400 David Hawes <dhawes(a)gmail.com> > wrote: > >> With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS >> client auth) bind on a connection succeeds, but subsequent SASL >> EXTERNAL binds on the same connection fail with: >> >> slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): >> mechanism too weak for this user: mech EXTERNAL is too weak > > > Please file an ITS for this, thanks. I would think the expected behavior > for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS > encrypted connection. > ITS filed: http://www.openldap.org/its/index.cgi/Incoming?id=8708;selectid=8708

1 0

Re: ppolicy issues
by Quanah Gibson-Mount 08 Aug '17

08 Aug '17

--On Tuesday, August 08, 2017 8:46 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > r0m5 wrote: >> 1) I use "olcPPolicyHashCleartext: TRUE" so the clients send cleartext >> passwords and slapd hashes it before writing in database for security >> reasons (and slapd can perform password quality checks). > > There's a nasty issue with this configuration option when using > slapo-accesslog: > > If the client sends the clear-text 'userPassword' value but the password > quality check fails and therefore the modify request fails with > constraintViolation the clear-text 'userPassword' value will be written > to accesslog DB. In case of successful modification only the hashed > 'userPassword' value is written to accesslog DB. :-/ Is there an ITS on this? If not, there should be. --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 Configuration issues
by Andrew Findlay 08 Aug '17

08 Aug '17

Please keep the discussion on-list so that others can find it if they have similar problems. On Tue, Aug 08, 2017 at 12:44:25PM +0200, R H wrote: > Subject: Re: Openldap Configuration issues > > No point in changing stuff without knowing what is going on. > > Add this to your config and restart slapd: > > loglevel stats,stats2 > after setting loglevel to stats, stats2 > > Aug 8 05:40:18 docker slapd[2990]: daemon: read active on 14 > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=9 active_threads=0 > tvp=zero > Aug 8 05:40:18 docker slapd[2990]: daemon: epoll: listen=10 active_threads=0 > tvp=zero No - something has set a different log level. You are seeing a lot of connection-management and debug stuff rather than the query and response summaries that you need. You might do better to stop the server and run it manually. Something like this: /usr/sbin/slapd -d stats,stats2 -h ldap:/// -g openldap -u openldap What I am expecting to see looks more like this (from a Cyrus mailbox server using LDAP via saslauthd): Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 BIND dn="cn=saslauthd,dc=ldap,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=103 RESULT tag=97 err=0 text= That shows saslauthd connecting to LDAP and authenticating correctly. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(uid=myusername)" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SRCH attr=dn That is the search to find the user account. Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 ENTRY dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=104 SEARCH RESULT tag=101 err=0 nentries=1 text= That shows the search result: the user entry is "uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND anonymous mech=implicit ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" method=128 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 BIND dn="uniqueIdentifier=1405431085.7365.0,associatedDomain=example.co.uk,ou=domains,dc=example,dc=com" mech=SIMPLE ssf=0 Aug 8 17:48:33 owl slapd[616]: conn=1282270 op=105 RESULT tag=97 err=0 text= Finally the password is checked by binding to LDAP using the account DN and password as credentials. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Openldap Configuration issues
by R H 07 Aug '17

07 Aug '17

Dear All, For the last few days I've been desperately reading official/user made guides in order to properly configure my openldap to allow users to login to a project management webapp (namely Redmine). With that said, please let me share the basic setup of the environment i'm dealing with. Webapplication(s): Redmine, Phpldapadmin LDAP: Openldap After the installation, i took the following steps to re-configure my ldap to reflect better the ldap being used in production (since this whole redmine + ldap isn't in production yet) 1. Stopped slapd service and removed the *cn=config.ldif* from */etc/ldap/slapd.d* 2. Modified */usr/share/slapd/slapd.conf* to this: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args loglevel none modulepath /usr/lib/ldap moduleload back_mdb sizelimit 500 tool-threads 1 backend mdb database mdb suffix "o=testcompany.com" rootdn "cn=admin,o=testcompany.com" directory "/var/lib/tc-ldap" rootpw "password" index objectClass eq index uid eq index ou eq index default eq,sub lastmod on checkpoint 512 30 access to attrs=userPassword,shadowLastChange by dn="cn=admin,o=testcompany.com" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,o=testcompany.com" write by * read 3. Afterwards, *slaptest -f /usr/share/slapd/slapd.conf -F /etc/ldap/slapd.d* which generated my new *cn=config.ldif* 4. Set the appropriate user/group to the new *cn=config.ldif* with *chown -R openldap:openldap /etc/ldap/slapd.d/* 5. Fired up slapd service and checked if the ldap was running or not. Since it was and i could access it with phpldapadmin, i added an *organizationalUnit (ou=sales)*, all the country codes and imported 3000 users (by using *ldapadd*) Now my DIT looks as follows - o=testcompany.com - ou=sales - AD + uid=123456,c=AD,ou=sales,o=testcompany.com + ... which is great, this is exactly the way it should look like, however I've noticed, that *cn=admin,o=testcompany.com <http://testcompany.com>* entry doesn't exists, while it did using the default config after i've installed openldap. 6. In Redmine, I've configured and tested the *ldap authentication*. It is working correctly (it can both connect to my ldap and If i wish to add a new user and choose the before configured ldap authentication for it, i can even choose from the entries that are in my ldap, which is also great) 7. However (this is where my problem is) when i try to log into Redmine with a user that i've just created (with ldap authentication) i always get *Invalid credentials* error (while it works like a charm when i login with any other account, created with *Simple Authentication*) These events led me to believe that the error is in the LDAP configuration. After a few more hours/days of fooling around with the *ACL*s and *dpkg-reconfigure slapd* (and even purging-reinstalling slapd and ldap-utils) i still can not get beyond this point. And one more bit of information, after *dpkg-reconfigure slapd* and creating a few users under the default *dc=example,dc=com*, i can get them to log into Redmine just fine (and even *cn=admin,o=testcompany.com <http://testcompany.com>* shows up...). Below i'll attach a few things that I've tried. I hope someone can aid me with a few tips as to where i got off the trail (somehow i feel that i'm missing the obvious here). What I have tried so far: 1. modify the default slapd.conf file, and repeat the process i've written above 2. create a completely new one 3. a lot of different ways to add/modify the ACL 4. read through a lot of mailing list, similar problems on redmine forums, and openldap mailing lists, still no success (i can paste a lot of links from my .txt if you need it)

3 2

Memory leak on single threaded Windows slapd
by Derrick McKee 07 Aug '17

07 Aug '17

Hi, I am trying to run slapd on windows as a single threaded application. I got it to compile, and run with the mdb backstore. However, it seems like slapd allocates 3 MB for every request, and doesn't free it after the request has been served. Anyone have any idea as to where to start to try to figure this out? Thanks. -- Derrick McKee Ph.D. Student at Purdue University

1 0

Re: mdb broken under OpenBSD
by Howard Chu 06 Aug '17

06 Aug '17

Paul B. Henson wrote: >> From: Howard Chu >> Sent: Friday, August 4, 2017 4:23 AM >> >> Nice work, thanks for the update. > > So 10 of the mdb tests ended up failing; a couple because slapd failed to start, a bunch because ldapadd failed, and one because the script that evidently was executable per the -x test moments before suddenly wasn't found? There doesn't seem to be any log info or other remnants of the tests left over once they are done running to determine why they failed? Unless I missed something; what does one do to check on a test to see why it failed? Thanks… By default, all test output is in the testrun directory. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

SASL EXTERNAL binds and sasl-secprops minssf > 0
by David Hawes 05 Aug '17

05 Aug '17

With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS client auth) bind on a connection succeeds, but subsequent SASL EXTERNAL binds on the same connection fail with: slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak when: sasl-secprops minssf=128 In previous OpenLDAP versions, both the initial and subsequent SASL EXTERNAL binds succeed due to the bug in #8568. This was a misconfiguration on my part (I should have kept the default of 0), but I wonder if the initial SASL bind should also fail. It seems to succeed because tls_ssf is used in connection.c: slap_sasl_external( c, c->c_tls_ssf, &authid ); [1] http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8568;selectid=8568

1 0

Re: mdb broken under OpenBSD
by Howard Chu 05 Aug '17

05 Aug '17

Paul B. Henson wrote: > On Thu, Aug 03, 2017 at 02:20:29PM -0700, Paul B. Henson wrote: > >> From my initial look, mdb_env_create() successfully sets mdb->mi_dbenv, >> it's still valid in mdb_db_open(), but by the time it reaches >> be->be_entry_put in slapadd() it's NULL :(. > > It turned out it was only sometimes NULL. The culprit was actually the local > OpenBSD patch that was added to mdb_db_open() to ensure MDB_WRITEMAP is always > set: > > if ( !(flags & MDB_WRITEMAP) ) { > Debug( LDAP_DEBUG_ANY, > LDAP_XSTRING(mdb_db_open) ": database \"%s\" does not have writemap. " > "This is required on systems without unified buffer cache.\n", > be->be_suffix[0].bv_val, rc, 0 ); > goto fail; > } > > There were two problems with it; first, it accesses the local flags variable > before it is initialized to mdb->mi_dbenv_flags shortly thereafter, so > the value is random and the if block nondeterministically triggers, and > second, it doesn't assign a failure value to rc before it jumps to fail:, > so the function returns successfully but with a closed be. > > mdb has been disabled for a while, so I'm guessing the first issue might > have occurred over time as backend.c changed and the patch was just > blindly updated without testing. The second issue I'm not sure about. So much for OpenBSD's vaunted attention to detail. > > I temporarily tweaked it to always enable MDB_WRITEMAP That would be the simplest approach. > so I could run the > mdb test suite (which doesn't have it enabled for everything) and so far > it seems to be working. > > I would hope that this simple issue isn't why they've had it disabled all > this time, but I guess I'll see what happens with the full test suite > as it progresses. > Nice work, thanks for the update. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: mdb_dbi_open and threads
by Howard Chu 04 Aug '17

04 Aug '17

Hallvard Breien Furuseth wrote: > On 22. mai 2017 14:00, Howard Chu wrote: >> Muhammed Muneer wrote: >>> Hallvard wrote >> >>> "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), >>> thread 1's prospect of using mdb_dbi_open() at all was lost." >>> >>> Yeah with both coexisting. Thats what I thought. > > Sorry, I should have said with _transactions_ #1 and #2 coexisting, > _transaction_ #1's prospect of using mdb_dbi_open() at all was lost. > Transaction #3 in thread #1 can use it if it stared after txn#2 ended. > > Anyway, just forget about being clever with DBIs. LMDB does not support > DBI cleverness, that's one of its trade-offs for speed and simplicity. Exactly. >> If you want to use dbi_open in multiple threads then put it in your own >> wrapper function, protected by a mutex. > > Wait, what? mdb_dbi_open() isn't coded to handle concurrent txns > calling it, regardless of any mutexes the caller has. In particular, > it does not use nor update the environment's numdbs, so the two > transactions could end up creating the same DBI for different DBs. Yes. This is only safe if you also close the dbi in the same txn that opened it. Which you are probably doing, if you are opening and closing on the fly. > >> Naturally you will also have to wrap dbi_close the same way. > > If we did support this, txn_commit() of the txn which used dbi_open() > would also need the mutex. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: mdb broken under OpenBSD
by Howard Chu 04 Aug '17

04 Aug '17

Paul B. Henson wrote: > I was interested in using openldap under OpenBSD; they currently have > mdb disabled as they say it is broken. That OS lacks a unified buffer > cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but > supposedly theoretically it should work with that. I tried running the > mdb tests, and it immediately segfaults: > > Program terminated with signal 11, Segmentation fault. > > 2773 flags |= env->me_flags & MDB_WRITEMAP; > > It looks like mdb_txn_begin is being passed a NULL env? I haven't started > poking around yet to see why that might be, but I thought I'd just toss this > out there in case an expert had a thought before I spent a lot of time on > it :). Thanks... OpenBSD's lack of a unified buffer cache is a pretty glaring deficiency, yes. Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it. For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

mdb broken under OpenBSD
by Paul B. Henson 03 Aug '17

03 Aug '17

I was interested in using openldap under OpenBSD; they currently have mdb disabled as they say it is broken. That OS lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but supposedly theoretically it should work with that. I tried running the mdb tests, and it immediately segfaults: Program terminated with signal 11, Segmentation fault. 2773 flags |= env->me_flags & MDB_WRITEMAP; It looks like mdb_txn_begin is being passed a NULL env? I haven't started poking around yet to see why that might be, but I thought I'd just toss this out there in case an expert had a thought before I spent a lot of time on it :). Thanks... #0 0x000016210db057c5 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x16210df6fec0) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/../../../libraries/libl mdb/mdb.c:2773 txn = (MDB_txn *) 0xf ntxn = (MDB_ntxn *) 0x0 rc = 0 size = 0 tsize = 32639 #1 0x000016210db224df in mdb_tool_entry_put (be=0x1623ccbdd200, e=0x16235a80c008, [47/9401] text=0x7f7ffffeeb90) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/tools.c:624 rc = 0 mdb = (struct mdb_info *) 0x1623c3580000 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0x0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\0' <repeats 255 times>} __func__ = "mdb_tool_entry_put" #2 0x000016210dac8329 in slapadd (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/slapadd.c:456 textbuf = '\0' <repeats 255 times> textlen = 256 erec = {e = 0x16235a80c008, lineno = 1, nextline = 18} bvtext = {bv_len = 256, bv_val = 0x7f7ffffeebd0 ""} thr = 0x16210dd8cd78 id = 140187732470848 prev = (Entry *) 0x0 ldifrc = 1 rc = 0 stat_buf = {st_mode = 4294896512, st_dev = 32639, st_ino = 140187732470584, st_nlink = 990767968, st_uid = 5667, st_gid = 0, st_rdev = 0, st_atim = {tv_sec = 179931522, tv_nsec = 48}, st_mtim = {tv_sec = 24342436749856, tv_nsec = 24341375494144}, st_ctim = { tv_sec = 24343378665241, tv_nsec = 140187732470664}, st_size = 0, st_blocks = 140187732470664, st_blksize = 990767968, st_flags = 5667, st_gen = 0, __st_birthtim = {tv_sec = 179915312, tv_nsec = 48}} #3 0x000016210da02d7a in main (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/main.c:664 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 8 waitfds = {331804096, 5667} g_argc = 8 g_argv = (char **) 0x7f7ffffeee58 configfile = 0x0 configdir = 0x0 serverName = 0x7f7ffffef122 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x16210ddb6ec5 "" l = 1 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __func__ = "main"

1 0

Re: searching userPassword value
by Howard Chu 03 Aug '17

03 Aug '17

Quanah Gibson-Mount wrote: > --On Wednesday, August 02, 2017 6:28 PM -0400 David Magda > <dmagda(a)ee.ryerson.ca> wrote: > >> Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. >> >> Thanks for any info. > > userPassword is base64 encoded, so no, you can't do that. False. The base64 encoding only happens in the ldapsearch tool just before it prints the result on stdout. The userPassword schema definition has no substring matching rule. And you should already know to check the schema definition for questions like this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: searching userPassword value
by Quanah Gibson-Mount 03 Aug '17

03 Aug '17

--On Wednesday, August 02, 2017 6:28 PM -0400 David Magda <dmagda(a)ee.ryerson.ca> wrote: > Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. > > Thanks for any info. userPassword is base64 encoded, so no, you can't do that. You could find all the values, and then decode them. Or you could decode a specific value for a given user to see what sort of hash it is using. I'd probably use perl or python. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

searching userPassword value
by David Magda 02 Aug '17

02 Aug '17

Hello, Is there a way to search the value of the userPassword attribute? Specifically I’m hoping to determining to whether it begins with {SHA}, {CRYPT}, etc. Using the (olc)rootdn account is fine; it doesn’t have to be a regular user as this would be a rare/manual operational need. Doing an “ldapsearch […] ‘(userpassword={SHA}*'" gets zero results. Thanks for any info. Regards, David

1 0

Blacklists of simple values in LDAP attribute constraints overlay?
by Florian Best 02 Aug '17

02 Aug '17

Hello, I am searching for a way to add an LDAP constraint on attributes which prevents setting specific values. For example, I want to prevent that the attribute "uid" is equal to (case insensitive) "foo" or "bar". Using the manpage from https://linux.die.net/man/5/slapo-constraint it seems not possible, I tried a lot of things like: constraint_attribute uid set "this/uid & ([foo])" constraint_attribute uid set "this/uid & [foo]" constraint_attribute uid uri ldap:///dc=school,dc=local?forbidden?sub?(objectClass=forbiddenUsernames) constraint_attribute uid regex ^[^f][^o][^o]*$ Even if they were working (they don't) I needed to reverse the whole constraint because this would only allow me to add a whitelist while I want to add a blacklist. (Best would be If I could just add a "!" before the attribute contsraint.) I hope there is something which could help me. Best regards Florian -- Florian Best Open Source Software Engineer Univention GmbH be open Mary-Somerville-Str.1 28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 best(a)univention.de http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

2 6

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 27 Jul '17

27 Jul '17

--On Friday, June 30, 2017 8:32 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: >> And what does the master say? >> > > same thing: > > slapd[38004]: conn=30116 op=3 SEARCH RESULT tag=101 err=53 nentries=0 > text=consumer state is newer than provider! It sounds like your replica was not configured correctly initially and self-generated its own CSN that is newer than the one on the provider. It would be interesting to make a modification on the provider so that its CSN is updated (and thus has one newer than on the consumer). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

[Q] "selective" ACL
by Zeus Panchenko 26 Jul '17

26 Jul '17

hi, I'm trying to configure a not complex (as I believe) ACL ... but have some difficulties I have two posixGroup groups cn=admins,ou=group,dc=foo cn=coadmins,ou=group,dc=foo my users resides in ou=People,dc=foo so, in subtree ou=People,dc=foo I need to allow anything to admins (and it is not difficult of course) for example this works for me: access to dn.subtree="ou=People,dc=foo" by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage by self write by users read by * break but in addition I need to allow my coadmins to do the same things except manipulations upon the objects which belong to admins ( ...anyobject,uid=adminuser,ou=People,dc=foo ) so, the question is: how? (if it is possible at all) :( please, advise -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

2 2

Sometimes openldap messages are logged in incorrect order
by Amit 26 Jul '17

26 Jul '17

Hello, I find sometimes order of event in openldap logs as: BIND RESULT ACCEPT SRCH base SRCH attr= SEARCH RESULT closed Configured rsyslog as: $template myTemplate,"%timegenerated:::date-rfc3339% %timereported:::date-rfc3339% %msg%\n" local4.* /var/log/rsyslog.log;myTemplate But I believe correct order should be: Accept Bind result srch base unbind closed What cant be the reason, is it related to openldap logging mechanism or Logger rsyslog. -- Thanks Amit

3 4

Re: Antw: Re: Limiting Search Results By Group Membership
by Howard Chu 25 Jul '17

25 Jul '17

Ulrich Windl wrote: >>>> Howard Chu <hyc(a)symas.com> schrieb am 25.07.2017 um 14:27 in Nachricht > <48d74363-2f0a-739f-d719-515e1fe14997(a)symas.com>: >> Ulrich Windl wrote: >>> BTW: Is there an LDAP query to get the schema name for an object class? >>> I can list objectclasses and schematas, but I miss the link between those. >> >> You can search under cn=schema,cn=config using filter >> (olcObjectClasses=*<objectclass name>*) > > Hi! > > Thanks, but I don't quite get it: If I'm trying for "ipService" (which is known), I get an empty result: > > # ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=schema,cn=config' -s one '(olcObjectClasses=ipService)' '* +' > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > # extended LDIF > # > # LDAPv3 > # base <cn=schema,cn=config> with scope oneLevel > # filter: (olcObjectClasses=ipService) > # requesting: * + > # > > # search result > search: 2 > result: 0 Success > > Can you give a concrete example, maybe? Pay attention to details. The filter I specified was ( * <objectclass name> * ) - a substring filter. The filter you used was an exact match filter, which obviously doesn't match anything. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Antw: Re: Limiting Search Results By Group Membership
by Howard Chu 25 Jul '17

25 Jul '17

Ulrich Windl wrote: > BTW: Is there an LDAP query to get the schema name for an object class? > I can list objectclasses and schematas, but I miss the link between those. You can search under cn=schema,cn=config using filter (olcObjectClasses=*<objectclass name>*) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Sometimes openldap messages are logged in incorrect order
by Howard Chu 25 Jul '17

25 Jul '17

Amit wrote: > Hello, > > I find sometimes order of event in openldap logs as: > BIND > RESULT > ACCEPT > SRCH base > SRCH attr= > SEARCH RESULT > closed > > Configured rsyslog as: > $template myTemplate,"%timegenerated:::date-rfc3339% > %timereported:::date-rfc3339% %msg%\n" > local4.* /var/log/rsyslog.log;myTemplate > > But I believe correct order should be: > Accept > Bind > result > srch base > unbind > closed > > What cant be the reason, is it related to openldap logging mechanism or Logger > rsyslog. Sounds like an rsyslog issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Limiting Search Results By Group Membership
by Douglas Duckworth 24 Jul '17

24 Jul '17

Thank you both for your guidance. I will try this now. Doug Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Mon, Jul 24, 2017 at 10:31 AM, Michael Ströder <michael(a)stroeder.com> wrote: > Douglas Duckworth wrote: > > If OpenLDAP can run with this schema then why wasn't support for this > feature created? > > There is a contrib/ overlay but I'd not use it. > > > What's the recommend schema? > > Simply start with groupOfNames. > > Ciao, Michael. > > > On Jul 21, 2017 1:44 PM, "Quanah Gibson-Mount" <quanah(a)symas.com > > <mailto:quanah@symas.com>> wrote: > > > > --On Friday, July 21, 2017 2:24 PM -0400 Douglas Duckworth > > <dod2014(a)med.cornell.edu <mailto:dod2014@med.cornell.edu>> wrote: > > > > > > > Am I rfc2307 or rfc2307bis? According to sssd-ldap man page: > > > > Per nis.schema: > > > > # Definitions from RFC2307 (Experimental) > > # An Approach for Using LDAP as a Network Information Service > > > > > > so it is RFC2307 as opposed to RFC2307bis. Neither schema has ever > made it > > past experimental. > > > > --Quanah > >

1 1

Re: Limiting Search Results By Group Membership
by Douglas Duckworth 24 Jul '17

24 Jul '17

If OpenLDAP can run with this schema then why wasn't support for this feature created? What's the recommend schema? On Jul 21, 2017 1:44 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: > --On Friday, July 21, 2017 2:24 PM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > > Am I rfc2307 or rfc2307bis? According to sssd-ldap man page: > > Per nis.schema: > > # Definitions from RFC2307 (Experimental) > # An Approach for Using LDAP as a Network Information Service > > > so it is RFC2307 as opposed to RFC2307bis. Neither schema has ever made it > past experimental. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > QjNwZbNvK3tkFCecwXFhz1ywKJbFr_zOd4L5bNHwKpc&s= > M9eRNUisYljobqAKHQaLfans5QZ9DGU5Srnk8kR6mso&e= > > >

2 1

Re: Limiting Search Results By Group Membership
by Quanah Gibson-Mount 24 Jul '17

24 Jul '17

--On Monday, July 24, 2017 10:23 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > If OpenLDAP can run with this schema then why wasn't support for this > feature created? ldap groups have a specific meaning and it has nothing to do with either of those schemas. The documentation is clear on what's required to use the limits feature with groups, which is a DN type attribute such as "member". I'm not sure what "feature" you feel support wasn't created for. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ppolicy and controls
by Côme Chilliet 24 Jul '17

24 Jul '17

Hello, I’m trying to understand how to use controls and EXOP with ppolicy overlay. I can get controls in the result from bind to get info like expired password. I can use an exop to change the password in which case an invalid password will get refused, but I’m not sure how to get the ppolicy reason for the refusal. There is ldap_parse_passwordpolicy_control but I don’t know how to get a control object to give to it. ldap_passwd_s does not return a result object for which to search controls in. It does take serverctrls and clientctrls as parameters but looking at the code it seems serversctrls is an input parameter, I’m not sure what it can be useful for. And clientctrls seems ignored, is it unused or deprecated? Côme

1 0

Re: Limiting Search Results By Group Membership
by Quanah Gibson-Mount 24 Jul '17

24 Jul '17

--On Friday, July 21, 2017 2:24 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > Am I rfc2307 or rfc2307bis? According to sssd-ldap man page: Per nis.schema: # Definitions from RFC2307 (Experimental) # An Approach for Using LDAP as a Network Information Service so it is RFC2307 as opposed to RFC2307bis. Neither schema has ever made it past experimental. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

EXOPs for PHP LDAP
by Côme Chilliet 22 Jul '17

22 Jul '17

Hello, I’m currently working on a PHP RFC to add EXOP handling to php-ldap. The draft is here: https://wiki.php.net/rfc/ldap_exop You are welcome to comment on any aspect of the RFC, but I would especially want to know: - Which are the EXOPs actually used by people out there? - Is there any EXOP using the responseName field? In the RFCs I read there is always something like «an ExtendedResponse where the responseName field is absent» or «The responseName field contains the same string as that present in the request.» Côme

2 7

Re: Limiting Search Results By Group Membership
by Douglas Duckworth 21 Jul '17

21 Jul '17

In the old openldap-servers-2.2.13-4 from which I copied this data: /etc/openldap/schema/nis.schema objectclass ( 1.3.6.1.1.1.2.2 NAME 'posixGroup' SUP top STRUCTURAL DESC 'Abstraction of a group of accounts' MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) ) attributetype ( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) In /etc/openldap/schema/core.schema I do see: attributetype ( 2.5.4.31 NAME 'member' DESC 'RFC2256: member of a group' SUP distinguishedName ) As well as: objectclass ( 2.5.6.9 NAME 'groupOfNames' DESC 'RFC2256: a group of names (DNs)' SUP top STRUCTURAL MUST ( member $ cn ) MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) ) Am I rfc2307 or rfc2307bis? According to sssd-ldap man page: ldap_group_member (string) The LDAP attribute that contains the names of the group´s members. Default: memberuid (rfc2307) / member (rfc2307bis) I am currently using memberuid obviously so my clients can talk to the old server. Thanks so much for your needed assistance! Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Fri, Jul 21, 2017 at 12:23 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, July 21, 2017 10:53 AM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > > limits > > group/posixGroup/memberUid="cn=admins,ou=group,dc=server,dc=domain" > > size=unlimited time=unlimited > > > > Though I am still hitting the limit. > > Hi Douglas, > > It would probably be worthwhile to dig into LDAP schema to understand > attribute definitions, matching rules, etc. > > To start, memberUid is a string type. It's not a DN type: > > attributetype ( 1.3.6.1.1.1.1.12 NAME 'memberUid' > EQUALITY caseExactIA5Match > SUBSTR caseExactIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > As opposed to member, which is specifically a DN type: > > attributetype: ( 2.5.4.31 NAME 'member' > DESC 'RFC2256: member of a group' > SUP distinguishedName ) > > attributetype: ( 2.5.4.49 NAME 'distinguishedName' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > kbjP16BBt5vXdPM9Whbvm854h6iISbROyp41L0OQ2lw&s=mC1OpgC- > KwREoe7aDfE6We28klGIEg6GvZBSzx-DiQE&e= > > >

1 0

Re: Limiting Search Results By Group Membership
by Quanah Gibson-Mount 21 Jul '17

21 Jul '17

--On Friday, July 21, 2017 10:53 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > limits > group/posixGroup/memberUid="cn=admins,ou=group,dc=server,dc=domain" > size=unlimited time=unlimited > > Though I am still hitting the limit. Hi Douglas, It would probably be worthwhile to dig into LDAP schema to understand attribute definitions, matching rules, etc. To start, memberUid is a string type. It's not a DN type: attributetype ( 1.3.6.1.1.1.1.12 NAME 'memberUid' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) As opposed to member, which is specifically a DN type: attributetype: ( 2.5.4.31 NAME 'member' DESC 'RFC2256: member of a group' SUP distinguishedName ) attributetype: ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 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: Limiting Search Results By Group Membership
by Douglas Duckworth 21 Jul '17

21 Jul '17

Thanks. Yes, very helpful. For the group that lists our accounts I now have full DN dn: cn=admins,ou=group,dc=server,dc=domain objectClass: posixGroup objectClass: top cn: admins memberUid: uid=user,ou=accounts,dc=server,dc=domain slapd.conf: limits group/posixGroup/memberUid="cn=admins,ou=group,dc=server,dc=domain" size=unlimited time=unlimited Though I am still hitting the limit. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Wed, Jul 19, 2017 at 6:25 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, July 18, 2017 4:32 PM -0400 Douglas Duckworth > <dod2014(a)med.cornell.edu> wrote: > > ># admins, group, ldap.server > > dn: cn=admins,dc=blah > > objectClass: posixGroup > > objectClass: top > > cn: admins > > memberUid: admin1 > > memberUid: admin2 > > > > Do you have any insight into what could be causing this behavior? I > > have not found the answer yet through extensive searching of the > > internets. > > Hi Douglas, > > The answer lies in the slapd.conf(5) man page, in the description of the > "limits" directive, specifically in this portion: > > "sets the limits for any DN listed in the values of the at attribute" > > memberUID does not contain a DN, therefore it cannot be used. Hope that > helps! > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.symas.com&d=DwIFaQ&c=lb62iw4YL4RFalcE2hQUQealT9- > RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= > 91FmzFy5LT0oV9_Olhg0-lXej0TEADB8w4Tft72zqXs&s= > rnsVibsarNFQ1327v29L487KiPFGapoLz4PZ55l7Hsc&e= > > >

1 0

Re: OpenLDAP server sizing
by Quanah Gibson-Mount 21 Jul '17

21 Jul '17

--On Wednesday, July 19, 2017 7:18 PM +0000 "Edgar Sanchez Arenas (edgasanc)" <edgasanc(a)cisco.com> wrote: > > > Hello, > > > > Is there a guide to do server sizing (CPU, memory, HD) for OpenLDAP? Hi Edgar, What database backend technology do you plan on using. Do you know how much disk space your database will consume? How many anticipated clients? Anticipated read & write rate? etc. Generally, if you have slapd-mdb as your backend, then you want your RAM to be greater than the database size for optimal performance. For HD, it's generally recommended to use SSD. CPU's will depend on your anticipated read etc rates. I.e., substantially more information is necessary to really give any solid advice. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Configuring OpenLDAP with a custom schema instead of default schemas
by Jon Smark 20 Jul '17

20 Jul '17

Hi, I'm new to OpenLDAP and I'm finding it hard to perform the initial configuration (a lot of the information I find online seems to pertain only to old versions of OpenLDAP, which used a different configuration system). Anyway, I have defined a schema file with the custom attributes and object classes relevant to my domain. Starting from a fresh installation of OpenLDAP 2.4.42 running on Ubuntu 16.04, I want to configure my Slapd server to *only* consider my schema file and to ignore all the other schemas it's configured to use by default. I thought it would be as simple as removing the old /etc/ldap/slapd.d and replacing it with the output of slaptest applied to my schema file. This doesn't work, unfortunately, because slapd refuses to start afterwords. I apologize if this question seems basic, but I'm stuck on this very first step and I've been unable to find an up-to-date tutorial on how to configure a recent OpenLDAP server from scratch (ie, without all the default schemas). Thanks in advance for your kind help! Regards, Jon

6 6

Re: Limiting Search Results By Group Membership
by Quanah Gibson-Mount 20 Jul '17

20 Jul '17

--On Tuesday, July 18, 2017 4:32 PM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: ># admins, group, ldap.server > dn: cn=admins,dc=blah > objectClass: posixGroup > objectClass: top > cn: admins > memberUid: admin1 > memberUid: admin2 > > Do you have any insight into what could be causing this behavior? I > have not found the answer yet through extensive searching of the > internets. Hi Douglas, The answer lies in the slapd.conf(5) man page, in the description of the "limits" directive, specifically in this portion: "sets the limits for any DN listed in the values of the at attribute" memberUID does not contain a DN, therefore it cannot be used. Hope that helps! 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: multi-value attribute rejected
by Quanah Gibson-Mount 19 Jul '17

19 Jul '17

--On Wednesday, July 19, 2017 7:51 PM +0100 Brad <braduk1973(a)gmail.com> wrote: > > > Thanks for the replies Michael and Quanah, appreciated. > > Here's some log output showing the content of one of the failed entries: > > cACertificate;binary: 308204423082032AA00302010202010... > cACertificate;binary: 3082039C30820284A00302010202010... > > Looks like the repeated cACertificate attributes do actually have > different values. May depend on the verification routines for CACertificate binary data. Do the two CA's have the same subject line? I haven't dug into the code yet to see how it does the comparison for these values, so it could be way off base. > (Note: apologies for any duplicate messages, I'm having issues getting my > posts to register with the mailing list) The list is moderated. It may just take a bit for a moderator to approve. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

OpenLDAP server sizing
by Edgar Sanchez Arenas (edgasanc) 19 Jul '17

19 Jul '17

Hello, Is there a guide to do server sizing (CPU, memory, HD) for OpenLDAP? Thank you, Edgar Sanchez

1 0

Limiting Search Results By Group Membership
by Douglas Duckworth 18 Jul '17

18 Jul '17

Hi Everyone, I am building a new LDAP v 2.4 cluster. We do not allow anonymous binds and set "sizelimit 1" for all users except our service account used for binding. limits dn.exact="uid=important,ou=sa,dc=blah" size=unlimited time=unlimited provides the bind account unlimited results. However, for group members, I am still hitting the "sizelimit 1" when trying: limits group/posixGroup/memberUid="cn=admins,dc=blah" size=unlimited time=unlimited Our group entry in LDAP: # admins, group, ldap.server dn: cn=admins,dc=blah objectClass: posixGroup objectClass: top cn: admins memberUid: admin1 memberUid: admin2 >From reading the slapd.conf man page, it seems we're not using the default objectclass "groupOfNames," or attribute "member," however when I use the defaults, or the above which exist in our directory, I still hit "sizelimit 1." Of course using dn.exact for our individual accounts works, though I don't want to touch slapd.conf every time we hire someone. Do you have any insight into what could be causing this behavior? I have not found the answer yet through extensive searching of the internets. Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690

1 0

Re: multi-value attribute rejected
by Brad 17 Jul '17

17 Jul '17

Thanks for the replies. Here's some log output showing the content of one of the failed entries: 2017-07-13 12:00:15,864 SEVERE [com.example.ldap.LdapUtils] (113,pool-6-thread-20) Failed to add following properties to uniqueIdentifier=a18d33ebf8ecda02336b1e10d850ba56:- businessCategory: PYCJ7ERc... objectClass: certificateData objectClass: top uniqueIdentifier: a18d33ebf8ecda... cACertificate;binary: 308204423082032AA00302010202010... cACertificate;binary: 3082039C30820284A00302010202010... createDate: 20170713120015+0100 encryptedObject: 00085341414B5... Looks like the repeated cACertificate attributes do actually have different values. On 12 July 2017 at 21:09, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, July 10, 2017 11:11 PM +0100 Brad <braduk1973(a)gmail.com> > wrote: > > The error seems pretty straight forward: > > Caused by: javax.naming.directory.AttributeInUseException: [LDAP: error >> code 20 - cACertificate;binary: value #0 provided more than once]; >> > > I.e., you've provided the exact same value more than once in your write > op. For example, you'd see a similar failure with: > > > dn: <blah> > changetype:modify > add: sn > sn: smith > sn: smith > > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Elliptic Curve support in 2.4 branch
by Howard Chu 15 Jul '17

15 Jul '17

Abdelkader Chelouah wrote: > Elliptic Curve support for OpenSSL was added in master branch 4 years ago > (ITS#7595). Is there any plan to backport EC support for OpenSSL in 2.4 branch ? OpenLDAP 2.4 is feature-frozen. All new features are 2.5 only. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Index Alias Attribute
by Josh Catana 15 Jul '17

15 Jul '17

I've been noticing slapd slow responsive time as my environment has been growing. Running on sles11sp3 openldap2-2.4.26-0.62.2 BDB backend. We heavily rely on aliases to different OUs to manage access to different environments, prod/dev/qa/etc. I know I should probably update the backend, but this isn't what the question is about. Looking at what it's doing it spending a lot of time with bld_idl_union in the BDB backend. Is this because it has to join aliases to actual CNs? Can I index the alias attribute and if I do would it help performance? Thanks.

2 3

Re: Openldap freeze after sometime
by Quanah Gibson-Mount 14 Jul '17

14 Jul '17

--On Thursday, July 13, 2017 12:28 PM +0000 scn_73(a)yahoo.com wrote: > > > Hi all, > > > Openldap freeze after sometime it's restart. Ldasearch queries keep > hanging with no result. OpenLDAP version? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Index Alias Attribute
by Quanah Gibson-Mount 14 Jul '17

14 Jul '17

--On Thursday, July 13, 2017 11:35 AM -0400 Josh Catana <jcatana(a)gmail.com> wrote: > Running on sles11sp3 openldap2-2.4.26-0.62.2 > BDB backend. Hm: OpenLDAP 2.4.26 Release (2011/06/30) OpenLDAP 2.4.45 Release (2017/06/01) Getting a bit crufty there. ;) > We heavily rely on aliases to different OUs to manage access to different > environments, prod/dev/qa/etc. Expand on what you mean by aliases, please. In general, using aliases in LDAP is a bad idea. > I know I should probably update the backend, but this isn't what the > question is about. back-mdb is awful with aliases (See <http://www.openldap.org/its/index.cgi/?findid=7657>), so I'm not sure changing backends would help. You may be hitting <http://www.openldap.org/its/index.cgi/?findid=7743>, there was no further follow up on it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Stopping pagination
by Côme Chilliet 13 Jul '17

13 Jul '17

Hello, Once a pagination server controls is set with ldap_set_option, it seems impossible to cancel pagination by sending a pagination control with 0 as pagesize. What I mean is calling ldap_set_option to set a pagination control (let’s say page size is 4), then starting a search, then calling ldap_set_option to set the pagination control with page size of 0 (and with the cookie returned by the search) Then trying to start new search will return 0 entries. From what I understood in https://www.ietf.org/rfc/rfc2696.txt I thought a page size of 0 would disable pagination but it does not seem to work. Am I missing something? Côme

2 3

Openldap freeze after sometime
by scn_73＠yahoo.com 13 Jul '17

13 Jul '17

Hi all, Openldap freeze after sometime it's restart. Ldasearch queries keep hanging with no result. Earlier this use to be because of ocks max reached. Now i see they are fine but i doubt on Lock requests not available due to conflicts. Please support me to find out the cause. slapd_db_stat -c -h . 91 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 8000 Maximum number of locks possible 1500 Maximum number of lockers possible 12500 Maximum number of lock objects possible 21 Number of current locks 26 Maximum number of locks at any one time 91 Number of current lockers 91 Maximum number of lockers at any one time 17 Number of current lock objects 26 Maximum number of lock objects at any one time 15M Total number of locks requested (15273903) 15M Total number of locks released (15025934) 0 Total number of locks upgraded 5 Total number of locks downgraded 166706 Lock requests not available due to conflicts, for which we waited 247948 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 3MB 752KB The size of the lock region 3385698 The number of region locks that required waiting (15%) - Sachin

1 0

Re: LMDB persistent snapshots
by Howard Chu 13 Jul '17

13 Jul '17

Michael Conrad wrote: > On 07/10/2017 03:28 PM, Howard Chu wrote: >> Michael Conrad wrote: >>> On 07/10/2017 12:16 PM, Howard Chu wrote: >>>> Michael Conrad wrote: >>>>> Hi, I'm scoping out my options for databases that support snapshotting. >>>>> From what I've read so far, this is a natural feature of LMDB, >>>> >>>> Not really. The persistent state only records the 2 most recent transactions. >>> >>> Hm, well so much for that idea ;-) But could you clarify what would >>> happen in a scenario like: >>> >>> Proc1: Begin Read Transaction t1 >>> Proc2: Write Transaction t2 >>> Proc2: Write transaction t3 >>> Proc3: Begin Read Transaction t4 >>> Proc2: Write Transaction t5 >>> Proc2: Write Transaction t6 >>> >>> After those steps, are process 1 and process 3 still able to continue >>> reading their data, and is all the data they see consistent with the state >>> of the database at the time they began the transaction? >> >> Yes. They each retain an in-memory copy of the DB metadata at the start of >> their transaction, and none of the pages they require can be reused by any >> write transactions. >> > > So, if I found a way to serialize the metadata being held by the transaction, > and maintain the lock on the pages, then in theory I could re-load the > transaction later to see the historic state? You would need to keep process 1 and process 3 alive, to maintain their locks. > And the downside to attempting > this would be that (assuming an idle database at the start of the read > transaction) *no* pages would get garbage collected at all for a long as the > lock was held? Correct. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: multi-value attribute rejected
by Quanah Gibson-Mount 12 Jul '17

12 Jul '17

--On Monday, July 10, 2017 11:11 PM +0100 Brad <braduk1973(a)gmail.com> wrote: The error seems pretty straight forward: > Caused by: javax.naming.directory.AttributeInUseException: [LDAP: error > code 20 - cACertificate;binary: value #0 provided more than once]; I.e., you've provided the exact same value more than once in your write op. For example, you'd see a similar failure with: dn: <blah> changetype:modify add: sn sn: smith sn: smith --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

multi-value attribute rejected
by Brad 12 Jul '17

12 Jul '17

Hi all, I'm testing some Java software which stores certificates in LDAP. Previously it has used OpenDJ/OpenDS for LDAP storage but we now have a requirement to run with OpenLDAP in Docker. Everything is working apart from a certificate import which attempts to create an LDAP entry with a repeating attribute. Here's the Java stack trace: Caused by: javax.naming.directory.AttributeInUseException: [LDAP: error code 20 - cACertificate;binary: value #0 provided more than once]; remaining name 'uniqueIdentifier=20d743cf8f62c4186365107d61d65db3' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3120) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx .java:3082) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx .java:2888) at com.sun.jndi.ldap.LdapCtx.c_bind(LdapCtx.java:423) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_bind( ComponentDirContext.java:299) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.bind( PartialCompositeDirContext.java:217) We have some other certificates which are imported without error but those only have a single "cACertificate" attribute. As I understand it, the default cardinality for attributes in OpenLDAP is MULTI-VALUE. I've checked the schema and it's not being specified as SINGLE-VALUE so I'm a bit confused as to why it's being rejected. If I could get some advice on possible causes & solutions that would be very much appreciated. I've done lots of googling and searched the list archives but so far nothing I've found seems relevant to the issue I'm seeing. Thanks, Brad.

2 1

Re: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 12 Jul '17

12 Jul '17

--On Wednesday, July 12, 2017 12:04 PM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > On Wed, Jul 12, 2017 at 05:57:51PM +0000, Jon C Kidder wrote: >> I then see an fopen for this file >> /appl/openldap/etc/openldap/tls/3a89cd48.0. I have no idea where this >> file name came from. > > http://www.openldap.org/doc/admin24/tls.html#TLS_CACERTDIR%20%3Cpath%3E > > https://www.openssl.org/docs/man1.1.0/apps/c_rehash.html If there is nothing in his code OR ~/.ldaprc, system ldap.conf, etc, referencing the TLS_CACERTDIR then it seems there's a bug, since it should only be trying to find the CA Cert hash if that's been set. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 12 Jul '17

12 Jul '17

--On Saturday, July 08, 2017 4:53 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > I vaguely remember there were bugs in back-ldap/back-meta ignoring TLS > options. The work-around back then was to set env var LDAPTLS_CACERT and > friends when starting slapd to let libldap pick up the TLS options from > env. > > Should be fixed in recent releases OpenLDAP though. Ha, one of the few times I failed to ask what version of OpenLDAP was being used... Jon, what OpenLDAP release are you running? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Re: olcGlobal vs. olcFrontendConfig
by Howard Chu 12 Jul '17

12 Jul '17

Michael Ströder wrote: > HI! > > I have to admit that when writing a static slapd.conf I do not make any distinction > regarding global config section and frontend config section. > > So I wonder which criteria are applied to determine whether a parameter is put into > cn=config (olcGlobal) or olcDatabase={-1}frontend (olcFrontendConfig) when converting > slapd.conf to dynamic config. In OpenLDAP 2.3 most global parameters were put into olcGlobal. We moved parameters into olcFrontendConfig in OpenLDAP 2.4 whenever we found an item that might depend on a loadable module, since olcModules are processed after olcGlobal. The parser still accepts these items in olcGlobal, to retain compatibility with configs migrated from 2.3, but in freshly generated configs, the 2.4 olcGlobal will omit them. > Looking at a concrete configuration it does not make sense to me to put attribute > olcPasswordHash into olcDatabase={-1}frontend while putting > olcPasswordCryptSaltFormat into cn=config. There could even be conflicting values in both > entries. A salt format is just a plain string, so it has no particular dependencies. A hash requires actual code to implement it, and may depend on olcModule. > > Background: I'd like to determine which password hash scheme and salt format is > configured by searching in back-config. > > Ciao, Michael. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

olcGlobal vs. olcFrontendConfig
by Michael Ströder 12 Jul '17

12 Jul '17

HI! I have to admit that when writing a static slapd.conf I do not make any distinction regarding global config section and frontend config section. So I wonder which criteria are applied to determine whether a parameter is put into cn=config (olcGlobal) or olcDatabase={-1}frontend (olcFrontendConfig) when converting slapd.conf to dynamic config. Looking at a concrete configuration it does not make sense to me to put attribute olcPasswordHash into olcDatabase={-1}frontend while putting olcPasswordCryptSaltFormat into cn=config. There could even be conflicting values in both entries. Background: I'd like to determine which password hash scheme and salt format is configured by searching in back-config. Ciao, Michael.

1 0

Re: Query on ldap sasl bind
by Quanah Gibson-Mount 11 Jul '17

11 Jul '17

--On Tuesday, July 11, 2017 9:13 PM +0530 Nishanth Nagendra <nishanth.amogh(a)gmail.com> wrote: > I was getting something like this above where there is a part of the > packet shown as unknown header. I am suspecting that wireshark is not > recognizing this or this is again a different problem. Look forward to > your feedback. Honestly no idea... I've never used wireshark to debug the GSSAPI exchange with OpenLDAP. And it's been over a decade since I last played writing a client with SASL/GSSAPI & OpenLDAP. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Query on ldap sasl bind
by Nishanth Nagendra 11 Jul '17

11 Jul '17

Hello Quanah, Thank you very much for your email. It worked for me (I passed GSSAPI as the string), dn as NULL and I could now see in the packet capture that an sasl bind request is being sent out using GSSAPI. Below is the snapshot. Lightweight Directory Access Protocol LDAPMessage bindRequest(1) "<ROOT>" sasl messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: authentication: sasl (3) sasl mechanism: GSSAPI credentials: 6d797077 GSS-API Generic Security Service Application Program Interface Unknown header (class=1, pc=1, tag=13) <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Why unknown ? [Expert Info (Warn/Protocol): Unknown header (class=1, pc=1, tag=13)] [Unknown header (class=1, pc=1, tag=13)] [Severity level: Warn] [Group: Protocol] I was getting something like this above where there is a part of the packet shown as unknown header. I am suspecting that wireshark is not recognizing this or this is again a different problem. Look forward to your feedback. regards, Nishanth On Mon, Jul 10, 2017 at 11:23 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, July 10, 2017 9:02 PM +0530 Nishanth Nagendra < > nishanth.amogh(a)gmail.com> wrote: > >> >> From the openldap source code, I notice that sasl.c file has a constant >> LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I >> tried to pass a non NULL value in my function call to ldap_sasl_bind in >> the third parameter expecting it to hit the other code path to initiate >> SASL bind with credentials but the library does not seem to allow it and >> returns error from sasl bind. >> > > As clearly noted in the source code comments, the third argument is the > MECHANISM to use: > > /* > * ldap_sasl_bind - bind to the ldap server (and X.500). > * The dn (usually NULL), mechanism, and credentials are provided. > * The message id of the request initiated is provided upon successful > * (LDAP_SUCCESS) return. > * > * Example: > * ldap_sasl_bind( ld, NULL, "mechanism", > * cred, NULL, NULL, &msgid ) > */ > > > I.e., you would pass in "GSSAPI" for a SASl/GSSAPI bind, etc. > > It is also generally better form to use ldap_sasl_interactive_bind_s, as > noted in the man page. In that case, as noted by the manual page: > > The mechs parameter should contain > a space-separated list of candidate mechanisms to use. If > this > parameter is NULL or empty the library will query the > supportedSASLMechanisms attribute from the server's rootDSE for > the > list of SASL mechanisms the server supports. > > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: LMDB persistent snapshots
by Howard Chu 10 Jul '17

10 Jul '17

Michael Conrad wrote: > On 07/10/2017 12:16 PM, Howard Chu wrote: >> Michael Conrad wrote: >>> Hi, I'm scoping out my options for databases that support snapshotting. >>> From what I've read so far, this is a natural feature of LMDB, >> >> Not really. The persistent state only records the 2 most recent transactions. > > Hm, well so much for that idea ;-) But could you clarify what would happen > in a scenario like: > > Proc1: Begin Read Transaction t1 > Proc2: Write Transaction t2 > Proc2: Write transaction t3 > Proc3: Begin Read Transaction t4 > Proc2: Write Transaction t5 > Proc2: Write Transaction t6 > > After those steps, are process 1 and process 3 still able to continue reading > their data, and is all the data they see consistent with the state of the > database at the time they began the transaction? Yes. They each retain an in-memory copy of the DB metadata at the start of their transaction, and none of the pages they require can be reused by any write transactions. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: LMDB persistent snapshots
by Howard Chu 10 Jul '17

10 Jul '17

Michael Conrad wrote: > Hi, I'm scoping out my options for databases that support snapshotting. From what I've read so far, this is a natural feature of LMDB, Not really. The persistent state only records the 2 most recent transactions. > however all the documentation talks about making sure not to let read transactions linger around. What if I *want* to hold onto a read transaction long-term, hours or even months? You should probably use the mdb_copy interface to just make a copy of that snapshot. > Also, I haven't yet seen a way for a new client to re-open the database as of the point in time of an existing transaction. Is this possible? See above, only the 2 most recent transactions' metadata is preserved. So in general, no. > If I manage to do something like this, will the storage overhead be roughly equivalent to the quantity of changed data between the snapshot and the latest write? or will the overhead be more like the sum of all writes + overwrites that happened since the read transaction started? i.e. if a read transaction is held starting from t0, then data is written at t1, then overwritten at t2 can the blocks affected by t1 be reclaimed for a write at t3? No. For any read transaction started at time t, only old pages up to t-2 can be reclaimed. Once they're all consumed, only new pages will be used, for as long as that txn stays open. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Query on ldap sasl bind
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Monday, July 10, 2017 9:02 PM +0530 Nishanth Nagendra <nishanth.amogh(a)gmail.com> wrote: > > From the openldap source code, I notice that sasl.c file has a constant > LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I > tried to pass a non NULL value in my function call to ldap_sasl_bind in > the third parameter expecting it to hit the other code path to initiate > SASL bind with credentials but the library does not seem to allow it and > returns error from sasl bind. As clearly noted in the source code comments, the third argument is the MECHANISM to use: /* * ldap_sasl_bind - bind to the ldap server (and X.500). * The dn (usually NULL), mechanism, and credentials are provided. * The message id of the request initiated is provided upon successful * (LDAP_SUCCESS) return. * * Example: * ldap_sasl_bind( ld, NULL, "mechanism", * cred, NULL, NULL, &msgid ) */ I.e., you would pass in "GSSAPI" for a SASl/GSSAPI bind, etc. It is also generally better form to use ldap_sasl_interactive_bind_s, as noted in the man page. In that case, as noted by the manual page: The mechs parameter should contain a space-separated list of candidate mechanisms to use. If this parameter is NULL or empty the library will query the supportedSASLMechanisms attribute from the server's rootDSE for the list of SASL mechanisms the server supports. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Monday, July 10, 2017 6:33 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > You didn't fail Quanah. I included the version number in my original > description of the problem 'cause I didn't want to be "that guy". :D I > am running 2.4.44. Ah, ok, good. ;) Hm, so it would seem to me there's a bug in back-ldap then. I haven't played with it enough to know for sure, however. It would probably be worthwhile following Howard's suggestion then. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Deleting old replicas on consumer?
by Quanah Gibson-Mount 10 Jul '17

10 Jul '17

--On Friday, June 30, 2017 2:44 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > If I delete a replication consumer, do I need to delete any > replication-related data for that consumer's replication on the producer? > If so, how? If you're talking about pure consumers (not multi-master consumers), there's nothing to do, as there's nothing stored on the provider. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Query on ldap sasl bind
by Nishanth Nagendra 10 Jul '17

10 Jul '17

Hi All, I am new to Openldap and have been doing some basic testing with an application software I am working with. This software has an ldap protocol interface that talks to an ldap server using the Openldap library version 2.4 supporting operations such as search, add, delete. I am currently facing a challenge in understanding as to how this interface can send out a bind request with sasl mechanism as not simple. The code snippet trying to initiate an asynchronous bind is as below: ldap_sasl_bind(ldaphandle, dn, NULL, cred, NULL, NULL , &msgID); This code is initiating a bind with mechanism as simple when I capture the packets on the wire which I believe is because of the third parameter in this function call being NULL. The man page for bind operations http://www.openldap.org/software/man.cgi?query=ldap_sasl_bind&apropos=0&sek… does not speak about what values should I pass to the third parameter if I want to use a specific sasl mechanism. Can this just be a user defined string or a specific string that openldap expects. >From the openldap source code, I notice that sasl.c file has a constant LDAP_SASL_SIMPLE as a constant for mechanism which is a NULL value. I tried to pass a non NULL value in my function call to ldap_sasl_bind in the third parameter expecting it to hit the other code path to initiate SASL bind with credentials but the library does not seem to allow it and returns error from sasl bind. Any inputs in this direction would be really helpful. regards, Nishanth

1 0

openldap under openbsd
by Paul B. Henson 10 Jul '17

10 Jul '17

I was curious if anybody is running openldap under openbsd? The version in their ports system has mdb disabled, it says mdb is unreliable and results in random slapd crashes. It seems openbsd lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option; they added a patch to cause initialization to fail if that option isn't enabled but then ended up disabling it completely anyway. This was back in 2015, I'm not sure if they've tested it recently or what details there were behind the crashes before they ended up disabling it. I'm thinking of trying it out with the latest release and seeing what happens but was wondering if anybody else had any recent experience. Thanks...

1 0

LMDB persistent snapshots
by Michael Conrad 09 Jul '17

09 Jul '17

Hi, I'm scoping out my options for databases that support snapshotting. From what I've read so far, this is a natural feature of LMDB, however all the documentation talks about making sure not to let read transactions linger around. What if I *want* to hold onto a read transaction long-term, hours or even months? Also, I haven't yet seen a way for a new client to re-open the database as of the point in time of an existing transaction. Is this possible? If I manage to do something like this, will the storage overhead be roughly equivalent to the quantity of changed data between the snapshot and the latest write? or will the overhead be more like the sum of all writes + overwrites that happened since the read transaction started? i.e. if a read transaction is held starting from t0, then data is written at t1, then overwritten at t2 can the blocks affected by t1 be reclaimed for a write at t3? Thanks for any insight! -Mike

1 0

Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 08 Jul '17

08 Jul '17

--On Friday, July 07, 2017 6:27 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > olcDbStartTLS: ldaps starttls=no > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" > tls_reqcert=demand tls_crlcheck=none There is no such option as "starttls" for the olcDbStartTLS parameter. >From the man page: tls {[try-]start|[try-]propagate|ldaps} [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] Specify the use of TLS when a regular connection is initialized. The StartTLS extended operation will be used unless the URI directive protocol scheme is ldaps://. In that case this keyword may only be set to "ldaps" and the StartTLS operation will not be used. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended. My guess then is everything past that point is ignored, since you've provided invalid configuration data. The attribute is also poorly named, as it may or may not have anything to do with startTLS. More likely it should have just been called olcDbTLS --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 4

Re: [EXTERNAL] Re: back-ldap and ldaps not working
by Howard Chu 08 Jul '17

08 Jul '17

Jon C Kidder wrote: > Thanks Michael. The message is clear but the solution isn't. I think you missed the part about this exact same slapd node being a replication consumer replicating successfully using the exact same certificate/TLS setup. Just for added validation the masters have been active for a couple years serving a very active test environment with ~100 test clients connecting via ldaps. Something appears to be hinky with the configuration processing or certificate validation processing in back-ldap. My gut is that olcDBStartTLS isn't being converted/formatted correctly or isn't being parsed correctly and the option to set the path to the CA cert file is being ignored. In that case you could use strace to verify whether the CA cert file is ever being opened. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 9:39 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > Yeah, that's actually how I started and where the starttls=no setting > came from. > > This .conf section > > overlay chain > chain-uri "ldaps://ds2-q.global.aep.com" > chain-rebind-as-user TRUE > chain-idassert-bind bindmethod=simple > binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" > credentials=<redacted> mode="self" chain-tls ldaps > tls_cacert=/appl/openldap/etc/openldap/tls/cacerts.cer chain-return-error > TRUE Hm, if the conversion is adding that "starttls=no" to the cn=config database, that seems like a serious bug in the conversion process. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: back-ldap and ldaps not working
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > I've removed the starttls=no syntax and the line now reads. > > olcDbStartTLS: ldaps > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " > tls_reqcert=demand tls_crlcheck=none > > I have verified the change propagated to the configuration directory and > restarted the instance. I saw no errors during configuration parsing in > the log. I am still seeing this error when the chain overlay tries to > follow the referral but no complaints when syncrepl connects. I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page: There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-. It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

back-ldap and ldaps not working
by Jon C Kidder 07 Jul '17

07 Jul '17

I have the following attributes set in my ldap backend for the chain overlay. olcDbURI: "ldaps://ds2-q.global.aep.com:636" olcDbStartTLS: ldaps starttls=no tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer" tls_reqcert=demand tls_crlcheck=none The referenced file is the exact same file I use in this global attribute olcTLSCACertificateFile: /appl/openldap/etc/openldap/tls/cacerts.cer This is a 2.4.44 replication consumer using the following replication attribute olcSyncrepl: {1}rid=112 provider=ldaps://ds2-q.global.aep.com:636 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" bindmethod=simple credentials=<redacted> searchbase="dc=Global,dc=aep,dc=com" type=refreshAndPersist retry="5 5 300 +" timeout=1 Replication works perfectly and changes to the referenced master are replicated to this slave. I can see successful connections for rid=112 to this master in the log. The problem is when the chain overlay tries to follow referrals to this same master I get the following error: 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" -> "ldaps://ds2-q.global.aep.com:636" 595fbb1c conn=1000 op=1 ldap_chain_op: ref="ldaps://ds2-q.global.aep.com:636/uid=s012235,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com": URI="ldaps://ds2-q.global.aep.com:636" found in cache ldap_create ldap_url_parse_ext(ldaps://ds2-q.global.aep.com:636) 595fbb1c =>ldap_back_getconn: conn=1000 op=1: lc=0x10180430 inserted refcnt=1 rc=0 ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ds2-q.global.aep.com:636 ldap_new_socket: 16 ldap_prepare_socket: 16 ldap_connect_to_host: Trying 10.92.127.52:636 ldap_pvt_connect: fd: 16 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 1, err: 19, subject: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com, issuer: /C=US/ST=Ohio/L=Columbus/O=American Electric Power/OU=Complex - Middleware/CN=AEP Root CA (2014)/emailAddress=middleware(a)aep.com TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_result: conn=1000 op=1 p=3 595fbb1c send_ldap_response: msgid=2 tag=103 err=52 ber_flush2: 14 bytes to sd 15 595fbb1c conn=1000 op=1 RESULT tag=103 err=52 text= So, is there something wrong with the value of the olcDBStartTLS attribute that I'm not seeing?? -Jon C. Kidder American Electric Power Complex - Middleware Engineering

1 0

RE: Using TLS
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:29 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Right, ldap_set_option doesn't take string input argument. I implied an > integer value such as LDAP_OPT_X_TLS_NEVER, LDAP_OPT_X_TLS_ALLOW, etc. > > I have no doubt it works nicely in your case. Just trying to understand > why it doesn't on my side. Hard to say without the full context of your code. It clearly works not just with what I did, but with other client code as well, whether it's the bits that part ldap.conf/.ldaprc to the syncrepl client code, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: [EXTERNAL] Re: [Bad Attachment] Slave won't send referrals
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:20 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > Of course it did!! Lol Let's try this instead. > > https://1drv.ms/t/s!Ahoo4oNE6Txzgx4wf4gzVQkKPjG6 You have this set: olcMirrorMode: TRUE Which indicates you are saying this is a provider, not a consumer. This turns the ability to write to it on. That setting is *only* for mult-master configurations. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 4:05 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hi Quanah, > > I tried ldap_int_tls_config for RE24 in my app program as shown below and > it didn't work. Interesting. ;/ I wonder if there's something more in what you're doing outside of that code snippet that's causing the context to be lost. It clearly works with the code I've done (and in general with the client libraries). > Additionally, I'm curious why you use ldap_int_tls_config instead of > ldap_set_option? ldap_set_option can't take "never" as an argument to LDAP_OPT_X_TLS_REQUIRE_CERT, but ldap_int_tls_config can. If I had used ldap_set_option, I would have needed to do a ton of code duplication for error checking. Similar for the LDAP_OPT_X_TLS_PROTOCOL_MIN and LDAP_OPT_X_TLS_CRLCHECK options. Much better to do code re-use. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: [Bad Attachment] Slave won't send referrals
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Friday, July 07, 2017 3:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > > > Ok, this should be simple right? I have a 2.4.44 slave with olcUpdateRef > pointing to the master. Replication works fine and the slave reflects > any changes made to the master. The slave is also accepting modify > operations without complaining and without returning a referral. I've > compared my configuration with the configuration generated for test022. I > have the needful extra stuff in my configuration and everything looks > correct to me. I've attached the modify command line and result, the > slave configuration, and the log of the operation for reference. My email provider still scrubbed your attachment. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 07 Jul '17

07 Jul '17

--On Monday, June 26, 2017 4:59 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt); > > -And- > > int new_ctx = 0; > ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx); Hi Daniel, This case is specifically tested in my TLS test suite in test067. It works correctly, as expected. I would note that I use ldap_int_tls_config (RE24)/ldap_pvt_tls_config (2.5/master) for setting LDAP_OPT_X_TLS_REQUIRE_CERT rather than ldap_set_option. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Slave won't send referrals
by Jon C Kidder 07 Jul '17

07 Jul '17

Ok, this should be simple right? I have a 2.4.44 slave with olcUpdateRef pointing to the master. Replication works fine and the slave reflects any changes made to the master. The slave is also accepting modify operations without complaining and without returning a referral. I've compared my configuration with the configuration generated for test022. I have the needful extra stuff in my configuration and everything looks correct to me. I've attached the modify command line and result, the slave configuration, and the log of the operation for reference. Any insight into what I'm overlooking would be greatly appreciated!! Thanks, -Jon C. Kidder American Electric Power Complex - Middleware Engineering. zip renamed as txt to avoid mail scrubbing.

1 0

libgcrypt's RSA-1024 and RSA-2048 broken
by Howard Chu 07 Jul '17

07 Jul '17

http://thehackernews.com/2017/07/gnupg-libgcrypt-rsa-encryption.html?utm_so… I believe most deployments of GnuTLS now use nettle instead of libgcrypt. But if you're on an older Debian or Ubuntu, using their packaged OpenLDAP built with GnuTLS, you should check what version of GnuTLS and libgcrypt you're using. And you should seriously consider not using their package; rebuild from source with OpenSSL or get a package from LTB or Symas. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Q: index for operational attributes?
by Ulrich Windl 06 Jul '17

06 Jul '17

Hello! Should I really add an index for modifyTimestamp? I got "slapd[4021]: <= bdb_inequality_candidates: (modifyTimestamp) not indexed!" (No discussions on using BDB, please!) Regards, Ulrich

2 4

RE: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 5:39 PM +0000 laurent2.perrin(a)orange.com wrote: > To sum up: > > Client ==> openLdap (meta backend): Control header is in the searchRequest > OpenLDAP (meta backend) ==> Active Directory: Control header is in the > searchRequest Active Directory ==> OpenLDAP (meta backend): Control > header is in the searchResDone OpenLDAP (meta backend) ==> Client: > Control header is not in the searchResDone > > This control Header should not be passed to client ? No idea. The backend and that code are both experimental, and the author has since retired from the project. What's really necessary is for someone to adopt back-ldap/meta and join the project so development on them can continue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 10:41 AM +0000 laurent2.perrin(a)orange.com wrote: > > > Hello, > > > > I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server > 16.04. > > > > This is working with some ldapsearch but meta directory will be used by a > VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, > which is disabled by default for the meta backend (according to the > slapd-meta documentation). Hi Luarent, The client-pr code is currently ifdef'd behind LDAP_DEVEL, which means it is not enabled by default. It appears there is a bug here, in that either the feature should be moved out from being behind LDAP_DEVEL or the documentation should be removed from the man page. If you need use of this feature, you need to define SLAPD_META_CLIENT_PR when compiling OpenLDAP. >From back-meta.h: #ifdef LDAP_DEVEL #define SLAPD_META_CLIENT_PR 1 #endif /* LDAP_DEVEL */ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 1:39 AM -0400 btb <btb(a)bitrate.net> wrote: > i've also increased accesslog data retention from 7 days to 14 days, as a > bit of a compensation for the infrequent writes, and i'll implement a > "no-op" cron job as well, as a fail safe. are then any pitfalls i may > not be considering with a 14 day accesslog retention period? is that too > long according to "typical" consensus? It really depends on your specific usage. It's defined as a configurable so it can be adjusted to match the reality of a given deployment. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: redMod with single colon
by Ondřej Kuzník 05 Jul '17

05 Jul '17

On Wed, Jul 05, 2017 at 01:48:06PM +0200, Ulrich Windl wrote: > Ondrej Kuzník <ondra(a)mistotebe.net> schrieb am 28.06.2017 um 17:51 in >> Hi, >> this is intended and how the issue in ITS#6545 has been fixed. >> >> The operation you are looking at has removed some values, then added >> other values for the same attribute straight away as another modify >> within the same op. > > What would break if those "Og==" lines were omitted? ITS#6545: interrupted replication/potential desynchronisation, depending on the operation. See the related changes to the test suite (test063). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

client-pr option for meta backend
by laurent2.perrin＠orange.com 05 Jul '17

05 Jul '17

Hello, I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server 16.04. This is working with some ldapsearch but meta directory will be used by a VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, which is disabled by default for the meta backend (according to the slapd-meta documentation). I tried to enable it with the "olcDbClientPr" option, with this ldif file: dn: olcDatabase={2}meta,cn=config changetype: modify add: olcDbClientPr olcDbClientPr: accept-unsolicited But I get this error message: modifying entry "olcDatabase={2}meta,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcDbClientPr> handler exited with -1026 Here is the configuration of the meta backend: dn: olcDatabase={2}meta objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=meta,dc=local olcLastMod: FALSE olcRootDN: cn=manager,dc=meta,dc=local olcRootPW:: e1NTSEF9S3VmQ2VFUEhUV2tyWWRkQnZLVUdkbEp4QSt6UDU2Zmk= structuralObjectClass: olcMetaConfig entryUUID: 7115068a-f1bb-1036-8e31-07775d6d5e9e creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170630083957Z olcSizeLimit: 30000 olcLimits: {0}users size.prtotal=1000 pr.size=1000 entryCSN: 20170704141941.224315Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Is something wrong with this type of configuration ? Regards, [cid:image001.gif@01CBF2E5.34FD28F0] Laurent PERRIN Service Infra aux Projets Orange Applications for Business SCE/OAB/DPO/DT/SF/CLOUDS tel. +33 4 37 24 62 85 Mob : 07 84 12 78 79 laurent2.perrin(a)orange.com<mailto:laurent2.perrin@orange.com> 139 rue Vendôme 69006 Lyon www.orange-business.com<http://www.orange-business.com/> [cid:image002.gif@01CBF2E5.34FD28F0] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Thursday, June 29, 2017 1:41 PM -0400 btb <btb(a)bitrate.net> wrote: > > > On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote: >> --On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: >> >>> i see, thanks. i tested this, and did a modify on each, but didn't see >>> replication resume. emulating the syncrepl connection with a manual >>> search against each master, there do seem to be accesslog entries now, >>> on both masters: >> >> You may have to restart the consumers (I did when I ran into this). > > i did try a restart on both, but they returned to the same state > >> Also, there are 2 sets of CSNs per master that you need to examine -- >> The CSNs in your database root (i.e., dc=example,dc=org) and your >> accesslog root. > > that would be these, right? > > dsa1 cn=accesslog: > 20161019002438.652359Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa1 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170530214231.171959Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa2 cn=accesslog: > 20170520031415.276678Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > dsa2 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170619014933.531051Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > why are there three per db, and which is suppose to match which? wow, that's a mess. So #000# is serverID 0, which would be for any entries prior to moving to MMR. The fact that you have different values for #000# on dsa1 accesslog vs the other 3 databases is disturbing. It would appear DSA1 is serverID 1, and its CSNs make sense: 20170530214415.204052Z#000000#001#000000 20170530214415.204052Z#000000#001#000000 However, there's someting serious wrong with dsa2 (assuming it is serverID 2): 20170521175113.974560Z#000000#002#000000 20170619014933.531051Z#000000#002#000000 As this implies the primary DB received a write on 2017/06/19 @ 01:49:33, but the accesslog has not recorded this change, as it says the last time there was a write op to the accesslog DB on #002# was 2017/05/21 @ 17:51:13, nearly a month earlier. So it doesn't seem to think you've done a write op directly against serverID 002. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: package OpenLDAP and lmdb
by Howard Chu 04 Jul '17

04 Jul '17

Michael Ströder wrote: > HI! > > What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? > > Use the OpenLDAP 2.4.x release and build from there? Sure, the latest LMDB release is always included in the latest OpenLDAP 2.4 release. > AFAICS LTB builds are made like this but they use a different prefix and therefore don't > have a collision with packages coming from OS package upstream. > > Ciao, Michael. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

package OpenLDAP and lmdb
by Michael Ströder 04 Jul '17

04 Jul '17

HI! What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? Use the OpenLDAP 2.4.x release and build from there? AFAICS LTB builds are made like this but they use a different prefix and therefore don't have a collision with packages coming from OS package upstream. Ciao, Michael.

1 0

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 03 Jul '17

03 Jul '17

--On Friday, June 30, 2017 9:08 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> >> Wouldn't it be simpler to define ACLs on the master that limit what >> the replication identity has access to that matches your filters? >> > > emm ... I was sure I can not do that on the master side ... just I try > do that, I receive full data ... Then likely your ACLs were incorrect? > looks like some more permittive acl works for the replica ... can I > somehow know which acl matched the replica? But I was trying to place > replABC ACLs to the end of the list and still was not able to limit data > according the filter I suggest reading the slapd.access(5) man page and the OpenLDAP Admin guide. As clearly noted in the documentation, ACLs (generally) stop processing on the *first* match. So, depending on your ACLs, adding your ACLS at the end of the list probably meant they were never evaluated. >> I would also note that your stanza limiting what attrs are replicated >> is missing the operational attributes that are necessary for sync >> replication to function, so I would fully expect errors. > > do you mean entryCSN and entryUUID ? Yes, sorry, I missed them at the start of the list of attributes. ;) So that part seems ok. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Deleting old replicas on consumer?
by Prentice Bisbal 30 Jun '17

30 Jun '17

If I delete a replication consumer, do I need to delete any replication-related data for that consumer's replication on the producer? If so, how? Prentice

1 0

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Tuesday, June 27, 2017 2:04 AM -2100 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > syncrepl rid=123 > provider=ldap://master.example:389 > starttls=critical > searchbase="ou=ABC,ou=Sendmail,dc=example" > bindmethod=simple > binddn="uid=replABC,ou=repl,dc=example" > credentials="***" > tls_cacert=/usr/local/etc/openldap/ssl/ca.crt > tls_cert=/usr/local/etc/openldap/ssl/ABC.crt > tls_key=/usr/local/etc/openldap/ssl/ABC.key > tls_reqcert=try > type=refreshAndPersist > retry="60 +" > logbase="cn=example-accesslog" > logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > syncdata=accesslog > - ---[ slave configuration quotation end ]---------------------------- Wouldn't it be simpler to define ACLs on the master that limit what the replication identity has access to that matches your filters? I would also note that your stanza limiting what attrs are replicated is missing the operational attributes that are necessary for sync replication to function, so I would fully expect errors. As Andrew already noted (and you later fixed), syncrepl RIDs are required to be unique, as documented in the man page. Given that OpenLDAP functions off of CSN values, partial replication is tricky, as the master can then have a contextCSN that does not correspond to anything in a partially replicated database, depending on how you slice it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Friday, June 30, 2017 12:48 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > ---[ slave slapd.log quotation start ]-------------------------------- > Jun 29 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 > LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 29 > 22:45:30 ABC slapd[12593]: do_syncrep2: rid=000 (53) Server is unwilling > to perform Jun 29 22:45:30 ABC slapd[12593]: do_syncrepl: rid=000 rc -2 > retrying ---[ slave slapd.log quotation end > ]-------------------------------- And what does the master say? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Catch-22: Need to change olcRootDN
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Thursday, June 29, 2017 7:27 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > Thanks. One more related question: are special rules needed for the > config information, like an ACL just for cn=config so the ldapadmins can > make changes w/o needing a rootDN? You can certainly add an olcAccess rule to the cn=config db that allows DNs from outside of cn=config to make modifications. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Catch-22: Need to change olcRootDN
by Quanah Gibson-Mount 30 Jun '17

30 Jun '17

--On Thursday, June 29, 2017 7:08 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > Actually, let me expand that question. I need to make changes to > everything in cn=config after switching to dynamic configuration. Is it > possible to do that without starting from scratch with a new slapd.conf > file. I deleted the slapd.conf I was working with because I didn't need > it anymore, and I was afraid a coworker not familiar with the dynamic > config would try to make changes to slapd.conf, and expect them to work. Use slapcat to export it. Use slapadd to import. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Catch-22: Need to change olcRootDN
by Prentice Bisbal 30 Jun '17

30 Jun '17

I got myself into a bit a of a Catch-22. I need to change the RootDN, but I don't have permission to. How does one change the root DN using dynamic configuration? Prentice

1 1

[Q] can I replicate several branches to the same slave from one master?
by Zeus Panchenko 29 Jun '17

29 Jun '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise I need to replicate not all but some branches from one master to one slave not sure how much correct I have done that, but here what I have: slave starts successfully, records appear on slave as expected, services successfully use data as expected ... but the replication fails (fragments of log files are bellow) on master I see: consumer state is newer than provider on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform so ... what is wrong here? branches to replicate: ou=People,dc=example ou=clusterX,ou=Sendmail,dc=example to be used by 3 services on the slave 1. email (smtp auth and imap4/pop3 auth) object dn sample: uid=ja@foo.bar,authorizedService=mail@foo.bar,uid=johnd,ou=People,dc=example 2. jabber object dn sample: uid=aj@foo.bar,authorizedService=xmpp@foo.bar,uid=johnd,ou=People,dc=example 3. sendmail configuration (here is the detailed diagram https://github.com/z-eos/umi/wiki/DB-topology) ====================================================================== here is the configuration layout: - ---[ master configuration quotation start ]--------------------------- ... access to dn.children="dc=example" by dn.exact="uid=replABC,ou=repl,dc=example" read by * break # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 overlay accesslog logdb cn=example-accesslog logops writes logold (objectclass=*) index default eq ### Accesslog DB database mdb maxsize 1073741824 suffix cn=example-accesslog rootdn "cn=root,cn=example-accesslog" rootpw *** directory "/var/db/openldap-data/example-accesslog" index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ... - ---[ master configuration quotation end ]--------------------------- - ---[ slave configuration quotation start ]---------------------------- syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(|(&(objectClass=authorizedServiceObject)(objectClass=mailutilsAccount)(authorizedService=mail(a)foo.bar)))" attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(&(objectClass=authorizedServiceObject)(authorizedService=xmpp(a)foo.bar))" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="ou=ABC,ou=Sendmail,dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog - ---[ slave configuration quotation end ]---------------------------- ====================================================================== here are logs - ---[ master slapd.log quotation start ]------------------------------- Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 ACCEPT from IP=192.168.0.1:54127 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 ACCEPT from IP=192.168.0.1:57184 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55586 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 closed Jun 26 22:54:25 master slapd[75509]: conn=55585 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 closed Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 ACCEPT from IP=192.168.0.1:58488 (IP=192.168.0.254:389) Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 STARTTLS Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 RESULT oid= err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:31 master slapd[75509]: conn=55587 op=3 UNBIND Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 closed - ---[ master slapd.log quotation end ]------------------------------- - ---[ slave slapd.log quotation start ]-------------------------------- Jun 26 21:41:44 ABC slapd[67186]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 7 2017 01:19:39) $ root@foo.bar:/usr/ports/net/openldap24-server/work/openldap-2.4.44/servers/slapd Jun 26 21:41:44 ABC slapd[67187]: slapd starting Jun 26 21:41:44 ABC slapd[67187]: conn=1000 fd=14 ACCEPT from IP=127.0.0.1:32266 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1002 fd=17 ACCEPT from IP=127.0.0.1:35827 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1001 fd=16 ACCEPT from IP=127.0.0.1:37048 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:42:43 ABC slapd[67187]: conn=1003 fd=9 ACCEPT from IP=127.0.0.1:37489 (IP=127.0.0.1:389) Jun 26 21:42:43 ABC slapd[67187]: conn=1003 op=0 BIND dn="" method=128 - ---[ slave slapd.log quotation end ]-------------------------------- - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWVGE9gAKCRCveOk+D/ej Kp1JAJ9tFikqgeCHlzUXfQrcTQuHlAqNKwCdEMnIM6uOFRCNBN6oHmh4AyQ6j1U= =Xn/Y -----END PGP SIGNATURE-----

2 3

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: > i see, thanks. i tested this, and did a modify on each, but didn't see > replication resume. emulating the syncrepl connection with a manual > search against each master, there do seem to be accesslog entries now, on > both masters: You may have to restart the consumers (I did when I ran into this). Also, there are 2 sets of CSNs per master that you need to examine -- The CSNs in your database root (i.e., dc=example,dc=org) and your accesslog root. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Thursday, June 29, 2017 5:07 PM +0100 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> wrote: > It seems that the CA cert was never referenced in the syncrepl clause, so > it would have dropped back to whatever TLS config was in the LDAP *client* > config file (probably /etc/ldap/ldap.conf). I seem to remember a change in > behaviour of OpenSSL libs a while ago where I was bitten by something > similar. Maybe Juergen's earlier setup used ldap.conf and the new one > is ignoring it? Could be. My specific suggestion to him was to add a line for the CA. Instead, he added a line for the CA and the two additional lines for a cert & key (which would imply certificate authentication). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Monday, June 26, 2017 7:11 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Cert authentication works on 2.4.44-r1 without any problem. Now you're switching topics. Your original mail did not include cert authentication, it used simple binds: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** Either way, cert authentication AND TLS encrypted syncrepl both work for me with OpenSSL 1.0.2l and OpenLDAP 2.4.45 just fine, so I would have to again guess issues with proper TLS configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Tuesday, June 27, 2017 5:35 PM -0400 btb <btb(a)bitrate.net> wrote: > On 6/27/17 10:27 AM, Quanah Gibson-Mount wrote: >> --On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: >>> i'm using 2.4.44 on freebsd, built from ports. i can provide any config >>> details etc - i just didn't want to inundate the post with guesses on >>> detail that might not be relevant. >> >> What is your accesslog purge setting? Do you have long periods of time >> with no write activity? > > there are some extended periods of time with no write activity, yes. That's one form of a known issue then with using accesslog (ITS#8100). I've made a suggestion on how it could be fixed, and Howard agreed that would be the correct solution. Just need the fix. :) In the meantime, you can set up a cronjob that does a modify once a day on some object that doesn't really do anything, like if you had: dn: cn=someobject,dc... objectClass: ... cn: someobject description: blah you could have a job that does: dn: cn=someobject,dc... changetype: modify replace: description description: blah So it in effect does nothing, but it keeps an active change in the accesslog alive. Basically what happens with the accesslog empty is that it'll end up generating its own new contextCSN that differs for that server than the one stored in the rootDB, and will be /newer/ than it as well, which is why you get that message. You can also fix the problem simply by doing a modify on each master, and it'll reset the contextCSNs and things will flow (i.e., no need to do a dump/reload, etc). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: N-Way multi-master configuration
by Quanah Gibson-Mount 29 Jun '17

29 Jun '17

--On Wednesday, June 28, 2017 11:25 PM +0100 Dave Lambley <dave.lambley(a)gmail.com> wrote: > What is the reason the documentation suggests "type=refreshOnly" for > data, but not for config? Should I expect any problems using > "type=refreshAndPersist" for data? The admin guide is simply giving information on how things can be done. It is not making recommendations on how things should be done. It is generally thought that people read through the pros and cons of different replication strategies and develop an understanding of what is likely best for them. I would note that running MMR with 2.4.31 is generally suicidal. I strongly advise upgrading to a current release. Please read the list of fixes in the 5 years since 2.4.31 was released: <http://www.openldap.org/software/release/changes.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

N-Way multi-master configuration
by Dave Lambley 28 Jun '17

28 Jun '17

We are using OpenLDAP 2.4.31 under Ubuntu 14.04, doing four way multi master replication. When I initially configured it, I set the data (as opposed to config) replication to be "type=refreshOnly", as described here, http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master That didn't work well, we lost insertions and and memory usage of some servers steadily over the two weeks I left it. Switching the replication to "type=refreshAndPersist" resolved both problems. What is the reason the documentation suggests "type=refreshOnly" for data, but not for config? Should I expect any problems using "type=refreshAndPersist" for data? Best regards, Dave Lambley

1 0

redMod with single colon
by Michael Ströder 28 Jun '17

28 Jun '17

HI! I have several accesslog entries with 'reqMod' containing a single colon. :-/ Example (excerpt): [..] reqMod: aeTicketId:- IAM-31 reqMod:: Og== reqMod: aeTicketId:+ IAM-201 reqMod: member:- uid=foo1,cn=ae,ou=ae-dir reqMod: member:- uid=foo2,cn=ae,ou=ae-dir reqMod:: Og== reqMod: member:+ uid=foo1,cn=ae,ou=ae-dir reqMod: member:+ uid=foo2,cn=ae,ou=ae-dir reqMod: member:+ uid=foo3,cn=ae,ou=ae-dir reqMod: memberUid:- foo1 reqMod: memberUid:- foo2 reqMod:: Og== reqMod: memberUid:+ foo1 reqMod: memberUid:+ foo2 reqMod: memberUid:+ foo3 [..] (before you ask: An account foo3 added to Æ-DIR user group with hybrid group schema compatible to RFC2307 and RFC2307bis.) Under which circumstances is slapo-accesslog writing a single colon? Currently I cannot easily reproduce it and I don't know what was so special about this particular modify operation (sent by web2ldap). Ciao, Michael.

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 27 Jun '17

27 Jun '17

--On Tuesday, June 27, 2017 10:37 AM -0400 btb <btb(a)bitrate.net> wrote: > i'm using 2.4.44 on freebsd, built from ports. i can provide any config > details etc - i just didn't want to inundate the post with guesses on > detail that might not be relevant. What is your accesslog purge setting? Do you have long periods of time with no write activity? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Why didn't rfc2307bis supersede rfc2307?
by John Lewis 27 Jun '17

27 Jun '17

https://tools.ietf.org/html/draft-howard-rfc2307bis-02 They only thing that jumps at me is the name. It doesn't follow rfc norms. Normally a new standard would be rfc and then the next number available. This one deviated, It used the same number as the old one and appended text. The standard itself is good enough to be used by Active Directory and FreeIPA by default. I am having a really hard time finding anyone who says that the standard is bad. I am willing to bet that if Luke Howard puts out this latest proposal out under the name of the next available rfc number today, which according to ftp://ftp.rfc-editor.org/in-notes/rfc-ref.txt would be rfc8203 it will be approved before the end of the year. According to Ludo here https://ludopoitou.com/2011/04/20/linux-and-unix-ldap-clients-and-rfc2307-s… , I can campaign for the standard myself if I had permission from the authors. I would do it to streamline documentation and, get the new standard into OpenLDAP 2.5 so it will be in OpenLDAP 2.6 by default.

3 5

mmr pair stops replicating: "consumer state is newer than provider"
by btb 27 Jun '17

27 Jun '17

hi. i have two servers, in an mmr arrangement, using delta-syncrepl. on a couple of occasions, the servers have stopped replicating, and the following is logged: dsa1: Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying dsa2: Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from IP=10.200.41.20:49141 (IP=0.0.0.0:389) Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established tls_ssf=256 ssf=256 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" method=128 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" mech=SIMPLE ssf=0 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed if i reload data and restart replication, things work again, for a period of time, but then this happens again. what determines "consumer state is newer than provider"? i'm also a little bit confused about this message in the context of mmr. if one has newer data than the other, i had sort of expected that the newer data would replace the old [obviously it's not that simple, so i'd like to understand what i'm missing]. lastly, how can i further troubleshoot why this happened in the first place? i'm using 2.4.44 on freebsd, built from ports. i can provide any config details etc - i just didn't want to inundate the post with guesses on detail that might not be relevant. thanks -ben

1 0

LDAP Issue: Logging region out of memory; you may need to increase its size
by Gurjot Kaur 27 Jun '17

27 Jun '17

Hello, On an already running setup of OpenLDAP 2.4 on Linux (Linux GURKES015 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux) platform, one day I start getting following error when I execute the slapcat command: bdb_db_open: warning - no DB_CONFIG file found in directory /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data: (2). Expect poor performance for suffix "dc=ORG,dc=COM".bdb(dc=ORG,dc=COM): Logging region out of memory; you may need to increase its size bdb_db_open: database "dc=ORG,dc=COM": db_open(/opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data/id2entry.bdb) failed: Cannot allocate memory (12). backend_startup_one: bi_db_open failed! (12) slap_startup failed Following are the system RAM and disk space usage. Tasks: 192 total, 2 running, 190 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.3%sy, 0.0%ni, 98.9%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8178840k total, 8145460k used, 33380k free, 329840k buffers Swap: 2031608k total, 220k used, 2031388k free, 6623032k cached Filesystem Size Used Avail Use% Mounted on /dev/mapper/rootvg-lv_root 1.9G 688M 1.2G 38% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/sda1 289M 17M 258M 7% /boot /dev/mapper/rootvg-lv_users 1.9G 1.6G 218M 89% /users /dev/mapper/rootvg-lv_exec 124M 5.6M 113M 5% /exec /dev/mapper/rootvg-lv_images 1.9G 73M 1.8G 4% /images /dev/mapper/rootvg-lv_var 1.9G 140M 1.7G 8% /var /dev/mapper/rootvg-lv_tmp 961M 22M 890M 3% /tmp /dev/mapper/rootvg-lv_system 186M 7.9M 169M 5% /system /dev/mapper/rootvg-lv_usr 1.9G 663M 1.2G 37% /usr /dev/mapper/rootvg-lv_cft251 496M 430M 41M 92% /exec/products/cft /dev/mapper/rootvg-lv_bases 79G 19G 57G 25% /bases /dev/mapper/rootvg-lv_nbu 1008M 361M 597M 38% /exec/products/netbackup /dev/mapper/rootvg-lv_pat 1008M 194M 764M 21% /exec/products/patrol /dev/mapper/rootvg-lv_bladelogic 992M 187M 755M 20% /exec/products/bladelogic I have removed some log.xxxxx files from /opt/proxy/HostedDirectoryLDAPMultiMaster/instances/LdapServers_1/var/openldap-data which are not in use. But still the same error persist while executing slapcat command. Then I restarted the slapd process. After that I start facing ldaperror 80 with additional info "index generation failed" error while adding, deleting or modifying any entry along in ldap DB. Could somebody help us to understand: 1. Why there was "Logging region out of memory; you may need to increase its size" error. How to resolve it? 2. Why after slapd restart, I got "index generation failed" error. How to resolve it? PS: DB_CONFIG was not present in /var/openldap-data directory and slapcat was used to work properly before this issue. "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

2 2

RE: Using TLS
by Quanah Gibson-Mount 26 Jun '17

26 Jun '17

--On Friday, June 23, 2017 10:31 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Thanks Quanah. > > Using OpenLDAP API, is it correct to set client TLS option to -not- > validate server certificates as follows? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt); You still have to reinitialize the global context, as in my commit, for the filehandle. So you'd want these two lines to be following: int new_ctx = 0; rc = ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx) etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 26 Jun '17

26 Jun '17

--On Friday, June 23, 2017 8:30 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > Have also added these entries to syncrepl now, but without any success: > > tls_cert=/etc/ssl/openldap/dannatu.ch.pem > tls_key=/etc/ssl/openldap/dannatu.ch.key > tls_cacert=/etc/ssl/certs/dannatuCA-cacert.pem This would indicate you want to do client cert authentication with the syncrepl client, which as far as I know, you are not using (based on your earlier configuration). You need to remove the tls_cert and tls_key lines. I've tested with OpenLDAP 2.4.45 and TLS works as expected with replication. --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 on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Quanah Gibson-Mount 25 Jun '17

25 Jun '17

--On Thursday, June 22, 2017 9:19 PM +0000 Ron Lamarche <Ron.Lamarche(a)innovapost.com> wrote: > I've installed the RHEL 6.9 OpenLDAP bundled product and have a working > suffix based on cn=config vs. slapd.conf model but cannot get the > accesslog overlays/DB's to work properly (ldapsearch returns accesslog > records but never completes and instead hangs showing > "ldap_int_select" . Need to ctl –c to exit ) Hi Ron, The OpenLDAP build distributed by RedHat is known to have severe issues. It is strongly recommended to avoid their OpenLDAP builds because of this and their advanced age. If you are not able to build OpenLDAP yourself, the LTB project provides standard OpenLDAP builds for free: <http://ltb-project.org/wiki/download#openldap> If you require support, Symas (my employer) has such an offering. Our OpenLDAP builds also include features not yet available from the OpenLDAP project. You may be well facing any of a number of bugs that have been fixed in the 2.5 years since 2.4.40 was released, in particular: Fixed slapd cn=config when updating olcAttributeTypes (ITS#8199) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Finally, I would also note that the back-bdb backend has been deprecated since OpenLDAP 2.3, and as of OpenLDAP 2.4, back-hdb is also deprecated. The recommended backend is back-mdb, which is built on top of LMDB (<http://www.symas.com/lmdb/>, <https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database>) In general, issues with RedHat's build will not be explored unless you can reproduce the same problem with a current build of OpenLDAP. 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: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Friday, June 23, 2017 10:08 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hi Quanah, > > No, I'm fairly new to OpenLDAP and wasn't aware of such global context > requirement. > > Does that only apply to client TLS options? > > Is global option set by passing a NULL LDAP handle? > > I found ITS#8573 wrt your TLS patch, but the URL: > <http://www.openldap.org/lists/openldap-devel/attachments/20170608/2ae39d > 03/attachment.bin> is not found. Can you point me to where to download or > see the patch? Has it been integrated into 2.4.45? Hi Daniel, You can view it here: <https://github.com/quanah/openldap-scratch/commit/cff66313706c607d4df6f0742…> and no, it would be part of 2.5 once submitted, although it applies just fine for me to 2.4 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

RE: Using TLS
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

Hi Daniel, You are aware that you must use the global context when changing the TLS options for a client, correct? It does not work on the specific filehandle. See my TLS patch for the command line client tools for an example (that is posted to the openldap-devel list). --Quanah --On Friday, June 23, 2017 9:20 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > Hello, > > Is there a unit tester where the client LDAP_OPT_X_TLS_REQUIRE_CERT > option is set to LDAP_OPT_X_TLS_NEVER that I can try? I was looking at > openldap-2.4.44/clients/tools/ldapsearch but it doesn't configure this > option. > > My application program sets LDAP_OPT_X_TLS_NEVER. Why does LDAP client > still check for server certificate which fails in the case of bad > certificate? > > int opt; > opt = LDAP_OPT_X_TLS_NEVER; > ldap_retcode = ldap_set_option(m_tLDAP, LDAP_OPT_X_TLS_REQUIRE_CERT, > &opt); ... > > Daniel > > -----Original Message----- > From: Daniel Le > Sent: Monday, June 19, 2017 3:58 PM > To: 'Paulm' <paulm(a)tetrardus.net> > Cc: openldap-technical(a)openldap.org > Subject: RE: Using TLS > > I rebuilt with libssl (an OpenSSL library which supports SSL and TLS) and > that worked. Thanks. > > However, I got into the connect error "14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self > signed certificate)", even though the LDAP_OPT_X_TLS_REQUIRE_CERT option > is set to LDAP_OPT_X_TLS_NEVER. Isn't LDAP client supposed to bypass > server certificate validation when LDAP_OPT_X_TLS_NEVER is configured? > > Daniel > > -----Original Message----- > From: Paulm [mailto:paulm@tetrardus.net] > Sent: Sunday, June 18, 2017 10:13 PM > > On Fri, Jun 16, 2017 at 03:26:20PM +0000, Daniel Le wrote: >> Hi, >> >> >> I'm seeing some critical error which causes the application program to >> exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is >> called. Tracing the code execution, ldap_start_tls_s => >> ldap_int_tls_start => tls_init, it appears the crash is at the >> statement "return impl->ti_tls_init()" in the tls_init function. >> >> >> Can someone give a pointer to help debugging this? And does OpenLDAP >> need to be linked to OpenSSL library for TLS to work? > > If your ldap libs are linked to gnutls, then it might be worthwhile to > rebuild and link to the openssl library; then test your code again. > > I don't use gnutls because it has given me problems. > >> I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. >> HAVE_TLS is defined but not LDAP_R_COMPILE. >> >> >> Thanks, >> >> Daniel > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Using TLS
by Daniel Le 23 Jun '17

23 Jun '17

Hi, I'm seeing some critical error which causes the application program to exit/terminate when ldap_start_tls_s(LDAP-handle, NULL, NULL) is called. Tracing the code execution, ldap_start_tls_s => ldap_int_tls_start => tls_init, it appears the crash is at the statement "return impl->ti_tls_init()" in the tls_init function. Can someone give a pointer to help debugging this? And does OpenLDAP need to be linked to OpenSSL library for TLS to work? I use LDAPv3, port 389 and the default LDAP_OPT_X_TLS_NEVER option. HAVE_TLS is defined but not LDAP_R_COMPILE. Thanks, Daniel

2 3

Re: syncrepl fails after upgrade to openldap 2.4.45
by Quanah Gibson-Mount 23 Jun '17

23 Jun '17

--On Thursday, June 22, 2017 10:25 AM +0000 Juergen.Sprenger(a)swisscom.com wrote: > syncrepl rid=000 > provider=ldaps://ldap.dannatu.ch:636 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=dannatu,dc=ch" > attrs="*,+" > scope=sub > bindmethod=simple > binddn="cn=Manager,dc=dannatu,dc=ch" > credentials=************** I don't see anything here configuring for syncrepl to find the CA for your server cert. I.e., something like tls_cacertdir=<path> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

ldapsearch on accesslog hangs in OpenLDAP 2.4.40 on RHEL 6.9 ( works ok w/ slapcat -b "cn=accesslog")
by Ron Lamarche 22 Jun '17

22 Jun '17

Hi. My company has decided to migrate from Oracle Directory Server 7.0 (ODSEE ) to OpenLDAP due to end of life supportability issues . I've installed the RHEL 6.9 OpenLDAP bundled product and have a working suffix based on cn=config vs. slapd.conf model but cannot get the accesslog overlays/DB's to work properly (ldapsearch returns accesslog records but never completes and instead hangs showing "ldap_int_select" . Need to ctl -c to exit ) Here's the details: - more /etc/redhat-release o Red Hat Enterprise Linux Server release 6.9 (Santiago) - yum list installed | grep openldap o compat-openldap.x86_64 1:2.3.43-2.el6 o openldap.x86_64 2.4.40-16.el6 o openldap-clients.x86_64 2.4.40-16.el6 o openldap-devel.x86_64 2.4.40-16.el6 o openldap-servers.x86_64 2.4.40-16.el6 - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={2}bdb,cn=config" | egrep "olcRo|olcSu" < - -------- main suffix DB o olcSuffix: dc=mydomain,dc=ca o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcRootPW: {SSHA}ZODaH7MZuRjuG+FTzIZvdPg5edL2WDjg - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "olcDatabase={3}bdb,cn=config" < - ---accesslog DB and overlay o dn: olcDatabase={3}bdb,cn=config o objectClass: olcDatabaseConfig o objectClass: olcBdbConfig o olcDatabase: {3}bdb o olcDbDirectory: /var/lib/ldap/accesslog o olcSuffix: cn=accesslog o olcRootDN: cn=dev13,dc=mydomain,dc=ca o olcDbIndex: default eq o olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart - o dn: olcOverlay={0}accesslog,olcDatabase={3}bdb,cn=config o objectClass: olcOverlayConfig o objectClass: olcAccessLogConfig o olcOverlay: {0}accesslog o olcAccessLogDB: cn=accesslog o olcAccessLogOps: writes reads session o olcAccessLogPurge: 07+00:00 01+00:00 o olcAccessLogSuccess: TRUE - ldapsearch -Q -Y EXTERNAL -H ldapi:/// -LLL -b "cn=module{0},cn=config" |< - --------------loaded modules o dn: cn=module{0},cn=config o objectClass: olcModuleList o cn: module{0} o olcModulePath: /usr/lib64/openldap o olcModuleLoad: {0}syncprov.la o olcModuleLoad: {1}accesslog.la When I execute the ldapsearch on cn=accesslog I get the following ( ctl-c needed to exit from the hang ) : ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mailposte,dc=ca" -b cn=accesslog -W ldap_url_parse_ext(ldap://) ldap_initialize( ldap://:389/??base ) ldap_create ldap_url_parse_ext(ldap://:389/??base) Enter LDAP Password: ... stuff omitted due to length ... reqDN: reqStart=20170620210816.000003Z,cn=accesslog ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqResult: 0 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqMod: objectClass:+ auditSearch reqMod: structuralObjectClass:+ auditSearch reqMod: reqStart:+ 20170620210816.000003Z reqMod: reqEnd:+ 20170620210816.000004Z reqMod: reqType:+ search reqMod: reqSession:+ 18446744073709551615 reqMod: reqAuthzID:+ cn=dev13,dc=mailposte,dc=ca reqMod: reqDN:+ cn=accesslog reqMod: reqResult:+ 0 reqMod: reqScope:+ one reqMod: reqDerefAliases:+ never reqMod: reqAttrsOnly:+ TRUE reqMod: reqFilter:+ (reqStart<=20170613210816Z) reqMod: reqAttr:+ 1.1 reqMod: reqEntries:+ 0 reqMod: reqTimeLimit:+ -1 reqMod: reqSizeLimit:+ -1 reqMod: entryUUID:+ 52bef5ee-ea48-1036-9807-2fa6ad6fded4 reqMod: creatorsName:+ cn=dev13,dc=mailposte,dc=ca reqMod: createTimestamp:+ 20170620210816Z reqMod: entryCSN:+ 20170620210816.416676Z#000000#000#000000 reqMod: modifiersName:+ cn=dev13,dc=mailposte,dc=ca reqMod: modifyTimestamp:+ 20170620210816Z ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4 ldap_get_attribute_ber ldap_msgfree ldap_result ld 0x14c91c0 msgid -1 wait4msg ld 0x14c91c0 msgid -1 (infinite timeout) wait4msg continue ld 0x14c91c0 msgid -1 all 0 ** ld 0x14c91c0 Connections: * host: (null) port: 389 (default) refcnt: 2 status: Connected last used: Wed Jun 21 13:46:58 2017 ** ld 0x14c91c0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x14c91c0 request count 1 (abandoned 0) ** ld 0x14c91c0 Response Queue: Empty ld 0x14c91c0 response count 0 ldap_chkResponseList ld 0x14c91c0 msgid -1 all 0 ldap_chkResponseList returns ld 0x14c91c0 NULL ldap_int_select ^C When I do an strace of the working suffix ( dc=mydomain,dc=ca ) I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b dc=mydomain,dc=ca -w my_passwd ..... stuff omitted due to length .... write(3, "0\5\2\1\3B\0", 7) = 7 shutdown(3, SHUT_RDWR) = 0 close(3) = 0 write(2, "ldap_free_connection: actually f"..., 37ldap_free_connection: actually freed ) = 37 exit_group(0) = ? +++ exited with 0 +++ When I do an strace of cn=accesslog I get the following termination : - strace ldapsearch -d 1 -H ldap:// -v -x -LLL -D "cn=dev13,dc=mydomain,dc=ca" -b cn=accesslog -w my_passwd ..... stuff omitted due to length .... write(1, "reqEntryUUID: 52bef5ee-ea48-1036"..., 51reqEntryUUID: 52bef5ee-ea48-1036-9807-2fa6ad6fded4) = 51 write(2, "ldap_get_attribute_ber\n", 23ldap_get_attribute_ber) = 23 write(2, "ldap_msgfree\n", 13ldap_msgfree) = 13 write(2, "ldap_result ld 0x24381e0 msgid -"..., 34ldap_result ld 0x24381e0 msgid -1) = 34 write(2, "wait4msg ld 0x24381e0 msgid -1 ("..., 50wait4msg ld 0x24381e0 msgid -1 (infinite timeout)) = 50 write(2, "wait4msg continue ld 0x24381e0 m"..., 46wait4msg continue ld 0x24381e0 msgid -1 all 0) = 46 write(2, "** ld 0x24381e0 Connections:\n", 29** ld 0x24381e0 Connections:) = 29 write(2, "* host: (null) port: 389 (defa"..., 37* host: (null) port: 389 (default)) = 37 write(2, " refcnt: 2 status: Connected\n", 31 refcnt: 2 status: Connected) = 31 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3477, ...}) = 0 write(2, " last used: Wed Jun 21 14:07:30"..., 39 last used: Wed Jun 21 14:07:30 2017) = 39 write(2, "\n", 1) = 1 write(2, "** ld 0x24381e0 Outstanding Requ"..., 38** ld 0x24381e0 Outstanding Requests:) = 38 write(2, " * msgid 2, origid 2, status In"..., 41 * msgid 2, origid 2, status InProgress) = 41 write(2, " outstanding referrals 0, pare"..., 43 outstanding referrals 0, parent count 0) = 43 write(2, " ld 0x24381e0 request count 1 ("..., 45 ld 0x24381e0 request count 1 (abandoned 0)) = 45 write(2, "** ld 0x24381e0 Response Queue:\n", 32** ld 0x24381e0 Response Queue:) = 32 write(2, " Empty\n", 9 Empty) = 9 write(2, " ld 0x24381e0 response count 0\n", 32 ld 0x24381e0 response count 0) = 32 write(2, "ldap_chkResponseList ld 0x24381e"..., 49ldap_chkResponseList ld 0x24381e0 msgid -1 all 0) = 49 write(2, "ldap_chkResponseList returns ld "..., 47ldap_chkResponseList returns ld 0x24381e0 NULL) = 47 write(2, "ldap_int_select\n", 16ldap_int_select) = 16 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1 < - ------------------------------- This means poll is waiting for something on this File descriptor which never gets returned ^C Process 7844 detached <detached ...> Here is the ldif file used for moduleload by ldapadd : cat addModule.ldif dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap #olcModuleLoad: {0}back_bdb olcModuleLoad: syncprov.la olcModuleLoad: accesslog.la Here is the ldif file to add the accesslog db and overlay by ldapadd: cat addAccesslog2DB # Accesslog database definitions dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=dev13,dc=mydomain,dc=ca olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # accesslog overlay definitions for primary db dn: olcOverlay=accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes reads session olcAccessLogSuccess: TRUE # scan the accesslog DB every day and purge entries older than 7 days olcAccessLogPurge: 07+00:00 01+00:00 I have also created /var/lib/ldap/accesslog owned by ldap:ldap : ls -l /var/lib/ldap/accesslog total 11232 -rw-r-----. 1 ldap ldap 4096 Jun 20 17:08 alock -rw-------. 1 ldap ldap 24576 Jun 20 17:08 __db.001 -rw-------. 1 ldap ldap 188416 Jun 21 14:07 __db.002 -rw-------. 1 ldap ldap 270336 Jun 21 13:46 __db.003 -rw-------. 1 ldap ldap 98304 Jun 21 13:46 __db.004 -rw-------. 1 ldap ldap 753664 Jun 21 14:07 __db.005 -rw-------. 1 ldap ldap 32768 Jun 21 14:07 __db.006 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 dn2id.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 entryCSN.bdb -rw-------. 1 ldap ldap 32768 Jun 20 17:08 id2entry.bdb -rw-------. 1 ldap ldap 10485760 Jun 20 17:08 log.0000000001 -rw-------. 1 ldap ldap 8192 Jun 20 17:08 objectClass.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqEnd.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqResult.bdb -rw-------. 1 ldap ldap 8192 Jun 20 17:08 reqStart.bdb I am new to this forum so If I've missed something please let me know. Constructive comments and suggestions are greatly appreciated. regards RON LAMARCHE Technical Specialist, Online Channel Innovapost

1 0

Re: Limit which database is reachable on which port (slapd is listening on)?
by Howard Chu 22 Jun '17

22 Jun '17

Karsten Heymann wrote: > Hi, > > short question: If I configure slapd to listen to several ports and > have several databases configured, is there a way to limit which > database is visible on which port? I want to use a single slapd > instance to serve multiple databases (slapd-meta instances to be > exact) and for each database want to use a dedicated listening port, > somehow like port-based virtual hosts in the apache web server. The > reason is that I want to define different firewall rules for the > different databases. Is this possible with openldap? Read the slapd.access(5) manpage, use an ACL specifying sockname=xxx for the local port identifier. > Best regards > Karsten > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 7

syncrepl fails after upgrade to openldap 2.4.45
by Juergen.Sprenger＠swisscom.com 22 Jun '17

22 Jun '17

Hi, after upgrading from openldap-2.4.44-r1 to openldap-2.4.45 on my Gentoo machine multi-master-replication does not work anymore. Has anything changed in configuration options for syncrepl or are certificates treated differently now? In the logs I found the following message: Jun 22 10:33:13 ids00000 slapd[30734]: [ID 000001 (local4.debug)] slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) Running slapd in foreground with -d -1 revealed this message: TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). 594b8120 slap_client_connect: URI=ldaps://ldap.dannatu.ch:636 DN="cn=manager,dc=dannatu,dc=ch" ldap_sasl_bind_s failed (-1) My syncrepl configuriation: syncrepl rid=000 provider=ldaps://ldap.dannatu.ch:636 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=dannatu,dc=ch" attrs="*,+" scope=sub bindmethod=simple binddn="cn=Manager,dc=dannatu,dc=ch" credentials=************** I have verified the certificate and my selfsigned ca-certificate with openssl, and both are ok: # openssl verify /etc/ssl/certs/dannatuCA-cacert.pem /etc/ssl/certs/dannatuCA-cacert.pem: OK # openssl verify /etc/ssl/openldap/dannatu.ch.pem /etc/ssl/openldap/dannatu.ch.pem: OK Also verification with openssl s_client seems ok: # openssl s_client -connect ldap.dannatu.ch:636 -tls1_2 CONNECTED(00000003) depth=1 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = Dannatu AG CA, emailAddress = admin(a)dannatu.ch verify return:1 depth=0 C = CH, ST = Solothurn, L = Solothurn, O = Dannatu AG, OU = IT, CN = dannatu.ch, emailAddress = admin(a)dannatu.ch verify return:1 --- Certificate chain 0 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=dannatu.ch/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch 1 s:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch i:/C=CH/ST=Solothurn/L=Solothurn/O=Dannatu AG/OU=IT/CN=Dannatu AG CA/emailAddress=admin(a)dannatu.ch --- After downgrading to openldap-2.4.44-r1 everything worked fine again. Seems certificate handling has changed. Any hints? Juergen Sprenger

1 0

Delete the root entry of a DIT (mdb as backend)
by Hongfu Huang 22 Jun '17

22 Jun '17

Hi all, I have defined a DIT (LMDB) as follows: > dn: olcDatabase={3}mdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {3}mdb > olcDbDirectory: /var/lib/ldap/mycompany/o=mycompany > olcSuffix: o=mycompany > olcRootDN: uid=admin,ou=system > olcAccess: {0}to attrs=userPassword,shadowLastChange by > dn="uid=admin,ou=system" write by anonymous auth by self write by * none > olcAccess: {1}to * by dn="uid=admin,ou=system" write by * none > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbEnvFlags: writemap > olcDbEnvFlags: nometasync > olcDbNoSync: FALSE > olcDbIndex: objectClass pres,eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: uidNumber pres,eq > olcDbIndex: gidNumber pres,eq > olcDbIndex: mail pres,eq,sub > olcDbIndex: ou pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbIndex: givenName pres,eq,sub > olcDbIndex: loginShell pres,eq > olcDbIndex: memberUid pres,eq,sub > olcDbIndex: nisMapName pres,eq,sub > olcDbIndex: nisMapEntry pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 4294967296 > olcDbMode: 0600 > olcDbSearchStack: 16 I can add the root entry as: > dn: o=mycompany > objectClass: organization > objectClass: top > o: mycompany And I can also add and delete sub-entries under o=mycompany. But I can not delete the root entry o=mycompany, even there is no sub-entry below it. Please no that the rootdn (uid=admin,ou=system) is not under the subffix (o=mycompany), that is why no rootPW is defined for this DIT. The rootDN and rootPW are defined in the second DIT (in BDB) The weird thing was that I could search and found it: > ldapsearch -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 -b o=mycompany > # extended LDIF > # > # LDAPv3 > # base <o=cornerbank> with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # mycompany > dn: o=mycompany > o: mycompany > objectClass: organization > objectClass: top > > # search result > search: 2 > result: 0 Success But it would fail if I tried to delete it: > $ ldapdelete -x -D uid=admin,ou=system -w XXXXXXXXX -H > ldap://localhost:389 o=mycompany > ldap_delete: No such object (32) > 32 In the other words, I could import the whole DIT for o=mycompany, but could not delete the whole DIT (the root entry o=mycompany could not be deleted). Does somebody know how to solve this problem? Thanks! Regards -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

2 1

Error: Can't contact LDAP server
by Jelle de Jong 19 Jun '17

19 Jun '17

Hello everybody, # my /etc/ldap/slapd.conf http://paste.debian.net/plainh/076816e3 I am trying to debug an issue for a while and I can use some help. During midday or in the morning there seems to be something happening that is causing smbd (samba) to not be able to connect to the ldap server. Since the machine is localhost is powerfull enough and has free cpu and memory I am wondering what is going on. Maybe there is some connection maximum but these are the only messages I am getting. Does somebody know how to debug this, or know the options to tweak to get rid of the messages? Kind regards, Jelle de Jong Jun 15 12:39:29 stayce smbd[9632]: [2017/06/15 12:39:29.549569, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:29 stayce smbd[9632]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:29 stayce smbd[9632]: #011(unknown) Jun 15 12:39:59 stayce smbd[5683]: [2017/06/15 12:39:59.076347, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:39:59 stayce smbd[5683]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:39:59 stayce smbd[5683]: #011(unknown) Jun 15 12:40:14 stayce smbd[5685]: [2017/06/15 12:40:14.190979, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5685]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5685]: #011(unknown) Jun 15 12:40:14 stayce smbd[5686]: [2017/06/15 12:40:14.232185, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:14 stayce smbd[5686]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:14 stayce smbd[5686]: #011(unknown) Jun 15 12:40:17 stayce smbd[5783]: [2017/06/15 12:40:17.852955, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:17 stayce smbd[5783]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:17 stayce smbd[5783]: #011(unknown) Jun 15 12:40:29 stayce smbd[5787]: [2017/06/15 12:40:29.636496, 0] lib/smbldap.c:1225(smbldap_connect_system) Jun 15 12:40:29 stayce smbd[5787]: failed to bind to server ldap://localhost with dn="cn=admin,dc=companyone,dc=nl" Error: Can't contact LDAP server Jun 15 12:40:29 stayce smbd[5787]: #011(unknown)

2 1

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 19 Jun '17

19 Jun '17

opensource(a)gmx-topmail.de wrote: >> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. > > I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. > > One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. If you meant libc.so yeah, you can't do that. LMDB uses process-shared POSIX mutexes in shared memory. glibc has a fundamental (and unfixable) flaw; it doesn't guarantee compatibility for the internal structure of pthread_mutex_t types between library versions. You cannot safely mix glibc versions among multiple programs concurrently accessing the same LMDB environment. Some details on the glibc issue here https://sourceware.org/bugzilla/show_bug.cgi?id=21119 It affects other libraries like BerkeleyDB too https://bugzilla.redhat.com/show_bug.cgi?id=1394862 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Limit which database is reachable on which port (slapd is listening on)?
by Karsten Heymann 19 Jun '17

19 Jun '17

Hi, short question: If I configure slapd to listen to several ports and have several databases configured, is there a way to limit which database is visible on which port? I want to use a single slapd instance to serve multiple databases (slapd-meta instances to be exact) and for each database want to use a dedicated listening port, somehow like port-based virtual hosts in the apache web server. The reason is that I want to define different firewall rules for the different databases. Is this possible with openldap? Best regards Karsten

1 0

RE: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 18 Jun '17

18 Jun '17

> Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. No, it is a Single Docker instance. Actually, I saw the same thing happening on a Ubuntu box, so it should not be related to Docker. I restructured the CI tests and divided one big test suite into two. Funny thing is that the problem did not occur anymore as of now. One difference between the now separated tests was that they were using a different version of our lib.so (including the same version of LMDB however). But I hardly see how that might cause problems. *Shrug.*

1 0

Re: SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by Howard Chu 18 Jun '17

18 Jun '17

opensource(a)gmx-topmail.de wrote: > We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). Are you running multiple Docker instances on the same database? AFAIK that won't work because of Docker's munging with POSIX namespaces. > The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). > > This is our basic code triggering the SIGSEGV (minus error checking for simplicity): > > mdb_env_create(&dbEnv_); > mdb_env_set_maxdbs(dbEnv_, 8); > mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); > mdb_env_open(dbEnv_, directory, 0, fileMode); > MDB_txn* txn; > mdb_txn_begin(dbEnv_, NULL, 0, &txn); > > It crashes inside mdb_txn_begin with this: > SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 > C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 > > I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: > > /* Not yet touching txn == env->me_txn0, it may be active */ > if (ti) { > if (LOCK_MUTEX(rc, env, env->me_wmutex)) > return rc; > > I also logged some data about the env and the mutex (which looks normal however): > PID: 23603 ENV: 0x7fd1e03e9ab0 > TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 > > Any idea what could go wrong here? > > Thanks! > Markus > > > Some additional crash info: > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 > > Registers: > RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 > RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f > R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 > R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 > RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > > Top of Stack: (sp=0x00007fd22862ff50) > 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 > 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 > 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 > 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 > 0x00007fd22862ff90: 0000000000001020 000000000000003c > 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 > 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 > 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 > 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 > 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 > 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 > 0x00007fd228630000: 0000000000000000 00000000286300c0 > 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 > 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 > 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 > 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a > 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 > 0x00007fd228630060: 0000000000000020 00007fd244000000 > 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 > 0x00007fd228630080: 0000000000000020 00007fd228630660 > 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 > 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 > 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 > 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 > 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b > 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c > 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 > 0x00007fd228630100: 00007fd228630460 00007fd24921f99f > 0x00007fd228630110: 00007fd2286301c8 0000002000000000 > 0x00007fd228630120: 0000000000000000 0000000000000000 > 0x00007fd228630130: 0000000000000000 0000000000000020 > 0x00007fd228630140: 0000000000000000 0000000000000000 > > Instructions: (pc=0x00007fd2607e4b58) > 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 > 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe > 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 > 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 > > Register to memory mapping: > > RAX=0x00007fd22801a060 is an unknown value > RBX=0x00007fd22811b040 is an unknown value > RCX=0x0000000000000000 is an unknown value > RDX=0x0000000000000000 is an unknown value > RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 > RBP=0x0000000000005c4f is an unknown value > RSI=0x0000000000000080 is an unknown value > RDI=0x0000000000005c4f is an unknown value > R8 =0x0000000000000080 is an unknown value > R9 =0x0000000000000000 is an unknown value > R10=0x00007fd22811b060 is an unknown value > R11=0x0000000000000000 is an unknown value > R12=0x0000000000000000 is an unknown value > R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' > R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 > R15=0x00007fd25848b000 is a thread > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Elliptic Curve support in 2.4 branch
by Abdelkader Chelouah 18 Jun '17

18 Jun '17

Elliptic Curve support for OpenSSL was added in master branch 4 years ago (ITS#7595). Is there any plan to backport EC support for OpenSSL in 2.4 branch ?

1 0

slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16
by Jelle de Jong 18 Jun '17

18 Jun '17

Hello everybody, I am getting a lot of these slap_global_control messages in my syslog. I searched online and tried adding the bellow to my /etc/ldap/slapd.conf but it did not help. Does somebody know how to resolve these messages? Kind regards, Jelle de Jong include /etc/ldap/schema/ppolicy.schema Jun 15 13:15:08 cassidy slapd[9071]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16 cassidy:~# slapd -V @(#) $OpenLDAP: slapd (May 30 2017 07:56:03) $ buildd@x86-ubc-01:/build/openldap-BLqnh8/openldap-2.4.40+dfsg/debian/build/servers/slapd cassidy:~# ldapsearch -x -b "" -s base supportedControl # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: supportedControl # # dn: supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

2 1

Re: using -c with slapd to force full reload
by Quanah Gibson-Mount 16 Jun '17

16 Jun '17

--On Thursday, June 15, 2017 4:20 PM -0700 Daniel Jung <mimianddaniel(a)gmail.com> wrote: > > > > -c with RID of the consumer and using Syncrepl. > I see the ITSs are opened for the related issue. I am only seeing this > problem on some consumer and not on the master by the way. I will see if > the masters are not in synced in all the datas. Hi Daniel, Your answer still isn't clear to me. From what you wrote, I would interpret that as doing -c 100 (-c with the RID of the consumer). The man page clearly states it takes a value pair, like -c rid=100 Generally, you're always better off doing a slapcat of the master and a slapadd on the consumer as it takes less time to populate the DB, and you don't have to worry about clients getting results from a partial database. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: using -c with slapd to force full reload
by Daniel Jung 16 Jun '17

16 Jun '17

-c with RID of the consumer and using Syncrepl. I see the ITSs are opened for the related issue. I am only seeing this problem on some consumer and not on the master by the way. I will see if the masters are not in synced in all the datas. On Jun 14, 2017 12:56, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Monday, June 12, 2017 5:19 PM -0700 Daniel Jung < mimianddaniel(a)gmail.com> wrote: Am I misreading the man page where providing rid only with -c forces > full reload? > Also, anyone seeing unsynced entries even though contextcsn is in > synced? > -c or -c 0? syncrepl or delta-syncrepl? There are known cases where replication can fail to properly sync: <http://www.openldap.org/its/index.cgi/?findid=8125> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

SIGSEGV on mdb_txn_begin / __pthread_mutex_lock_full
by opensource＠gmx-topmail.de 15 Jun '17

15 Jun '17

We are using LMDB and are running a big number of tests on a CI server (Debian via Docker, Xenon CPU). The crash happens during opening the database. This is done a lot in the tests without problems (and on Windows this problem does not exist). However, during the CI process we get the crash quite reproducible (~80% crash rate when running the full CI test suite). This is our basic code triggering the SIGSEGV (minus error checking for simplicity): mdb_env_create(&dbEnv_); mdb_env_set_maxdbs(dbEnv_, 8); mdb_env_set_mapsize(dbEnv_, maxDbSizeInKByte * 1024); mdb_env_open(dbEnv_, directory, 0, fileMode); MDB_txn* txn; mdb_txn_begin(dbEnv_, NULL, 0, &txn); It crashes inside mdb_txn_begin with this: SIGSEGV (0xb) at pc=0x00007fd2607e4b58, pid=23603, tid=0x00007fd228633700 C [libpthread.so.0+0x5b58] __pthread_mutex_lock_full+0x1a8 I digged into it a bit, and could tracd it down to this LOCK_MUTEX call in mdb_txn_renew0: /* Not yet touching txn == env->me_txn0, it may be active */ if (ti) { if (LOCK_MUTEX(rc, env, env->me_wmutex)) return rc; I also logged some data about the env and the mutex (which looks normal however): PID: 23603 ENV: 0x7fd1e03e9ab0 TXN: 0x7fd22811b000 COUNT: 0 KIND: 144 LOCK: 0 OWNER: 0 Any idea what could go wrong here? Thanks! Markus Some additional crash info: siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x00007fd22801a058 Registers: RAX=0x00007fd22801a060, RBX=0x00007fd22811b040, RCX=0x0000000000000000, RDX=0x0000000000000000 RSP=0x00007fd22862ff50, RBP=0x0000000000005c4f, RSI=0x0000000000000080, RDI=0x0000000000005c4f R8 =0x0000000000000080, R9 =0x0000000000000000, R10=0x00007fd22811b060, R11=0x0000000000000000 R12=0x0000000000000000, R13=0x00007fd22813b0f0, R14=0x00007fd2286309d0, R15=0x00007fd25848b000 RIP=0x00007fd2607e4b58, EFLAGS=0x0000000000010206, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 TRAPNO=0x000000000000000e Top of Stack: (sp=0x00007fd22862ff50) 0x00007fd22862ff50: 00007fd22813b0f0 00007fd228630040 0x00007fd22862ff60: 0000000000000000 00007fd22813b0f0 0x00007fd22862ff70: 00007fd2286309d0 00007fd20c2d05e4 0x00007fd22862ff80: 00007fd228630050 00007fd22862ff90 0x00007fd22862ff90: 0000000000001020 000000000000003c 0x00007fd22862ffa0: 0000000a00000023 0000000a00000000 0x00007fd22862ffb0: 00007fd228633700 00007fd25fee1c29 0x00007fd22862ffc0: 0000000000000000 00007fd25fe7a423 0x00007fd22862ffd0: 00007fd2286309d0 0000000900000000 0x00007fd22862ffe0: 0000000000000008 00007fd244000000 0x00007fd22862fff0: 00007fd22813b0f0 00007fd25fe79ae3 0x00007fd228630000: 0000000000000000 00000000286300c0 0x00007fd228630010: 0000000000000000 00007fd25fe7b255 0x00007fd228630020: 00007fd22811b000 00007fd1e03e9ab0 0x00007fd228630030: 00007fd1e08f3260 00007fd25fe6fb22 0x00007fd228630040: 00007fd2286300c0 00007fd20c2d0e8a 0x00007fd228630050: 00007fd2286300c0 00007fd2601ac2a0 0x00007fd228630060: 0000000000000020 00007fd244000000 0x00007fd228630070: 0000000800000000 00007fd25fe79ae3 0x00007fd228630080: 0000000000000020 00007fd228630660 0x00007fd228630090: 00007fd1e08f3260 00007fd2286301c8 0x00007fd2286300a0: 00000000601ac2a0 0000000000000000 0x00007fd2286300b0: 00007fd1e03e9ab0 00007fd25fe6fb22 0x00007fd2286300c0: 00007fd228630660 00007fd20c23a768 0x00007fd2286300d0: 0000000200f01b00 00007fd20000003b 0x00007fd2286300e0: 00007fd20c2eb3fd 00007fd24921da4c 0x00007fd2286300f0: 00000005cac01420 00007fd22814c210 0x00007fd228630100: 00007fd228630460 00007fd24921f99f 0x00007fd228630110: 00007fd2286301c8 0000002000000000 0x00007fd228630120: 0000000000000000 0000000000000000 0x00007fd228630130: 0000000000000000 0000000000000020 0x00007fd228630140: 0000000000000000 0000000000000000 Instructions: (pc=0x00007fd2607e4b58) 0x00007fd2607e4b38: 00 a9 00 00 00 40 0f 85 02 ff ff ff c7 43 04 01 0x00007fd2607e4b48: 00 00 00 64 48 8b 04 25 e0 02 00 00 48 83 e0 fe 0x00007fd2607e4b58: 4c 89 50 f8 64 48 8b 04 25 e0 02 00 00 48 89 43 0x00007fd2607e4b68: 20 64 48 8b 04 25 10 00 00 00 48 05 e0 02 00 00 Register to memory mapping: RAX=0x00007fd22801a060 is an unknown value RBX=0x00007fd22811b040 is an unknown value RCX=0x0000000000000000 is an unknown value RDX=0x0000000000000000 is an unknown value RSP=0x00007fd22862ff50 is pointing into the stack for thread: 0x00007fd25848b000 RBP=0x0000000000005c4f is an unknown value RSI=0x0000000000000080 is an unknown value RDI=0x0000000000005c4f is an unknown value R8 =0x0000000000000080 is an unknown value R9 =0x0000000000000000 is an unknown value R10=0x00007fd22811b060 is an unknown value R11=0x0000000000000000 is an unknown value R12=0x0000000000000000 is an unknown value R13={method} {0x00007fd22813b0f0} 'nativeCreate' '(Ljava/lang/String;J[B)J' in 'MyDb' R14=0x00007fd2286309d0 is pointing into the stack for thread: 0x00007fd25848b000 R15=0x00007fd25848b000 is a thread

1 0

Re: using -c with slapd to force full reload
by Quanah Gibson-Mount 14 Jun '17

14 Jun '17

--On Monday, June 12, 2017 5:19 PM -0700 Daniel Jung <mimianddaniel(a)gmail.com> wrote: > Am I misreading the man page where providing rid only with -c forces > full reload? > Also, anyone seeing unsynced entries even though contextcsn is in > synced? -c or -c 0? syncrepl or delta-syncrepl? There are known cases where replication can fail to properly sync: <http://www.openldap.org/its/index.cgi/?findid=8125> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Attempting to set Access Control for auth to Perl Backend
by Quanah Gibson-Mount 13 Jun '17

13 Jun '17

--On Tuesday, June 06, 2017 5:32 PM +0000 Etan Weintraub <eweintra(a)jhmi.edu> wrote: > I now need to do the same type of thing for another branch, but for > authentication instead (i.e. only allow auth to occur if coming from an > approved IP). I've tried the following: > > access to dn.sub="dc=mfa" > > by peername.ip=127.0.0.1 auth > > by peername.ip=10.181.24.193 auth > > by * none > > > > But no luck. Any ideas/help? If I can't do this with an ACL, if I can > get the IP address of the request passed in to the bind function in the > Perl backend, I can handle the controls there. That's not really what "auth" access means. Are you using simple binds? If so, I'd try something like: access to dn.sub="dc=mfa" attrs=userPassword by peername.ip=127.0.0.1 anonymous auth by peername.ip=10.181.24.193 anonymous auth by <admin> write access to dn.sub="dc=mfa" by users read Now this makes some assumptions: a) Users auth against an entry in the dc=mfa tree, and b) that users only exist in that tree. Alternatively, you may wish to look at set based ACLs to set it so that only entries that exist /in/ the dc=mfa tree can read entries in the dc=mfa tree, combined with the IP restrictions. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

OpenLDAP 2.4.45 LTB packages available
by Clément OUDOT 13 Jun '17

13 Jun '17

Hello, the LDAP Tool Box team has published RPM and Debian packages for OpenLDAP 2.4.45. You can download them directly or use APT/YUM repositories: https://ltb-project.org/download Documentation: * https://ltb-project.org/documentation/openldap-deb * https://ltb-project.org/documentation/openldap-rpm GitHub projects: * https://github.com/ltb-project/openldap-deb * https://github.com/ltb-project/openldap-rpm Clément.

1 0

using -c with slapd to force full reload
by Daniel Jung 13 Jun '17

13 Jun '17

Hi, Using 2.4.44 on centos 6 with multimaster 4 ways. I have been noticing more unsynced entries from the master on the consumer side ever since I have enabled chain overlay to pass ppolicy failure from slaves to the master. While the problem is not frequent, it has cropped up quite a few times so I tried using -c to force reload but this doesn't seem to work even though, contextcsn on the producer and consumers are equal. Only real solution so far has been wiping out data.mdb then restarting the slapd which 100% fixes the problem. Am I misreading the man page where providing rid only with -c forces full reload? Also, anyone seeing unsynced entries even though contextcsn is in synced? Cheers

1 0

Re: LDAP Issue: Logging region out of memory; you may need to increase its size
by Quanah Gibson-Mount 10 Jun '17

10 Jun '17

--On Saturday, June 10, 2017 12:00 PM +0200 Dieter Klünter <dieter(a)dkluenter.de> wrote: > Am Fri, 9 Jun 2017 11:27:32 +0000 > schrieb Gurjot Kaur <gurjot.kaur(a)aricent.com>: > >> Hello, >> >> On an already running setup of OpenLDAP 2.4 on Linux (Linux GURKES015 >> 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 >> x86_64 GNU/Linux) platform, one day I start getting following error >> when I execute the slapcat command: >> >> bdb_db_open: warning - no DB_CONFIG file found in I would also note that for current releases of OpenLDAP, the bdb backend is deprecated, and it's proably worthwhile to take the time to migrate to back-mdb, which doesn't have these issues. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

rwm - send in peername?
by Etan Weintraub 08 Jun '17

08 Jun '17

Is there a way to reference the remote IP (I'm assuming that's in peername based on ACL's) in configuration directives? I.e. I'd like to do the following: overlay rwm rwm-rewriteEngine on rwm-rewriteParam remoteip {peername} rwm-rewriteContext bindDN rwm-rewriteRule "^(.+,)?dc=mfa$" "$1dc=${$remoteip},dc=mfa" ":@" And have the DN for the bind look like uid=user,dc=127.0.0.1,dc=mfa instead of uid=user,dc=mfa Is that possible? -Etan E. Weintraub Information Security Architect IT@Johns Hopkins Johns Hopkins at Mt. Washington <x-apple-data-detectors://4/> 5801 Smith Ave. Davis Building <x-apple-data-detectors://4/> Suite 3110B <x-apple-data-detectors://5/0> Baltimore, MD 21209 Phone: <tel:667-208-6309> 667-208-6309 E-mail: <mailto:eweintra@jhmi.edu> eweintra(a)jhmi.edu

1 0

RE: Limiting which attributes get replicated
by Quanah Gibson-Mount 08 Jun '17

08 Jun '17

--On Thursday, June 08, 2017 2:38 PM +0000 Etan Weintraub <eweintra(a)jhmi.edu> wrote: > Actually, I've found another possible way. If I use the rwm overlay, I can > modify the DN that is sent in. I just need a way to get the IP to put in > the rewriteRule and I should be good. Any ideas on that? I'm not clear on what slapo-rwm has to do with limiting what attributes get replicated. This isn't about rewrite. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Limiting which attributes get replicated
by Quanah Gibson-Mount 08 Jun '17

08 Jun '17

--On Thursday, June 08, 2017 12:28 PM +0100 Philip Colmer <philip.colmer(a)linaro.org> wrote: > What happens if one of the consuming LDAP servers is then itself > queried for an attribute that hasn't been synced? So, for example, if > a system in a data centre connects to a local consuming LDAP server > and asks for a jpegPhoto, that won't be on the local server, so what > happens then? Might be easiest to use an ACL to drop the attributes you don't want it to replicate for the replication DN for those consumers. As for what happens when a client requests jpegPhoto and it doesn't exist, the same thing that happens for any client that requests an attribute that doesn't exist -- It won't get a result that includes that attribute. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Limiting which attributes get replicated
by Philip Colmer 08 Jun '17

08 Jun '17

Hi We've got a core set of OpenLDAP servers that are in a multi-master configuration. We are looking at building out that set of servers so that our data centres can have local copies of the data. However, those copies don't need to be of everything, so I want to limit which attributes get replicated. I wanted to check that I've understood the configuration correctly ... According to http://www.openldap.org/doc/admin22/syncrepl.html, it looks like I can specify on the consuming LDAP server which attributes are synced, and I can also ensure that the binddn account only has access to those attributes on the providing LDAP server. The example given in the documentation has: filter="(objectClass=organizationalPerson)" What do I do if I want to synchronise all objectClasses but only restrict the attributes on the organizationalPerson class? So, for example, I want everything on groups but I don't want jpegPhoto on people. What happens if one of the consuming LDAP servers is then itself queried for an attribute that hasn't been synced? So, for example, if a system in a data centre connects to a local consuming LDAP server and asks for a jpegPhoto, that won't be on the local server, so what happens then? Thank you. Philip

1 0

Security Enclaves
by Derrick McKee 08 Jun '17

08 Jun '17

Greetings, I am a computer security researcher working on adding functionality to the hardware security enclaves recently released on CPUs (e.g. Intel SGX or ARM TrustZone). I think that OpenLDAP would suit my purposes well, and I was thinking of attempting to secure SASL and TLS/SSL functionality. My plan is to get OpenSSL to use the secure enclave, and adopt OpenLDAP to use the enclave as well for SASL and TLS. I just need a little help on where to start looking. I have seen sasl.c and saslauthz.c in servers/slapd, as well as tls2.c in libraries/libldap and libraries/libldap_r. Anywhere else I should be looking? Is the only difference between libraries/libldap and libraries/libldrap_r just the use of threads? Finally, any other ideas about what else I can protect? For those unfamiliar, security enclaves allow for virtual address ranges to be encrypted/decrypted on the processor itself. So even an adversary with root privileges would not be able to read data/code/whatever within the secure address range. Thanks in advance for any help. - Derrick McKee -- Derrick McKee Ph.D. Student at Purdue University

1 0

Attempting to set Access Control for auth to Perl Backend
by Etan Weintraub 06 Jun '17

06 Jun '17

Hi all- I'm configuring an OpenLDAP server with the Perl Backend. I've been able to set permissions for search on one of my backends to lock it down based on IP as follows: access to dn.sub="dc=alias" by peername.ip=127.0.0.1 read by peername.ip=10.181.24.193 read by peername.ip=10.181.35.243 read by * none That makes it that only those IP's listed can search and get results from that branch. I now need to do the same type of thing for another branch, but for authentication instead (i.e. only allow auth to occur if coming from an approved IP). I've tried the following: access to dn.sub="dc=mfa" by peername.ip=127.0.0.1 auth by peername.ip=10.181.24.193 auth by * none But no luck. Any ideas/help? If I can't do this with an ACL, if I can get the IP address of the request passed in to the bind function in the Perl backend, I can handle the controls there. -Etan E. Weintraub Information Security Architect IT@Johns Hopkins Johns Hopkins at Mt. Washington <x-apple-data-detectors://4/> 5801 Smith Ave. Davis Building <x-apple-data-detectors://4/> Suite 3110B <x-apple-data-detectors://5/0> Baltimore, MD 21209 Phone: <tel:667-208-6309> 667-208-6309 E-mail: <mailto:eweintra@jhmi.edu> eweintra(a)jhmi.edu

1 0

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 05 Jun '17

05 Jun '17

Prentice Bisbal wrote: > On 05/31/2017 12:37 AM, John Lewis wrote: > >> What if I wanted to write a OpenLDAP backend for a systemd journal file >> or Elasticsearch so I can present my logs as an LDAP subtree so I can >> use my LDAP tools to filter my logs? Should I use back-shell for >> prototyping? If so, what is the usual work flow? > This sounds like the wrong tool for this job. Really? Can you give a point by point comparison against what you think is the "right" tool for the job? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Directory Sever Gateway for OpenLDAP
by John Lewis 05 Jun '17

05 Jun '17

Is there something like 389 Directory Server Gateway (389-dsgw) for OpenLDAP? Is there some way to borrow 389-dsgw itself and run it standalone and aim it at OpenLDAP? I am looking for some kind of service I can run to get a phonebook, orgchart, advanced search interface, and DSML gateway. Having a frontend like this would make it easier for people to buy into the idea of a directory server for things they interact with directly before introducing thick clients.

2 1

Re: How wold you go about writing a new OpenLDAP backend?
by Quanah Gibson-Mount 02 Jun '17

02 Jun '17

--On Friday, June 02, 2017 3:02 PM -0400 Prentice Bisbal <pbisbal(a)pppl.gov> wrote: > Well, that certainly sounds like the missing link, doesn't it? ;) > > What is different about your native backends that makes them so much > faster? Domain-specific design? I haven't been keeping up with OpenLDAP > over the past few years. The versions I've used in the bast used BDB for > the backend. I've been charged with upgrading an old LDAP server, and as > I was looking through the documentation for the latest version, I saw > that you have some new native backend(s), but I didn't have time to read > up on them. You might find some of this useful: <https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database> <https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb…> <http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance> There's also a ton more information at: <https://symas.com/lightning-memory-mapped-database/> Scroll to the bottom and look at the "Project presentations" section and the "Benchmarks" section, in addition to the rest of the useful information. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

OpenLDAP 2.4.45 available...openSUSE / SLES RPMs
by Michael Ströder 02 Jun '17

02 Jun '17

OpenLDAP Project wrote: > OpenLDAP 2.4.45 is now available for download as detailed on our download page: Devel builds for various openSUSE / SLES versions are here: https://build.opensuse.org/package/show/network:ldap/openldap2 You can directly add appropriate repo from herein: https://download.opensuse.org/repositories/network:/ldap/ Example for adding the repo on openSUSE Tumbleweed: zypper addrepo -f https://download.opensuse.org/repositories/network:/ldap/openSUSE_Tumblewee… Ciao, Michael.

1 0

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 02 Jun '17

02 Jun '17

Prentice Bisbal wrote: > On 05/31/2017 04:39 PM, John Lewis wrote: >> On Wed, 2017-05-31 at 15:07 -0400, Prentice Bisbal wrote: >>> On 05/31/2017 02:55 PM, Howard Chu wrote: >>>> Prentice Bisbal wrote: >>>>> On 05/31/2017 12:37 AM, John Lewis wrote: >>>>> >>>>> This sounds like the wrong tool for this job. >>>> Really? Can you give a point by point comparison against what you >>>> think is the "right" tool for the job? >>> That's the wrong question to ask, since I never made any claim as to >>> what the right tool is. A better question to ask would be why I think >>> this is the wrong tool. So here's my reply to that: It doesn't seem like >>> this is a job LDAP was designed for. To me, LDAP is really just a >>> standardized database interface that make certain type of DB looks up >>> easy, and most importantly, standardized.I would think a more general >>> purpose database interface would be better for this. >>> >>> Unfortunately, I'm not a database expert, so I can't give you the >>> "point-by-point argument you requested. >>> >>> Now your turn - why would OpenLDAP be a good fit for this over other >>> databases? >>> >>> -- >>> Prentice >>> >> Yes, LDAP is really just a standardized database interface. That is the >> point. I want my logs available through an IETF standardized protocol so >> I can reuse tools so I don't have to maintain as many tools. >> >> OpenLDAP would be a good fit over other databases because Michael, and >> Howard, and the other contributers to OpenLDAP did most of the work for >> me. >> > > Fair enough answer. How would you store and retrieve your results? Are you > creating/using a schema specifically for this? If so, what does it look like. > > I'm still having trouble seeing the performance benefits, though. The data is > still stored in a backend DB, right? Let's say that backend is some sort of > SQL DB. You write your ldapsearch query, and then LDAP converts that to SQL, > and then the DB returns the results to LDAP, which then translated the results > to LDIF and returns them to you. Isn't there performance hits every time you > traverse the LDAP layer? > > I suppose this might still be faster than reading a plain-text log file. Is > that the point I'm missing? OpenLDAP's native backends are multiple orders of magnitude faster than every SQL DB. That seems to be the crucial point you're missing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

problem with syncrepl and STARTTLS
by r0m5 02 Jun '17

02 Jun '17

Hello, I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of problem happening only sometimes, and disappearing "by itself". I use Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. Description : I have a production environment, and a preproduction environment. Both of them consist of one provider and multiple consumers. Right now all is working fine. Then 2 times a days a script injects the production data in the preproduction environment : ldapsearch on prod / ldapdelete on preprod / stop slapd on preprod / slapadd on preprod / start slapd on preprod. Then sometimes during this injection I get a problem : one or more of the consumers in preprod fail to sync. But sometimes all are OK. Then the consumers facing the issue succeed syncrepl again "by themselves" after a few dozens of minutes / hours. If I restart slapd on the failing consumers, then the syncrepl succeeds immediately. When the syncrepl is failing, I can still perform an ldapsearch using STARTTLS and the syncrepl binding credentials from the consumer to the provider. There is no issue with non-TLS LDAP replications. Also, using ldapsearch with option "-d 3" I get TLS debug, but even with "olcLogLevel -1" in cn=config I can't get precise debug for TLS during syncrepl. I captured the trafic and when there is the error, wireshark at some point can't understand TLS sent by the consumer (SSL "ignored unknown record"). Corresponding data is "30 05 02 01 02 42 00". Not sure it's related to the problem though, but it looks like since (if I am right) the first information in TLS is the content-type, and 30 is not a valid value for content type (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…). Any idea ? I would like to avoid making the injection script connect to all my preprod consumers and restart slapd on them. Please feel free to ask for more logs / configurations. Log on the provider : May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: slap_listener_activate(9): May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 busy May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: >>> slap_listener(ldap:///) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: listen=9, new connection on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: added 18r (active) listener=(nil) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 ACCEPT from IP=192.168.115.61:33816 (IP=0.0.0.0:389) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: op tag 0x77, time 1496231248 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 do_extended May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: do_extended: oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 STARTTLS May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_extended: err=0 oid= len=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_response: msgid=1 tag=120 err=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 RESULT oid= err=0 text= May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): unable to get TLS client DN, error=49 id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 TLS established tls_ssf=128 ssf=128 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 2 descriptors May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: ber_get_next on fd 18 failed errno=0 (Success) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): input error=-2 id=1010, closing. May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_closing: readying conn=1010 sd=18 for close May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_close: conn=1010 sd=18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: removing 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 closed (connection lost) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero Log on the consumer : May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: =>do_syncrepl rid=006 May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: slap_client_connect: URI=ldap://ldap-master-pp.acme Error, ldap_start_tls failed (-11) May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: do_syncrepl: rid=006 rc -11 retrying May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero syncrepl config on consumer : olcSyncrepl: {0}rid=6 provider=ldap://ldap-master-pp.acme starttls=critical t ls_reqcert=never bindmethod=simple binddn="cn=replication,ou=Applications,d c=acme,dc=fr" credentials=**** searchbase="dc=acme,dc=fr" schemacheck ing=off type=refreshAndPersist filter="(objectClass=*)" attrs="*" scope=sub retry="60 +" TLS config on provider : dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 9efabaca-b31f-1036-9746-2d4f8feb88f1 creatorsName: cn=config createTimestamp: 20170411162820Z olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcLogLevel: 256 entryCSN: 20170531131949.877388Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170531131949Z

1 0

How wold you go about writing a new OpenLDAP backend?
by John Lewis 31 May '17

31 May '17

What if I wanted to write a OpenLDAP backend for a systemd journal file or Elasticsearch so I can present my logs as an LDAP subtree so I can use my LDAP tools to filter my logs? Should I use back-shell for prototyping? If so, what is the usual work flow?

2 1

OpenLDAP / Active directory cohabitation
by Alexandre Rosenberg 31 May '17

31 May '17

Hello, I am in a environment where we use both OpenLDAP and Active Directory. All Linux servers authenticate against OpenLDAP where we have user group, unix group (...) I would like to keep everything the same except that when the user bind to OpenLDAP the credential should be checked against Active Directory. There is no need to retrieve/return any information from Active Directory except for the authentication. This means that if perform a BIND and a search, the BIND should be performed against the AD but the search result should from OpenLDAP. (anonymous search is fine) One complication is that we have 2 times of usernames: short username: john01 long username: john.smith(a)example.com The short username are used in in OpenLDAP like this: uid=john01,ou=People,dc=example,dc=com While the AD uses the long username. From my test when binding to AD, only the "DN" is simply set to the username. john.smith(a)example.com I am starting to seriously look at the various OpenLDAP overlay and proxy functionality but I am a bit confused on how to archive this. Best regards, Alexandre

5 4

Re: SIGPIPE on OS X fix still pending (ITS#8590)
by Quanah Gibson-Mount 31 May '17

31 May '17

--On Wednesday, May 31, 2017 12:11 PM +0100 Lorenz Bauer <lmb(a)cloudflare.com> wrote: > Hello Quanah, > > On 26 May 2017 at 20:36, Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> Generally, we need secondary confirmation on the patch. > > That makes sense. I've written a test program which exercises the > different ways of generating SIGPIPE, available at [1]. This should > make verifying the patch easier. I'll also update the ITS. > > Best, > Lorenz > > 1: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb Thanks, I will discuss with the rest of the team about getting this integrated into the LMDB test suite. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Migration from ApacheDS to OpenLDAP
by Hongfu Huang 31 May '17

31 May '17

Hi all, Is there an easy way to migrate an ApacheDS to an OpenLDAP? Can just export everything in an ldif file from ApacheDS and then import it into an OpenLDAP? Or what should I definitely take care of here? For example, the schema mapping? Should I create a separate DIT(DBs) in OpenLDAP for each partition in ApacheDS? Thanks for any suggestions! Regards Hongfu -- Hongfu Huang, Senior System Integrator M.Sc. Computer Science AdNovum Informatik AG Roentgenstrasse 22, 8005 Zurich, Switzerland phone +41 44 272 6111, direct +41 44 270 5266 hongfu.huang(a)adnovum.ch, www.adnovum.ch Locations: Zurich (HQ), Bern, Lausanne, Budapest, Ho Chi Minh City, Singapore

3 2

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 31 May '17

31 May '17

Michael Ströder wrote: > Howard Chu wrote: >> John Lewis wrote: >>> What if I wanted to write a OpenLDAP backend for a systemd journal file >>> or Elasticsearch so I can present my logs as an LDAP subtree so I can >>> use my LDAP tools to filter my logs? Should I use back-shell for >>> prototyping? If so, what is the usual work flow? >> >> back-shell might work for rough prototyping. back-sock would be more reasonable these >> days. > > For prototyping a back-sock listener in Python you could give module slapdsock a try: > > https://pypi.python.org/pypi/slapdsock > > Personally I use it for OATH-LDAP's bind listeners which seem to work fairly robust on > moderate load. But the release 0.5.2 should also work with all other request types. > > If you have a non-trivial deployment the sheer amount of log data can cause some > interesting performance issues. Indeed. Still it's an interesting idea; I've often thought about writing an ElasticSearch replacement on top of OpenLDAP. In a native backend it would be orders of magnitude faster than their stuff. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 2

Re: How wold you go about writing a new OpenLDAP backend?
by Howard Chu 31 May '17

31 May '17

John Lewis wrote: > What if I wanted to write a OpenLDAP backend for a systemd journal file > or Elasticsearch so I can present my logs as an LDAP subtree so I can > use my LDAP tools to filter my logs? Should I use back-shell for > prototyping? If so, what is the usual work flow? back-shell might work for rough prototyping. back-sock would be more reasonable these days. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: SIGPIPE on OS X fix still pending (ITS#8590)
by Lorenz Bauer 31 May '17

31 May '17

Hello Quanah, On 26 May 2017 at 20:36, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Generally, we need secondary confirmation on the patch. That makes sense. I've written a test program which exercises the different ways of generating SIGPIPE, available at [1]. This should make verifying the patch easier. I'll also update the ITS. Best, Lorenz 1: https://gist.github.com/lmb/a35e7b9566fa79e7bf971ac21bbb9efb -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com

1 0

Re: Re: OpenLDAP / Active directory cohabitation
by Clément OUDOT 30 May '17

30 May '17

2017-05-30 8:10 GMT+02:00 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>: > I have one question: Why is hte AD admin accound needed to authenticate? I see > a problem with the AD admin password being stored in cleartext in the saslauthd > configuration... You don't need AD admin password, you just need a standard AD account that can read user entries (no write access required). Clément.

1 0

Re: Antw: Re: OpenLDAP / Active directory cohabitation
by Dan White 30 May '17

30 May '17

On 05/30/17 08:10 +0200, Ulrich Windl wrote: >>>> Clément OUDOT <clem.oudot(a)gmail.com> schrieb am 29.05.2017 um 20:43 in >Nachricht ><CAK_oV4-DYo6d=LgWnu7foGkYQ4n9mjHiDbmo1t9uGyJT5e8EFQ(a)mail.gmail.com>: >> 2017-05-29 19:00 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>: >>> On 05/29/17 23:36 +0900, Alexandre Rosenberg wrote: >>>> >>>> I am in a environment where we use both OpenLDAP and Active Directory. >>>> All Linux servers authenticate against OpenLDAP where we have user group, >>>> unix group (...) >>> >>> Pass-through authentication should work if you're performing simple binds. >>> Chapter 14 of the admin guide has a good example. >> >> You can also find a tutorial here: >> https://ltb-project.org/documentation/general/sasl_delegation > >I have one question: Why is hte AD admin accound needed to authenticate? I see >a problem with the AD admin password being stored in cleartext in the saslauthd >configuration... Here's a simpler approach that does not require storing a password: https://www.openldap.org/lists/openldap-technical/201106/msg00198.html This was tested against AD 2003. You may need to use ldaps with newer versions. -- Dan White

1 0

ACL and Dynamic Groups
by Ivan Athanazio 28 May '17

28 May '17

Dear Members, I have a problem that consists in allow a member of a group to manage accounts that have a value in an attribute. My organization structure is as the following example: -Organization --Branch1 ---Branch1-HR ---Branch1-divisionA ---Branch2-divisionB --Branch2 ---Branch2-HR The way that I figured out to make it work was using Dynamic Lists to group users that have the attribute value. So I activated the dynlists overlay and configured it. My OpenLDAP DIT is as showed bellow: -dc=something,dc=something2,dc=br --ou=Group ---cn=s-brach1admin-rw ----dn=uid=user3,ou-People,dc=something,dc=something2,dc=br ---cn=branch1-users (dynamic group that contains DN's of users filtered by departmentNumber=divisionA or departmentNumber=divisionB) ----dn=uid=user1,ou-People,dc=something,dc=something2,dc=br ----dn=uid=user2,ou-People,dc=something,dc=something2,dc=br --ou=People ---uid=user1 (attr: inetorgperson departmentNumber=divisionA) ---uid=user2 (attr: inetorgperson departmentNumber=divisionB) ---uid=user3 So, now, I need an ACL that allow members of cn=s-branch1admin-rw to manage user1, user2 and any other user that is in the dynamic group cn=branch1-users. I searched the web and didn't found any result that shows exactly how to build this ACL. I tried some ways to write it, specially this two forms: 1) access to dn.children="cn=branch1-users,dc=something,dc=something2,dc=br" by set="[cn=s-branch1admin-rw,ou=Group,dc=something,dc=something2,dc=br]/member*" manage 2) access to dn.children="cn=branch1-users,dc=something,dc=something2,dc=br" by group.exact="cn=s-branch1admin-rw,ou=Group,dc=something,dc=something2,dc=br" manage And some other forms and any of these appears to work. So, If someone already did it or know about it, can help me with ACL and Dynamic Groups? Thanks for the help and for the patience with my long e-mail. Best regards! Ivan Athanazio

1 0

Re: SIGPIPE on OS X fix still pending (ITS#8590)
by Quanah Gibson-Mount 26 May '17

26 May '17

--On Thursday, May 25, 2017 3:11 PM +0100 Lorenz Bauer <lmb(a)cloudflare.com> wrote: > Hello list / maintainers, > > I submitted http://www.openldap.org/its/index.cgi?findid=8590 back in > February, and it's still pending. Could you have a look and let me > know if the patch is acceptable? Hi Lorenz, Generally, we need secondary confirmation on the patch. I'm not aware of anyone on the OpenLDAP development team that makes use of OSX, so we're not really able to do that in this case. Some Apple employees used to lurk on here, I don't know if they still do. Or perhaps there are others on the list that can confirm. 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: Can I do this with openldap ?
by Quanah Gibson-Mount 26 May '17

26 May '17

--On Friday, May 26, 2017 12:07 PM +0000 Roelof Wobben <rwobben(a)hotmail.com> wrote: > > > Thanks all. I use now Ubuntu 17.04 for the client and Ubuntu 16.06 LTS > for the server. > > > > So as I understand LDAP can only be used for authentication and for > autortication I have to look for other software. LDAP can be used for both authz and authc if the software in question was well written. If the software in question was poorly written, it probably won't be possible. But that is not an LDAP limitation, that is a limitation due to the software developer. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Can I do this with openldap ?
by Roelof Wobben 26 May '17

26 May '17

Hello, My boss wants to run everything from a server. But he wants also that I can take care of that some of the software is only used by some people. So the cad software is only used by the drawers and not by the financial people. Can I do this with openldap or if it cannot be done , which software can I then use the best. I work on Ubuntu Server 16.04 LTS. Regards, Roelof

6 6

SIGPIPE on OS X fix still pending (ITS#8590)
by Lorenz Bauer 25 May '17

25 May '17

Hello list / maintainers, I submitted http://www.openldap.org/its/index.cgi?findid=8590 back in February, and it's still pending. Could you have a look and let me know if the patch is acceptable? Best, Lorenz -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com

1 0

RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount 25 May '17

25 May '17

This is expected to be the final testing call for 2.4.45, with an anticipated release, depending on feedback, during the week of 2017/05/29. For this testing call, we particularly need folks to test OpenLDAP with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with the 1.1 series). There is currenly nothing in the test suite that covers encrypted connections (Although it's on my todo list). To build against OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT repository, depending on your build options as the current cyrus-sasl release does not support the OpenSSL 1.1 series. It can be found at <https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that is where OpenSSL 1.1 support was added). It can be obtained from <http://h5l.org/>. Also new with this release is the ability to run "make its" in the tests/ directory. This will run a specific set of tests around past bugs to ensure there are no regressions. While I've tested this with modular openldap builds, it has not been tested with the modules and backends built into slapd, so there could be some issues in that scenario. 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 run through the regression suite. Thanks! OpenLDAP 2.4.45 Engineering Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533, ITS#8634) Fixed libldap to fail ldap_result if the handle is already bad (ITS#8585) Fixed libldap to expose error if user specified CA doesn't exist (ITS#8529) Fixed libldap handling of Diffie-Hellman parameters (ITS#7506) Fixed libldap GnuTLS use after free (ITS#8385) Fixed libldap SASL initialization (ITS#8648) Fixed slapd bconfig rDN escape handling (ITS#8574) Fixed slapd segfault with invalid hostname (ITS#8631) Fixed slapd sasl SEGV rebind in same session (ITS#8568) Fixed slapd syncrepl filter handling (ITS#8413) Fixed slapd syncrepl infinite looping mods with delta-sync MMR (ITS#8432) Fixed slapd callback struct so older modules without writewait should function. Custom modules may need to be updated for sc_writewait callback (ITS#8435) Fixed slapd-ldap/meta broken LDAP_TAILQ macro (ITS#8576) Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794) Fixed slapd-mdb double free with size zero paged result (ITS#8655) Fixed slapd-meta uninitialized diagnostic message (ITS#8442) Fixed slapo-accesslog to honor pauses during purge for cn=config update (ITS#8423) Fixed slapo-accesslog with multiple modifications to the same attribute (ITS#6545) Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428) Fixed slapo-sssvlv double free (ITS#8592) Fixed slapo-unique with empty modifications (ITS#8266) Build Environment Added test065 for proxyauthz (ITS#8571) Fix test008 to be portable (ITS#8414) Fix test064 to wait for slapd to start (ITS#8644) Fix its4336 regression test (ITS#8534) Fix its4337 regression test (ITS#8535) Fix regression tests to execute on all backends (ITS#8539) Contrib Added slapo-autogroup(5) man page (ITS#8569) Added passwd missing conversion scripts for apr1 (ITS#6826) Fixed contrib modules where the writewait callback was not correctly initialized (ITS#8435) Fixed smbk5pwd to build with newer OpenSSL releases (ITS#8525) Documentation admin24 fixed tls_cipher_suite bindconf option (ITS#8099) admin24 fixed typo cn=config to be slapd.d (ITS#8449) admin24 fixed slapo-syncprov information to be curent (ITS#8253) admin24 fixed typo in access control docs (ITS#7341, ITS#8391) admin24 fixed minor typo in tuning guide (ITS#8499) admin24 fixed information about the limits option (ITS#7700) admin24 fixed missing options for syncrepl configuration (ITS#7700) admin24 fixed accesslog documentation to note it should not be replicated (ITS#8344) Fixed ldap.conf(5) missing information on SASL_NOCANON option (ITS#7177) Fixed ldapsearch(1) information on the V[V] flag behavior (ITS#7177, ITS#6339) Fixed slapd-config(5), slapd.conf(5) clarification on interval keyword for refreshAndPersist (ITS#8538) Fixed slapd-config(5), slapd.conf(5) clarify serverID requirements (ITS#8635) Fixed slapd-config(5), slapd.conf(5) clarification on loglevel settings (ITS#8123) Fixed slapo-ppolicy(5) to clearly note rootdn requirement (ITS#8565) Fixed slapo-memberof(5) to note it is not safe to use with replication (ITS#8613) Fixed slapo-syncprov(5) documentation to be current (ITS#8253) Fixed slapadd(8) manpage to note slapd-mdb (ITS#8215) Fixed various minor grammar issues in the man pages (ITS#8544) Fixed various typos (ITS#8587) LMDB 0.9.20 Release Engineering Fix mdb_load with escaped plaintext (ITS#8558) Fix mdb_cursor_last / mdb_put interaction (ITS#8557) Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Search for primary group
by Bernard Fay 23 May '17

23 May '17

Hello, Is there a way to find the primary group of a user with ldapsesarch or other command? I run OpenLDAP version 2.4.40 on CentOS 7.2 if that matters. Thanks, Bernard

2 1

Re: mdb_dbi_open and threads
by Howard Chu 22 May '17

22 May '17

Muhammed Muneer wrote: > Hallvard wrote > "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), > thread 1's prospect of using mdb_dbi_open() at all was lost." > > Yeah with both coexisting. Thats what I thought. > > @Klaus > > > Yeah. I know there can be only one write transactions. I was talking about 1 > write and 1 or more read transactions. > It is not as if I am first looking to open dbi in the read transaction. It is > because I can't guarantee whether another read transaction will > start and will attempt to open the same named dbi when a write is in progress. > > "And first looking in a read transaction whether a database exists and then > creating it in a second write transaction is definitely a bad and risky > programming style, as it carries an assumption from one transaction to the > next, which is typically not valid." > > That was not what I tried to do. > > "you still have the option to combine all your logical databases into a big > single database" > > Its a workaround that I haven't thought about before. Hoping to avoid the > extra complexity. > > Is there any prospect of implementing mdb_dbi_open or mdb_db_open_immediate to > put the dbi into the shared environment without waiting for txn commit. > I learned earlier from Howard Chu that it is not a wanted phenomenon in ACID. > But just in case, because otherwise (without opening all the dbi's in > initialization) in a multi-threaded > environment, the possibility to open a dbi on demand ending in failure goes up. No. Transaction isolation is a fundamental feature, breaking isolation is not allowed. If you want to use dbi_open in multiple threads then put it in your own wrapper function, protected by a mutex. Naturally you will also have to wrap dbi_close the same way. Note that even if you open and close on demand, you're going to have to configure maxdbs to the largest number that can possibly be open at once so there won't be much memory savings. All in all it's a stupid approach with more costs than benefits. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: mdb_dbi_open and threads
by Howard Chu 22 May '17

22 May '17

Muhammed Muneer wrote: > Thanks for clarifying. > I did get the impression but there was some part of it where I thought the doc > was not clear enough. It is a fundamental principle of ACID transactions. The "I" in ACID stands for Isolation. That means nothing that changes elsewhere, while a transaction is underway, can affect that particular transaction. Since we already document that LMDB is a full ACID DB engine, none of this should require any further explanation. > Thanks anyway. > > On Sat, May 20, 2017 at 10:46 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Muhammed Muneer wrote: > > Is the following valid. > > 1) Read transaction 1 is started > 2) Read transaction 2 is started and calls mdb_dbi_open and commits > 3) Read transaction 1 uses the handle from (2) > > > Please learn how to read. The doc says more than you quoted before, and it > already quite explicitly defines its properties: > > http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f… > <http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f…> > > The database handle will be private to the current transaction > until the transaction is successfully committed. If the transaction is > aborted the handle will be closed automatically. After a successful commit > the handle will reside in the shared environment, and may be used by other > transactions. > > In your question above, transaction 1 is not after transaction 2 therefore > it cannot use the handle that transaction 2 commits. > > The handle does not exist in the shared environment until after its > opening transaction commits. If it doesn't exist in the shared environment > when a transaction begins, then it is not visible or valid in that > particular transaction. > > Just follow the recommendation to open all handles at the beginning of the > program. > > > > On Sat, May 20, 2017 at 6:46 PM, Muhammed Muneer <elendilm(a)gmail.com > <mailto:elendilm@gmail.com> > <mailto:elendilm@gmail.com <mailto:elendilm@gmail.com>>> wrote: > > Thanks. > > On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny > <Klaus.Malorny(a)knipp.de <mailto:Klaus.Malorny@knipp.de> > <mailto:Klaus.Malorny@knipp.de <mailto:Klaus.Malorny@knipp.de>>> > wrote: > > On 5/20/17 2:02 PM, Muhammed Muneer wrote: > > So when the doc says > > * The database handle will be private to the current > transaction until > * the transaction is successfully committed. > > "the handle being private" only refers to the first > mdb_dbi_open. > Once this transaction is committed, one doesn't have to > call this > again in subsequent concurrent transactions and can use > this handle. > And then this handle won't be private at all. > > Did I get it right? > > > Yes. I do this exactly that way as part of my initial setup of my > application. Once the transaction is committed, I use the returned > handles setup from whatever thread that needs to access the > respective > database. I never call mdb_dbi_open again after the setup. > > Regards, > > Klaus > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 6

Seach Object
by Bruno de Oliveira Bastos 21 May '17

21 May '17

Someone know how to search a object DN and return a CN ? I have this object DN ( Q049c3Vwb3J0ZTNkYiBzdXBvcnRlIGRhIDNkYixPVT1Vc3XDoXJpb3MsREM9Y2hlc3BhZ ) and i need the CN of object.

2 1

Re: mdb_dbi_open and threads
by Howard Chu 20 May '17

20 May '17

Muhammed Muneer wrote: > Is the following valid. > > 1) Read transaction 1 is started > 2) Read transaction 2 is started and calls mdb_dbi_open and commits > 3) Read transaction 1 uses the handle from (2) Please learn how to read. The doc says more than you quoted before, and it already quite explicitly defines its properties: http://www.lmdb.tech/doc/group__internal.html#gac08cad5b096925642ca359a6d6f… The database handle will be private to the current transaction until the transaction is successfully committed. If the transaction is aborted the handle will be closed automatically. After a successful commit the handle will reside in the shared environment, and may be used by other transactions. In your question above, transaction 1 is not after transaction 2 therefore it cannot use the handle that transaction 2 commits. The handle does not exist in the shared environment until after its opening transaction commits. If it doesn't exist in the shared environment when a transaction begins, then it is not visible or valid in that particular transaction. Just follow the recommendation to open all handles at the beginning of the program. > > > On Sat, May 20, 2017 at 6:46 PM, Muhammed Muneer <elendilm(a)gmail.com > <mailto:elendilm@gmail.com>> wrote: > > Thanks. > > On Sat, May 20, 2017 at 6:29 PM, Klaus Malorny <Klaus.Malorny(a)knipp.de > <mailto:Klaus.Malorny@knipp.de>> wrote: > > On 5/20/17 2:02 PM, Muhammed Muneer wrote: > > So when the doc says > > * The database handle will be private to the current > transaction until > * the transaction is successfully committed. > > "the handle being private" only refers to the first mdb_dbi_open. > Once this transaction is committed, one doesn't have to call this > again in subsequent concurrent transactions and can use this handle. > And then this handle won't be private at all. > > Did I get it right? > > > Yes. I do this exactly that way as part of my initial setup of my > application. Once the transaction is committed, I use the returned > handles setup from whatever thread that needs to access the respective > database. I never call mdb_dbi_open again after the setup. > > Regards, > > Klaus > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

mdb_dbi_open and threads
by Muhammed Muneer 20 May '17

20 May '17

Hi, I have been using LMDB for over a year now. It has been a wonderful experience. A great thank you for the wonderful work that you guys have done. Till now I have used it on the main thread. And for the info, I only make use of LMDB named dbi. I was trying to make it work in threads. Reading the docs on mdb_dbi_open got me confused. The doc says " * The database handle will be private to the current transaction until * the transaction is successfully committed. " and " * This function must not be called from multiple concurrent * transactions in the same process. A transaction that uses * this function must finish (either commit or abort) before * any other transaction in the process may use this function. " I use MDB_NOTLS. Does the doc mean I can't simultaneously read the same named dbi from multiple threads because I have to wait for readers in other threads to commit before starting a read of the same named dbi?

3 5

Re: ACL to authenticate gitlab users
by Quanah Gibson-Mount 20 May '17

20 May '17

--On Sunday, May 07, 2017 5:49 PM +0200 Xaar <xaar(a)linux.pl> wrote: > Hello, > > I want to authenticate users via OpenLDAP to Gitlab. In Gitlab > configuration there is a gitlab.rb file, where I can write some special > user (let it be gitlabuser) with credentials who will be bind to ldap > server. Now my question is, what acl should I provide to this user on > OpenLDAP server to allow other users authenticate to Gitlab ? > > Now my DIT looks like this: > > dc=company,dc=com >| >| > - cn=admin > - cn=gitlabuser >| >| > - ou=Groups > - ou=Users -> here are users which I want to give access to Gitlab > > Is this entry is fair enough ? > > dn: olcDatabase={1}hdb,cn=config > changetype: modify > replace: olcAccess > olcAccess: {0} to attrs=userPassword by anonymous auth by > dn=„cn=admin,dc=company,dc=com" write by * none olcAccess: {1} to > dn.base=„" by * read > olcAccess: {2} to * by * read It would allow anyone (anonymous or authenticated) to read all your entries, minus the userPassword attribute. Depending on your security requirements, this may or may not be desirable. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapcompare vs ldapsearch
by Roger Szabo 19 May '17

19 May '17

Hi, The goal is to perform frequent periodic calls to check the health of OpenLDAP using anonymous bind. Someone at http://stackoverflow.com/questions/16077473/ldap-bind-vs-search suggested that a ldapcompare would perform better than a ldapsearch because "there is only a single response per entry (a compare result) rather than two (a search result entry and a search result done)". This explanation makes sense but it would be really great to hear the opinion of an expert on this, thank you very much :)

4 4

Re: ldapcompare vs ldapsearch
by Roger Szabo 19 May '17

19 May '17

2017-05-17 23:14 GMT+08:00 Aaron Richton <richton(a)nbcs.rutgers.edu>: > On Wed, 17 May 2017, Roger Szabo wrote: > > The goal is to perform frequent periodic calls to check the health of >> OpenLDAP using anonymous bind. >> >> Someone at http://stackoverflow.com/questions/16077473/ldap-bind- >> vs-search suggested that a ldapcompare would perform better than a >> ldapsearch because "there is only a single response per entry (a compare >> result) rather than two (a search result entry and a search result done)". >> >> This explanation makes sense but it would be really great to hear the >> opinion of an expert on this, thank you very much :) >> > > Overall, seems a bit oversimplified. I suppose the common case compare > would typically be cheaper than a search, but you could just as easily be > comparing against some dynamic membership where the matching is expensive, > potentially invoking multiple internal searches (there goes your savings). > On the other hand, if the search requires access to unindexed data, maybe > the search is more expensive. If the result set is large, maybe the search > is more expensive even if it is indexed! > > Yeah, to offer a more precise example: ldapcompare -x -H ldaps://xxxxxx:xxx "o=test" "o:test" This method simply checks whether the attribute "o" of the DIT's root element "o=test" actually contains the value "test". For this example it looks like there would theoretically be no ldapsearch on the same root element that would perform equally or even better, wouldn't it? > But you're talking about health, so the entire conversation may need to be > reframed. There's nothing in the RFC that says you have to search nor > compare. You could do something definitely in-core, i.e. ldapwhoami(1) ... > or a simple "can I speak the protocol properly?" could be connect, BIND, > UNBIND, close. > > Yeah, but would a bind (even without being configured to auto-write last login time etc.) perform better than an anonymous ldapsearch like the example above? > > As with most things, you'd have to think through your precise cases and > plan accordingly. If you're only concerned with general health of slapd(8), > a back-null or back-monitor would both be fairly cheap (back-null literally > being as cheap as it gets). But it IS possible to have backend(s) fail > while the slapd(8) frontend remains operational, so monitoring of > individual backends may be warranted too. (This is my practice -- each > backend gets an indexed monitoring search, with a search congruent with the > common use case for each backend.) > > If I'm not mistaken, with the ldapcompare example above, supposedly the backend's health is checked as well. I would be really interested though in the monitoring search you mentioned, maybe it would be possible to provide an anonymised example? > > > The counterargument to all of this, across any network service, is "if > your monitoring strains your capacity limits you're probably running too > hot anyway." Hehe, absolutely, looks like this could actually summarize the result of this discussion :D

1 0

Using of Collective attributes in 2.4.42
by Andrew Podko 19 May '17

19 May '17

Hello! I rebuilt the OpenLdap with -DLDAP_COLLECTIVE_ATTRIBUTES Added in slapd.conf include collective.schema moduleload collect overlay collect collectinfo cn=coll,dc=exadel,dc=com c-PhysicalDeliveryOfficeName,c-TelephoneNumber # also i tried with collectinfo cn=coll,dc=exadel,dc=com PhysicalDeliveryOfficeName,TelephoneNumber I created element: dn: cn=coll,dc=exadel,dc=com objectClass: subentry objectClass: extensibleObject objectClass: collectiveAttributeSubentry objectClass: top structuralObjectClass: subentry c-PhysicalDeliveryOfficeName: Test office c-TelephoneNumber: +8888888888 cn: coll subtreeSpecification: {base "ou=Test Group"} But when I query with ldapsearch, I don't see what users from ou=Test Group,dc=example,dc=com have attributes PhysicalDeliveryOfficeName, TelephoneNumber I can not understand what else needs to be done to make it work. Could you tell me what I missed? I checked it on versions 2.4.42 and 2.4.44. -- With Best Wishes Andrew Podko System Administrator Exadel apodko(a)exadel.com <mailto:apodko@exadel.com> -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

1 0

Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates
by Dameon Wagner 18 May '17

18 May '17

On Thu, May 18 2017 at 20:17:16 +0900, Alexandre Rosenberg scribbled in "Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates": > Hello, > > I test and the issue only happen if 2 CA have the same DN. > I regenerated the new CA with a different DN and it's working. > > As I am mentioned I am not sure what the proper behavior of > OpenLDAP/OpenSSL should be in case 2 CA have the same DN. > > I am not sure I misunderstanding what TLSCACertificateFile is used > for. The main use it to let OpenLDAP though which CA if should trust > when validating certificate. That is clearly what is in the doc. > > Best, > > Alex Hi Alex, Glad you got it working. I think the proper behaviour would be to not have 2 CAs with the same DN, as the first-match-wins. As the DN is used to identify the issuer of the certificate you're attempting to authenticate, it would make little sense to have a naming collision. I realise the docs say that order doesn't matter, but that assumes that all included certificates would have clearly distinguished subject names (hence "DN"). Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dr. Dameon Wagner, Systems Development and Support IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

1 0

knowing which schema(s) to use
by Prentice Bisbal 17 May '17

17 May '17

Over the past few days or weeks, I've asked a number of questions related to schemas as I move my LDAP directory to a newer OS and newer version of OpenLDAP. As has happened in the past, I have run into schema issues when importing the database (LDIF file) into the new directory with slapadd. This time I got the following errors: 1. Kerberos attributes in "new" kerberos schema start with 'krb' instead of 'krb5' 2. I got a schema structural error because user accounts have both objectclasses "account" and "krbPrincipal", which is not good. 3. We were using solaris.schema on the old system, which CentOS 6 doesn't provide, but it does provide duaconf.schema, which seemed be be similar if not identical to solaris.schema. Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa? I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach. After doing that several times, I imagine the newer applications on the newer OS versions will be looking for different objectclass or attribute names (like krb instead of krb5), and things will eventually break, anyway. So my questions are this: 1. How do the rest of you handle situations like this? 2. Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs? In an earlier e-mail, regarding my kerberos schema issues, Michael Ströder wrote > You should use the current schema file shipped with your particular Kerberos installation. That's exactly what I'm trying to do, which led to the kerberos schema issues. And in the past there have been times when the current version of the OS didn't provide the same schemas as the old version, and I was left searching the Internet to find the modern equivalent of the schema from the old system. -- Prentice

3 4

TLSCACertificateFile directive and multiple CA certificates
by Alexandre Rosenberg 17 May '17

17 May '17

Hello, Using multiple CA certificates with the TLSCACertificateFile directive is not working in my setup. The man page (1) clearly states that multiple certificates can be appended to the file. Only the first CA in the file appear to be used. I confirmed this by changing the order of the certificate in the file. I am using self-signed CA Certificate which is used for validating the provider server certificate during replication. I see this behaviour in both the latest OpenLDAP release and an older release. In both case I am using OpenSSL. I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired). I will test tomorrow if appending another CA certificate with a different CN makes a difference. I am wondering if some people are successfully using multiples certificates with the TLSCACertificateFile directive. Thanks. Best, Alex (1) http://www.openldap.org/software/man.cgi?query=slapd.conf

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical