openldap-devel May 2011

openldap-devel@openldap.org

8 participants
8 discussions

client StartTLS issue and return codes enhancement
by Jan Vcelak 31 May '11

31 May '11

Hello everyone, I'm trying to fix one of the OpenLDAP bugs which was reported to Red Hat bugzilla [1]. But I'm not very sure about the correct behavior of client tools '-Z' option. In addition, this is closely related to one enhancement, we would like to propose. Manual page says: > -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you > use -ZZ, the command will require the operation to be successful. According to my findings, -Z option causes that StartTLS request is sent as a first operation. And then: 1.) If everything goes well, the client and server will communicate securely. 2.) If the TLS connection is established but the certificate verification is unsuccessful (e.g. hostname doesn't match), the error message is emitted and the communication continues over the TLS channel. 3.) If the server doesn't support TLS (or is configured not to use TLS), StartTLS request is rejected and communication is held insecurely. 4.) If client's TLS configuration is wrong (e.g. TLS_CACERT does not exist), the client connection will fail with 'Can't contact LDAP server (-1)'. The situation we are dealing with is the 4th option. Is this an expected behavior? The problem is, that StartTLS request is sent before processing the certificates. If the server accepts the request, it expects that all following communication is encrypted. But the client cannot process the certificates, ignores the TLS failure and sends the following next unencrypted. The server doesn't understand it, which leads to mentioned error code. The behavior is the same for OpenSSL and Mozilla NSS. And if it is incorrect, there at least two possibilities of fixing it, citing from the bug report: On 2011-05-23 18:09 Rich Megginson wrote: > On 2011-05-23 17:30 Jan Vcelak wrote: > > > 1.) Initialize client certificates before sending StartTLS request. > > I think we would have to change the StartTLS protocol to handle this case. > > > 2.) Close the TLS connection and establish a new unencrypted one when > > this situation happens. > > This is the safest way to go, but I don't know what impact this would have > on existing clients. What do you think about that? Is that expected? Are there a better ways of solving this? If this is an expected behavior, the manual pages should probably mention it. Anyway it would be great, if we could resolve the situation, where the connection to the server fails due to connection error and due to invalid TLS configuration. At the API level and maybe as a return code of the client tools. What do you think about this enhancement? Thank you. Jan [1] https://bugzilla.redhat.com/show_bug.cgi?id=693470

2 1

pcache entry ttl handling
by Ralf Haferkamp 26 May '11

26 May '11

Hi, while working on some issues in slapo-pcache (ITS#6950, 6951, 6953 and 6954). I noticed some (IMO) odd behaviour in how the experiation of cached queries is handled. It seems that pcache happily returns entries for cached queries from the cache even if the query has already expired (ttl is over). It only stops returning results for such a cached query after the periodic consistency checker has run an removed those expired queries. If this is really the desired behaviour I think we should clarify this in the man-page. If it's not we should fix the code. -- Ralf

2 1

OpenLDAP / Oracle LDAP: naming collision for ldap_set_option/ldap_get_option
by Peter Steiert 26 May '11

26 May '11

Hello alltogether, i'm not quite sure whether this list is the correct place to discuss the following topic but I hope so. I recently had an issue after compiling and running freeradius with oracle and openldap support. The error is as following: Thu May 12 10:06:42 2011 : Debug: [ldap] (re)connect to ldaps.localnet.local:636, authentication 0 Thu May 12 10:06:42 2011 : Error: [ldap] Could not set LDAP_OPT_NETWORK_TIMEOUT 1: Bad parameter to an ldap routine Thu May 12 10:06:42 2011 : Debug: [ldap] setting TLS mode to 1 Thu May 12 10:06:42 2011 : Error: [ldap] could not set LDAP_OPT_X_TLS option Bad parameter to an ldap routine: Thu May 12 10:06:42 2011 : Debug: [ldap] bind as cn=RADIUSADMIN, c=DE/PASSWORD to ldaps.localnet.local:636 Thu May 12 10:06:42 2011 : Debug: [ldap] waiting for bind result ... Thu May 12 10:06:42 2011 : Debug: [ldap] ldap_result() Thu May 12 10:06:42 2011 : Error: [ldap] cn=RADIUSADMIN, c=DE bind to ldaps.localnet.local:636 failed: Can't contact LDAP server sgslufread: Hard error on read, OS error = 32 sgslufread: Hard error on read, OS error = 32 After longer investigation i found out that the routines: ldap_set_option ldap_get_option are defined in OpenLDAP/ldap.h as well as in Oracle/ldap.h and are locatable in Oraclelib/libclntsh.so.11.1 as well as in OpenLDAP/libldap_r.so. So the ld-loader is sometimes offering the oracle code to the client and sometime the openldap code. This causes failure in the application. Now my question to the community here: Is there a global naming definiton about these routines to avoid such a conflict? Wouldn't it be better if Oracle would use it's own namespace convention as well as OpenLDAP? Kind regards Peter If the list is wrong please tell me the correct one to discuss this topic. Btw: We did a workaround by using the LD_PRELOAD path :)

2 2

replicate internal operations (was: (ITS#6915) memberof+accesslog duplicate reqStart)
by Michael Ströder 25 May '11

25 May '11

Taking this to -devel for clarification. hyc(a)symas.com wrote: > The original design for memberOf was for the internal modifications to not be > replicated. Instead, any replicas that wanted to maintain member information > was expected to run an identical memberOf overlay configuration. Ok. > In general it's incorrect to replicate internal operations. The fanout from > replicating every internal operation would be too large and the information > content of what is being replicated is essentially nil. When the servers are > configured identically they will maintain identical data by virtue of the > overlays on each node performing the same internal operations in response to a > given sequence of user operations. While I agree here I think "internal operations" has to be defined a little bit more clear: What about extended operations which may result in several write operations? Extended operations are not written to the accesslog-DB and are not replicated. Ciao, Michael.

2 1

Critical client controls stop ldap_unbind()
by Hallvard B Furuseth 13 May '11

13 May '11

ldap_unbind() & co fail without doing anything if a critical client control is set with ldap_set_option() or passed to ldap_unbind_ext_s(). This seems wrong, since ldap_unbind() has always been documented as the way to both close the connection and free the LDAP structure. Yet if some code does set a critical client control, that might be a hack to get exactly this functionality: Temporarily protect the LDAP* from being destroyed by some other code. Server controls do not prevent the Unbind. RFC 4511 says the criticality field MUST be ignored for Unbind controls. But that's in the protocol. Client controls are an LDAP API invention. I don't know which solution to pick. Opinions? Maybe we should deprecate ldap_unbind... calls now that we have ldap_destroy(). That function also sends an Unbind if it can. But that doesn't affect existing code using ldap_unbind...(). LDAPControl ctrl = {"1.2.3.4", {0,""}, 1}, *ctrls[] = {&ctrl, NULL}; LDAP *ld = ldap_open("ldap", LDAP_PORT); ldap_set_option(ld, LDAP_OPT_CLIENT_CONTROLS, ctrls); ldap_unbind_ext_s(ld, NULL, NULL); /* Connection remains open here... */ sleep(999); -- Hallvard

2 1

sizelimit and pagedResultsControl - AD vs Openldap ...
by Mads Freek Petersen 09 May '11

09 May '11

Hi all I have written a simple pure php ldap library to be able to use the pagedResultsControl - which the standard php library - to my knowledge - doesn't support. Testing it against Openldap and AD i have found that given: a dit with 1000 objects a sizelimit of 500 a pagesize of 100 Openldap returns 5 pages of 100 objects while AD returns 10 pages of 100 objects. Ie. if the sizelimit is greater than the pagesize AD ignores it. What is the correct behavior? Bwt.hHas anyone ever looked at the "cookie" AD returns - it is more than 1K bytes long! Regards Mads Freek ------------------------------------------------------ Mads Freek Petersen Special Consultant Computer Science Department Roskilde University Building 42-1, P.O. Box 260, DK-4000 Roskilde, Denmark Phone: +45 4674 3882 Fax: +45 4674 3072 E-mail: freek(a)ruc.dk There are two types of code. A large pile of crap code, and a small pile of crap code. Favour the small. - unknown IBM engineer

2 1

.git* files in .tar.gz releases?
by Hallvard B Furuseth 06 May '11

06 May '11

Should .gitattributes and .gitignore be included in releases? If not, .gitattributes needs the lines: .gitignore export-ignore .gitattributes export-ignore -- Hallvard

1 0

Static Analysis of OpenLDAP
by Lynn Gayowski 03 May '11

03 May '11

Klocwork's open source program did some source code analysis for OpenLDAP a few years back. We've analyzed the project again using our static analysis product, Klocwork Insight, and found some bugs and potential security vulnerabilities that may be of interest. The results are hosted on a secure web portal so only contributors to the project will have access to the results. They will not be published. Please email opensource at klocwork dot com for the login credentials. Issue Summary: https://opensource.klocwork.com/review/insight-review.html#reportviewer_ goto:project=openldap,report=6,scope=1 Full Details/Issue Management: http://goo.gl/9GNiu This program will be offered free to open source projects on an ongoing basis, so if you find the results of value we could analyze future versions of your project as well. Cheers, Lynn Gayowski Klocwork P +1.613. 836.8899 ext. 424 lynn.gayowski at klocwork.com

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel May 2011