openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 10 Dec '10

10 Dec '10

New patch to supplement the other patch for this ITS: ftp://ftp.openldap.org/incoming/openldap-2.4.23-allow-self-issued-certs-to-… Should only allow a cert to pass verification with BasicConstraints CA == FALSE if the cert is self issued. This is what openssl does. Forgot to include the IP statement for the previous patch. The statement applies to that patch and this one. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

jonathan(a)phillipoux.net wrote: > On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >> Submission from: (NULL) (82.67.204.30) >> >> >> Hi, >> >> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >> intercepts successful binds and records the current timestamp in an attribute >> named "bindTimestamp" in the bound-to entry. It's original use-case is to detect >> unused accounts. >> >> A configuration parameter (olcLastBindPrecision) allows to set a minimum >> precision for the timestamp (ie, don't update the timestamp unless it's older >> than<n> seconds). This avoids a performance hit from many unnecessary writes in >> case there are many binds per minute/hour/day/week/etc. >> >> Of course, the behaviour this overlay implements is not described in any RFC, or >> other. However, it closely resembles some of the functionality from the password >> policy overlay, and similar functionality already exists in other LDAP servers. There is an equivalent attribute defined in the latest ppolicy draft. Perhaps you could use that. Or just submit a patch to incorporate this feature into the current ppoloicy overlay. >> >> I post it here in the hope that it may serve others, and in case the OpenLDAP >> wishes to include it in one form or another. I would most appreciate any >> comments or feedback. -- -- 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: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 10 Dec '10

10 Dec '10

cmikk(a)qwest.net wrote: > This fix would have the effect of treating the sessionlog > as empty until it overflows, and will cause unnecessary > refresh traffic. > > Other than the patch I suggested (using the list head's > CSN value directly), I can think of two other approaches: > > 1) When adding an entry to the sessionlog, check > if sl_mincsn is empty. If it is, update sl_mincsn > to the new entry's CSN. > > 2) When initializing the sessionlog, set sl_mincsn > to the maximum contextCSN value of the underlying > database. > > #2 seems ideal from an efficiency standpoint, although it > differs from the algorithm the current code appears to be > intended to implement. #2 sounds fine, but it sounds like Rein has already got a good solution underway. -- -- 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

(ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 10 Dec '10

10 Dec '10

Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) There seems to be a memory leak in the LDAP client library when casing referrals. When the code below is run through valgrind it reports: ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) ==30395== by 0x40650A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x4065EB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x8048871: main (test.c:28) The code below is not very pretty (does not include error handling) but should free all returned buffers. I can also reproduce the above leak with the ldapsearch command-line tool. Some background: http://www.openldap.org/lists/openldap-technical/201012/msg00031.html http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00166.html -----8<-- test.c --8<----- #include <stdio.h> #include <errno.h> #define LDAP_DEPRECATED 1 #include <ldap.h> int main(int argc,char *argv[]) { char *base="dc=test,dc=tld"; char *filter="(objectClass=posixAccount)"; char *attrs[] = { "uid", NULL }; int i; LDAP *ld; LDAPMessage *msg=NULL; int msgid; char **values; /* set up connection */ ldap_initialize(&ld,"ldap://localhost";); i=3; ldap_set_option(ld,LDAP_OPT_PROTOCOL_VERSION,&i); ldap_simple_bind_s(ld,NULL,NULL); /* start search and handle results */ ldap_search_ext(ld,base,LDAP_SCOPE_SUB,filter,attrs, 0,NULL,NULL,NULL,LDAP_NO_LIMIT,&msgid); while (1) { switch (ldap_result(ld,msgid,LDAP_MSG_ONE,NULL,&msg)) { case LDAP_RES_SEARCH_ENTRY: /* we have a normal search entry, print some attribute values */ values=ldap_get_values(ld,msg,attrs[0]); for (i=0;values[i]!=NULL;i++) fprintf(stderr,"%s=%s\n",attrs[0],values[i]); ldap_value_free(values); break; case LDAP_RES_SEARCH_RESULT: /* end of results */ ldap_msgfree(msg); ldap_unbind(ld); return 0; case LDAP_RES_SEARCH_REFERENCE: break; /* just ignore search references */ default: /* we have some error condition, bail out */ return -1; } ldap_msgfree(msg); } } -----8<-- test.c --8<-----

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 14:53, Kurt Zeilenga wrote: > > On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > >> I'd like to add an IPR notice to this >> contribution: > > I note that you only provide half the notice. A complete notice would be followed by a statement of what license the contribution is provided under. Ah, the licence is included in the files, but I repeat it here for clarity: * Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. Jonathan

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > I'd like to add an IPR notice to this > contribution: I note that you only provide half the notice. A complete notice would = be followed by a statement of what license the contribution is provided = under. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > > Hi, > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. > > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. > > Of course, the behaviour this overlay implements is not described in any RFC, or > other. However, it closely resembles some of the functionality from the password > policy overlay, and similar functionality already exists in other LDAP servers. > > I post it here in the hope that it may serve others, and in case the OpenLDAP > wishes to include it in one form or another. I would most appreciate any > comments or feedback. > > Regards, > Jonathan > > PS: please note that the OIDs used are not registered, but used temporarily. I > do not currently have access to a registered OID to use. To respond to an off-list request, I'd like to add an IPR notice to this contribution: The above mentioned files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the files were developed by Jonathan Clarke <jonathan(a)phillipoux.net>. I have not assigned rights and/or interest in this work to any party. Hope this is the right wording... Jonathan

1 0

Re: (ITS#6743) LDAP 3000
by masarati＠aero.polimi.it 10 Dec '10

10 Dec '10

sylvie.longeau(a)axa-lm.com wrote: > Full_Name: Longeau > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.18.2.133) > > > Please, could you explain what is the [LDAP 3000] error code? This is not an OpenLDAP (nor an LDAP) error code, as far as I know. In any case, the ITS is intended to track software bugs and related issues. Usage questions should be addressed to openldap-technical. This ITS will be closed. p.

1 0

(ITS#6743) LDAP 3000
by sylvie.longeau＠axa-lm.com 10 Dec '10

10 Dec '10

Full_Name: Longeau Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.18.2.133) Please, could you explain what is the [LDAP 3000] error code? Thanks

1 0

(ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 09 Dec '10

09 Dec '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-centralize-and-improve-cert… Submission from: (NULL) (76.113.111.209) The changes are to make Mozilla NSS certificate verification work like OpenSSL. The former is using Fedora 14 with Mozilla NSS 3.12.8, the latter, Fedora 13 with OpenLDAP 2.4.21 and OpenSSL 1.0.0b. I tested the following scenarios: * self signed server + CA cert as generated by openssl req -x509 * server cert generated by self signed CA (/etc/pki/tls/misc/CA) I tested various combinations of certs, with and with CA certs, on both the server and the client, and verified that the F-14 system worked the same as the F-13, excepting differences in error messages. I added a new function - tlsm_verify_cert() - that could handle different types of cert verification. I replaced other calls to CERT_Verify* with this function and consolidated exception and error handling there. In order to make error handling more flexible, I use the CERT_VerifyCertificate() function which takes a logging parameter. The log contains a list of the errors found along with each cert that caused a problem (a cert may be listed in the log multiple times if a cert had more than one problem). The use of logging also allows cert verification to continue to search for all problems, rather than just returning at the first problem. This allows fine grained error handling which is needed for the following problem: OpenSSL allows CA certs with the Basic Constraints extension set with the CA flag set to FALSE. NSS does not. If tlsm_verify_cert finds this case, it can just log a warning and allow it. I also added the ability to specify an error code to ignore in cert verification, which is needed when using a self signed CA cert for the server cert. I also changed the way trust is handled. In OpenSSL, certs specified by the user (e.g. in TLS_CACERT, TLS_CACERTDIR, TLS_CERT) are explicitly trusted. So, for example, you can specify a server or client cert without specifying the CA cert issuer, and OpenSSL will allow it. NSS will allow it if the cert is specified as trusted. I changed the add_cert code to accept an istrusted flag so that you can specify if a PEM cert is trusted. The PEM NSS code stores trusted certs in a special slot, so the code had to be changed to accommodate that. Finally, I added a default error message which has the error code if an error message was not already set by the library.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs