openldap-technical

openldap-technical@openldap.org

9937 discussions

Question about LibLmdb MDB_GET_BOTH_RANGE and MDB_SET_RANGE
by Tim Uckun 02 Dec '16

02 Dec '16

I am trying to figure out how these calls work. The SET_RANGE works as expected but I was expecting different behavior fro GET_BOTH_RANGE. I have the following code in my spec file. txn.put(db, "1", "1") txn.put(db, "1", "1.1") txn.put(db, "1", "1.2") txn.put(db, "1", "1.3") txn.put(db, "2", "2") txn.put(db, "2.1", "2.1") txn.put(db, "2.2", "2.2") Then I do a seek like this cur.find_ge(".") #this uses SET_RANGE cur.find_ge(".", "1.2") #this uses GET_BOTH_RANGE The result of the first call is "1", "1" but the second call results in a MDB_NOTFOUND Seems like I am missing something here. Thanks.

2 1

Building OpenLDAP with TLS support
by Tom Leach 01 Dec '16

01 Dec '16

OK, I know I'm missing something since I know people are building OpenLDAP with OpenSSL for TLS/SSL, but when I add the --with-tls flag to configure, it all goes pear shaped. I'm starting with freshly downloaded tarballs of openssl-1.1.0c and openldap-2.4.44 on CentOS 7.2.1511. I've install the packages using yum: yum -y install tcp_wrappers tcp_wrappers-devel tcp_wrappers-libs libtool-ltdl-devel I've built/installed openssl with: ./config shared --prefix=/usr/local;make;make test; make install I then successfully build openldap with: ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" --prefix=/usr/local --enable-wrappers --enable-syncprov=yes --enable-crypt=yes --enable-accesslog=yes --enable-auditlog=yes --enable-constraint=yes --enable-ppolicy=yes --enable-modules --enable-mdb --enable-debug=yes --enable-syslog --enable-slapd --enable-cleartext --enable-monitor --enable-overlays -with-threads --enable-rewrite --enable-syncprov=yes (without TLS support) make depend; make; make distclean I now add the "--with-tls=openssl" option to configure it fails with: ./configure CPPFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" --prefix=/usr/local --enable-wrappers --enable-syncprov=yes --enable-crypt=yes --enable-accesslog=yes --enable-auditlog=yes --enable-constraint=yes --enable-ppolicy=yes --enable-modules --enable-mdb --enable-debug=yes --enable-syslog --enable-slapd --enable-cleartext --enable-monitor --enable-overlays -with-threads --enable-rewrite --enable-syncprov=yes --with-tls=openssl <snip> checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no configure: error: Could not locate TLS/SSL package In looking at config.log: configure:15466: checking openssl/ssl.h usability configure:15466: cc -c -g -O2 -I/usr/local/include conftest.c >&5 configure:15466: $? = 0 configure:15466: result: yes configure:15466: checking openssl/ssl.h presence configure:15466: cc -E -I/usr/local/include conftest.c configure:15466: $? = 0 configure:15466: result: yes configure:15466: checking for openssl/ssl.h configure:15466: result: yes configure:15478: checking for SSL_library_init in -lssl configure:15503: cc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib conftest.c -lssl -lcrypto -lresolv >&5 /tmp/ccpvG28c.o: In function `main': /usr/local/src/openldap-2.4.44/conftest.c:107: undefined reference to `SSL_library_init' collect2: error: ld returned 1 exit status configure:15503: $? = 1 The source for OpenSSL 1.1.0c no longer has SSL_library_init in either the ssl or crypto libraries. It's now a macro in ssh.h which references OPENSSL_init_ssl. Since the OpenLDAP configure script doesn't pull in ssh.h in it's test, it doesn't find SSL_library_init and that test fails. As a hack, I changed the test in configure to use OPENSSL_init_ssl instead of SSL_library_init and OpenLDAP successfully configured but that blows up during make with a whole host of errors. I've also tried adding "-I/usr/local/include/openssl" to the CPPFLAGS environment but that doesn't change anything (as I expected): ./configure CPPFLAGS="-I/usr/local/include -I/usr/local/include/openssl" LDFLAGS="-L/usr/local/lib -Wl,-rpath,/usr/local/lib" --prefix=/usr/local --enable-wrappers --enable-syncprov=yes --enable-crypt=yes --enable-accesslog=yes --enable-auditlog=yes --enable-constraint=yes --enable-ppolicy=yes --enable-modules --enable-mdb --enable-debug=yes --enable-syslog --enable-slapd --enable-cleartext --enable-monitor --enable-overlays -with-threads --enable-rewrite --enable-syncprov=yes --with-tls=openssl So, is my next step to pull the dev version of 2.4.45 from git or am I just being a moron? Tom Leach

1 1

Re: restrict openldap TLS version
by Quanah Gibson-Mount 01 Dec '16

01 Dec '16

--On Thursday, December 01, 2016 6:24 PM +0000 David Ward <daward(a)Brocade.COM> wrote: Hi David, > I'm looking for a test method to restrict the level of TLS used with > slapd. I'm running ver 2.4.40 which supports TLS 1.2. I see the > undocumented command 'TLSProtocolMin' to require minimum strength. I > would like to disable certain version. I'm unclear what you mean by undocumented. It is clearly documented in the slapd.conf(5) man page (for 2.4.44), which you can freely view on the OpenLDAP.org website: TLSProtocolMin <major>[.<minor>] Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g., TLSProtocolMin 3.2 would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This directive is ignored with GnuTLS. There is not, as far as I know, any way to fine tune things beyond this (I.e., accept TLS 1.1 and TLS 1.3, but not TLS 1.2). 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>

3 3

restrict openldap TLS version
by David Ward 01 Dec '16

01 Dec '16

I'm looking for a test method to restrict the level of TLS used with slapd. I'm running ver 2.4.40 which supports TLS 1.2. I see the undocumented command 'TLSProtocolMin' to require minimum strength. I would like to disable certain version. I saw in the thread 'Re: undocumented TLSProtocolMin' that there is mention of 'SSL_OP_NO_TLSv1_2'. Has this been implemented and how do you configure this in slapd.conf? This would be what I'm looking for in a method to toggle different version of TLS. -David

1 0

Change log timestamp: rsyslog changes don't work
by mdii 30 Nov '16

30 Nov '16

Hi all, I'm trying to change the timestamp appears in my openLDAP logs. Today it's the default timestamp (Nov 22 11:55:02), but for debugging reasons I need to show the milliseconds (something like Nov 22 11:55:02:987 or any other format with milliseconds). The logs output are managed by the /etc/rsyslog.d/openldap.conf file: > #Configuration specifique openldap > local4.* @10.2.32.95:514 > local4.* -/custom/log/openldap.log > local5.* @10.2.32.95:514 > local5.* -/custom/log/openldap-oldschema.log My /etc/rsyslog.conf configuration looks like: > # Use default timestamp format > $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat For testing purposes, I change it to: > # Use default timestamp format > $ActionFileDefaultTemplate RSYSLOG_FileFormat Or even to: > # Use default timestamp format > $template myFormat,"PRI: %pri%, MSG: %msg%\n" > $ActionFileDefaultTemplate myFormat But I see no changes in the timestamp (I restart the rsyslog service at each modification) I also notice that I'm just getting the first instance log (-/custom/log/openldap.log), I'm not seeing the second one (-/custom/log/openldap-oldschema.log). Viewing this I have two questions: - why my second instance doesn't log? - why my log timestamp doesn't change when I change the configuration file? I would like to thank you in advance for all the help, Marc

2 1

Re: slapo-smbk5pwd build fixes
by Quanah Gibson-Mount 29 Nov '16

29 Nov '16

--On Saturday, November 05, 2016 7:30 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, November 05, 2016 6:30 PM +0200 Emmanuel Dreyfus > <manu(a)netbsd.org> wrote: > >> Hello >> >> slapo-smbk5pwd does not link with newer OpenSSL,because the old des_* >> API was removed. This simple patch uses the new (but available for a >> long time) DES_* API to fix that: >> http://www.openldap.org/its/index.cgi/Incoming?id=8525;selectid=8525 > > Hi Emmanuel, > > The openldap-devel list would be the appropriate place to raise and > discuss this. I will try and look into it further on Monday. This is now in RE24, scheduled for the 2.4.45 release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

replicate cn=config with exception of "ACLs"
by Stanislav Kopp 29 Nov '16

29 Nov '16

Hello, at the moment we're using master<->slave setup with slapd 2.4.31 using old slapd.conf. I want to migrate all to "cn=config" and if possible replicate cn=config DB to slaves for sake maintenance simplicity, but with exception ofr ACLs rules, because master and slaves have different ACLs. Is it possible, or ist it a good idea in general? The plus of slapd.conf was that I can deploy the same ACL file on all slaves with some automation (e.g. puppet). Thanks, Stan

1 0

Re: OID syntax and NAMEs
by Howard Chu 29 Nov '16

29 Nov '16

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Eventual I'd like to have a constraint like this: >>> >>> # check whether appropriate password policy is assigned >>> constraint_attribute structuralObjectClass,pwdPolicySubentry >>> set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC" >> >> Not possible without custom code. > > Hmm, are this/structuralObjectClass and this/pwdPolicySubentry generally > unusable in set-constraints? > > Or does it not work because of the different matching rules? Yes, because of the matching rule issue. This seems to be a deficiency in either ASN.1 or the LDAP spec, I'm not sure which. The problem is that numeric OIDs are obviously unique, but there's no guarantee that string names are. Moreover, the same name might apply to the OID of an attribute, or an objectclass, or a syntax, or some other entity, and there's no way to tell the objectIdentifierMatch rule which context is relevant. So, we can only match on numeric OIDs. -- -- 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: OID syntax and NAMEs
by Howard Chu 28 Nov '16

28 Nov '16

Michael Ströder wrote: > HI! > > I've declared an attribute type like this with LDAP syntax OID: > > ( 1.3.6.1.4.1.5427.1.389.100.4.18 > NAME 'aeApplicableSOC' > DESC 'AE-DIR: structural object classes for which policy is applicable' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 > X-ORIGIN 'AE-DIR' ) > > Which is pretty similar to this: > > ( 2.5.4.0 > NAME 'objectClass' > DESC 'RFC4512: object classes of the entity' > EQUALITY objectIdentifierMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) > > Now I wonder why I can't use the object class NAMEs instead of the OIDs as > attribute or assertion values, e.g. why I can't find the entries with filter > (aeApplicableSOC=aeUser). > > This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in > 'pwdPolicy' entries. It's the exact same issue. The objectIdentifierMatch function only works with numeric OIDs. The ppolicy overlay inserts its own matching function to make the name work. > > Eventual I'd like to have a constraint like this: > > # check whether appropriate password policy is assigned > constraint_attribute structuralObjectClass,pwdPolicySubentry > set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC" Not possible without custom code. > > 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/

2 1

Re: Ldap not reachable/tuning
by Quanah Gibson-Mount 28 Nov '16

28 Nov '16

--On Friday, November 25, 2016 7:05 PM +0100 Thomas Hummel <thomas.hummel(a)pasteur.fr> wrote: > Hello, > > I'm using a simple setup on CentOS Linux release 7.2.1511 > (Core)/openldap-servers-2.4.40-9 /cn=config/mdb : one provider with the > syncprov overlay and 2 syncrepl consumers. The DIT itself is about 10000 > dn in size (about 3000 active users). > > Everything works fine except that sometimes, some clients report > (temporary) failure to reach the consumers (NAS servers for instance). Hi Thomas, A few notes: a) The CentOS7 build is hacked to support a broken TLS implementation. b) The version (2.4.40) is quite old, and has numerous known problems (it was a particularly broken release). I would also note the CentOS7 build has on occassion had its own problems introduced by patches from RedHat that do not exist in stock OpenLDAP builds. See <http://www.openldap.org/software/release/changes.html> for a list of changes since 2.4.40 was released. c) Nothing you presented indicates any issue on the server side. It could, for example, be an issue with your clients, a firewall, packet shaper, etc. d) You should fully disable rate limiting for rsyslogd. Then find out what the server side reports during the periods of time when you see issues with the client connections. You may wish to examine the LTB builds (<http://ltb-project.org/wiki/download#openldap>) if you are unable to build OpenLDAP yourself, or if you require support for your OpenLDAP installation, Symas (the company I work for) has support options. Hope this helps! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical