- openldap-bugs - openldap.org

Re: (ITS#6588) Change log not up to date on www.openldap.org
by Kurt＠OpenLDAP.org 13 Jul '10

13 Jul '10

On Jul 13, 2010, at 2:39 AM, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: 2.4.23 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.14.151.50) >=20 >=20 > The page at http://www.openldap.org/software/release/changes.html only = lists > changes for the 2.4.22 release, although 2.4.23 is now released. Fixed. -- Kurt

1 0

(ITS#6588) Change log not up to date on www.openldap.org
by jonathan＠phillipoux.net 13 Jul '10

13 Jul '10

Full_Name: Jonathan Clarke Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.14.151.50) The page at http://www.openldap.org/software/release/changes.html only lists changes for the 2.4.22 release, although 2.4.23 is now released. This should be updated, I guess! In the mean time, changes can be consulted here: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/Attic/CHANGES?rev=1.5.1…

1 0

Re: (ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 12 Jul '10

12 Jul '10

Can somebody take a look at this issue. Note that the issue here is with close() being called from ldap_unbind_s with fd = (-1). Please read the first line in my original bug description email as: This is a consulation bug for clarification on close() being called from ldap_unbind_s with fd = -1.

1 0

Re: (ITS#6587) lconn_refcnt is not thread-safe
by hyc＠symas.com 10 Jul '10

10 Jul '10

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.22 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.113.184.10) > > > lconn_refcnt is read and written without any sync mechanism, which may cause > subtle multi-threading issues. You're mistaken. ld->ld_res_mutex is owned in all cases where lc->lconn_refcnt is touched. > E.g. libldap/result.c -r1.172 > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > rc = try_read1msg( ld, msgid, all, lc, result ); > lnext = lc->lconn_next; > /* Only take locks if we're really freeing */ > if ( lc->lconn_refcnt<= 1 ) { > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_req_mutex ); > #endif > ldap_free_connection( ld, lc, 0, 1 ); > > -- -- 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#6587) lconn_refcnt is not thread-safe
by test.007＠seznam.cz 09 Jul '10

09 Jul '10

Full_Name: Test Seven Version: 2.4.22 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.113.184.10) lconn_refcnt is read and written without any sync mechanism, which may cause subtle multi-threading issues. E.g. libldap/result.c -r1.172 #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif rc = try_read1msg( ld, msgid, all, lc, result ); lnext = lc->lconn_next; /* Only take locks if we're really freeing */ if ( lc->lconn_refcnt <= 1 ) { #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex ); #endif ldap_free_connection( ld, lc, 0, 1 );

1 0

(ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 01 Jul '10

01 Jul '10

Full_Name: Christian Manal Version: 2.4.21 OS: SunOS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30dd:221:85ff:fe3f:1775) I have noticed a problem regarding ExOp PASSMOD and chaining in my OpenLDAP environment. Maybe some of the other overlays are doing their part in this as well. Password changes started behaving weird at some point: When a slave runs for a few days and some user tries to change his password, the change is done in the local database only (no chaining done or referral returned), resulting in an inconsistent database between the slave and all the other servers. That way logging in to services which connect to the LDAP servers in a round-robin fashion sometimes works with the "new" password and sometimes with the old one. After I restart the slapd on the slaves, everything works again for a few days, before it goes bad again. Every other write gets chained just fine when a slave is in this condition. It's only the PASSMOD operations that are stuck. I have one master and four slaves running on Solaris 10. One of them SPARC, the others x86. Software Versions are: OpenLDAP 2.4.21 BDB 4.8.26 Cyrus SASL 2.1.23 Heimdal Kerberos 1.3.3 All the configs and the sourcecode of my self-made pwdCheckModule for ppolicy can be found here: http://www.informatik.uni-bremen.de/~moenoel/ldap/ As pointed out by Pierangelo Masarati, this may be the same issue as reported here: <http://www.openldap.org/lists/openldap-technical/201003/msg00019.html> Regards, Christian Manal

1 0

(ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 01 Jul '10

01 Jul '10

Full_Name: Asif Iqbal Desai Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.214.64.6) This is a consulation bug for clarification on close() being called from ldap_unbind_s with fd = 1. The application uses ldap client apis for user authentication. We recently upgraded to use OpenLDAP version 2.4.16 and are getting an unexpected AIO error issue when ldap user authentication is enabled. Investigating further revealed that from ldap_unbind_s ( close(-1) is getting called. However the close function of solaris libaio does a special handling when fd < 0 which causes AIO errors. The application needs solaris aio support and hence cannot link libc before libaio. Is there any specific reason for close being called with fd = -1 from ldap_unbind_s. This issue didnot exist with OpenLDAP 2.3.27. Following is the stacktrace: [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7f406a64 [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21eafc [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21e160 [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, 0xd), at 0xffffffff7d21cebc [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at 0xffffffff7d26a4bc [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, 0x100121a00), at 0xffffffff7d26a048 [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, 0x0, 0x100117728), at 0xffffffff7d26a55c ... ... Thanks in Advance, Asif Iqbal Desai

1 0

Re: ( ITS#6580)
by gianluigi.nigro＠passepartout.sm 01 Jul '10

01 Jul '10

I think that is right for new implementations, but should be guaranteed compatibility with the old interface (netscape slapi plugin). The patch serves only this purpose (and I have a set of extended operations written through that interfaces that I want to carry on openldap). -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato puo contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti.

1 0

RE: intent of pwdGraceAuthNLimit when using ppolicy overlay
by Licause, Al 30 Jun '10

30 Jun '10

I have been attempting to use the ppolicy overlay on an openldap server running on a Red Hat V5.4 platform with the following components: openldap-servers-2.3.43-3.el5 checkpassword-ldap-0.01-1.2.el5.rf mozldap-6.0.5-1.el5 openldap-2.3.43-3.el5 openldap-debuginfo-2.3.43-3.el5 nss_ldap-253-22.el5_4 openldap-clients-2.3.43-3.el5 openldap-servers-overlays-2.3.43-3.el5 I was unable to get the users password to expire by simply setting a value for pwdMaxAge without the use of the pwdReset parameter. I finally turned on all debugging in the slapd.conf file (value -1) and noticed that the value of pwdGraceAuthNLimit in the default policy, was set to 3, which allowed the ldap user access without changing the password. The disturbing thing about this was the fact that the user is not notifed that their password has expired. I would have thought that if the intent was to allow an expired password, then the user should be notified of not only the fact that their password has expired but how many more grace logins they would be allowed before either having to change the password or having the account disabled. Is this really what development had intended or are there some enhancements to this behavior in a later version ? Thanks, Al Licause HP Services Unix Network Team

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 26 Jun '10

26 Jun '10

Yet good for me ... Program source : m_connectForm->getLdapHandle()->doModifyEntries( entry( "dc=mydomain", attribute("userPassword", LDAP_MOD_ADD ) ) ); -> ... Debugger trace on breakPoint: this->m_connectForm->getLdapHandle()->getErrorNumber() = 2,, this->m_connectForm->getLdapHandle()->getErrorString() = "Protocol error", Regards, PE Le samedi 26 juin 2010 à 04:46 +0200, masarati(a)aero.polimi.it a écrit : > > Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... > > Nothing to hurry about, but I had to change the fix (not related to the > issue you reported). No strict need to test again. > > p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 26 Jun '10

26 Jun '10

> Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Nothing to hurry about, but I had to change the fix (not related to the issue you reported). No strict need to test again. p.

1 0

Re: R: ITS#6580
by masarati＠aero.polimi.it 26 Jun '10

26 Jun '10

> Hi, > the issue is that in release 2.4.21 is not possible execute an exended > operation registered in a plugin: THIS way doesnt work because slapd (in > extended.c fe_extended(), line 199) only look for built-in extended > operations and not plugin-defined extended operations (in a plugin calling > slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and SLAPI_EXT_OP_RET_VALUE). > > In fe_extended() I tried to extend the search to all extended operations > and now things start to work, but the main question concerns the choice of > backend. > > Uploaded files: > > servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch > servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch I think this approach is not correct, in many senses. First of all, you should use the native API instead of SLAPI. In fact, SLAPI is essentially unsupported. It was intended to give the possibility to somehow recycle software coded according to Netscape's API, but there's little point in developing new code based on that interface. Second, the whole purpose of implementing the slapi overlay was to avoid the pervasive presence of #ifdef LDAP_SLAPI in baseline code. So a more appropriate approach would be to have the slapi overlay register the extended operation using the native API, rather than having #ifdef LDAP_SLAPI in extended.c to check that any extop was loaded using SLAPI, as in gianluigi.nigro1-100625.patch. I can't say anything about gianluigi.nigro2-100625.patch because the file looks corrupted. p.

1 0

R: ITS#6580
by gianluigi.nigro＠passepartout.sm 25 Jun '10

25 Jun '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it]=20 Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p. -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato pu=F2 contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>R: ITS#6580</TITLE> </HEAD> <BODY>  Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> = gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be = successfully registered using OpenLDAP's native API, load_extop2().  See for = example overlays/dds.c p.    <hr color=3D'#D2D3D2' noshade> Il contenuto di questo messaggio di posta elettronica e = ogni eventuale documento a quest'ultimo allegato pu=F2 contenere = informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente = agli effettivi destinatari i quali prendono atto del carattere non = strettamente personale dei messaggi di risposta, che potranno essere = noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso = di questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. </body></html> ------_=_NextPart_001_01CB14A1.5852206C--

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Thanks, PE Le jeudi 24 juin 2010 à 19:27 +0200, masarati(a)aero.polimi.it a écrit : > The error is in the server: for this specific error, no response is > returned to the client. It is now fixed in HEAD, please test. Thanks, p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 24 Jun '10

24 Jun '10

The error is in the server: for this specific error, no response is returned to the client. It is now fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 24 Jun '10

24 Jun '10

--On Wednesday, June 23, 2010 4:03 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > > Note: this comes in the form of: > > olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top > AUXILIARY MAY > ( dgIdentity $ dgAuthz ) ) > > > in dyngroup overlay (it lets you specify the internal identity to use for > the searches/auth identity). Never mind, browsing the dynlist code, I see this is implemented in there. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 24 Jun '10

24 Jun '10

--On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org wrote: Note: this comes in the form of: olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY ( dgIdentity $ dgAuthz ) ) in dyngroup overlay (it lets you specify the internal identity to use for the searches/auth identity). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

Full_Name: Quanah Gibson-Mount Version: 2.4.22 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When dynlist expands the group membership from a URI statement, it applies the bind identity to the search to expand it. This does not conform to the dyngroup behavior as was requested. Instead, dynlist should allow expansion by doing an internal search on the specified URI value, so that the binding identity is not required to have "compare" access on the attributes making up the query. This was implemented in dyngroup for security purposes, and those reasons still apply. --Quanah

1 0

(ITS#6583) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6582) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

ITS#6580
by masarati＠aero.polimi.it 23 Jun '10

23 Jun '10

No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p.

1 0

(ITS#6580) slapi extended operation not executed
by gianluigi.nigro＠passepartout.sm 22 Jun '10

22 Jun '10

Full_Name: gianluigi nigro Version: 2.4.21 OS: Linux CentOS release 5.5 ( i686) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.186.39.1) An extended operation with slapi plugin does not work, it is never executed because slapd doesnt look for an extended operation registered in a plugin (debugging slapd i verified that the list struct extop_list -extended.c, function find_extop, line 208 - contains only built-in extended operation). 1) The initialization function look like this: char** oids = (char**) slapi_ch_malloc( 2 * sizeof( char * ) ); oids[0] = 1.3.6.1.4.1.35746.2.11.1"; oids[1] = NULL; i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_OIDLIST, oids ); if( i_ret == 0 ) i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_FN, (void*) extop1_start ); if( i_ret != 0 ) slapi_log_error( SLAPI_LOG_PLUGIN, "extop1_init", "[ERROR] registrazione %s\n", pluginDescription.spd_description ); 2) slapd.conf look like this: ... pluginlog /var/log/caronte/plugin.log plugin extendedop /opt/ldap/slapi/libextop1-plugin.so extop1_init ... After server restart: a) the log file plugin.log tell me that the plugin was successfully registered: ... 06/17/10 10:43:53 plugin_pblock_new: Registered plugin my-plugin 0.1 [mycompany] (description plugin) ... b) and the rootDSE object contains information about my extended operation, an 'ldapsearch -x -s base -b "" "(objectclass=*)" +' output like this: ... supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.35746.2.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 But, when i perform the extended operation, no plugin is executed and i get the error code 2 and the slapd log file look like this: Jun 17 09:53:03 linux-setup slapd[11969]: conn=1000 op=1 EXT oid=1.3.6.1.4.1.35746.2.11.1 Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 do_extended: unsupported operation "1.3.6.1.4.1.35746.2.11.1" Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 RESULT tag=120 err=2 text=unsupported extended operation Is it a bug or a lack of implementation?

1 0

Re: (ITS#6579) syncrepl lost in refreshAndPersist mode
by quanah＠zimbra.com 21 Jun '10

21 Jun '10

--On Monday, June 21, 2010 7:42 AM +0000 haller(a)efrei.fr wrote: > Full_Name: Nicolas Haller > Version: 2.4.22 > OS: FreeBSD 8.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:7a8:1:15::143) > > > Hi, > > I have a master LDAP server and two slaves. The slaves use syncrepl in > refreshAndPersist mode. > > it's working until I see the message "connection_read(128): no > connection!" in a slave log file. Here, I must restart the slave slapd to > force the slave to be syncronized. > > I post the syncrepl slave conf: > > syncrepl rid=1 > provider=ldap://ldap-master.blah.net > type=refreshAndPersist > interval=00:00:05:00 > retry="30 +" > searchbase="dc=blah,dc=net" > schemachecking=on > bindmethod=simple > binddn="cn=root,dc=blah,dc=net" > credentials=blahblah It sounds like you have a device between the master and the replicas that cuts the connection after some period of time. If the operating system supports it, you can set a tcp keepalive in the sycnrepl configuration block in 2.4.22. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6579) syncrepl lost in refreshAndPersist mode
by haller＠efrei.fr 21 Jun '10

21 Jun '10

Full_Name: Nicolas Haller Version: 2.4.22 OS: FreeBSD 8.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:7a8:1:15::143) Hi, I have a master LDAP server and two slaves. The slaves use syncrepl in refreshAndPersist mode. it's working until I see the message "connection_read(128): no connection!" in a slave log file. Here, I must restart the slave slapd to force the slave to be syncronized. I post the syncrepl slave conf: syncrepl rid=1 provider=ldap://ldap-master.blah.net type=refreshAndPersist interval=00:00:05:00 retry="30 +" searchbase="dc=blah,dc=net" schemachecking=on bindmethod=simple binddn="cn=root,dc=blah,dc=net" credentials=blahblah thanks, Nicolas Haller

1 0

(ITS#6578) Mailman subscribtion answer update
by daniel＠pluta.biz 19 Jun '10

19 Jun '10

Full_Name: Daniel Pluta Version: NULL OS: MS-DOS URL: http://www.openldap.org/lists/openldap-software/201005/msg00096.html Submission from: (NULL) (2001:470:9feb:ff02:b173:4a10:490:24af) As the OpenLDAP-software mailinglist has been shutdown Mailman's subscribtion auto answer should perhaps be updated to mention OpenLDAP-technical instead of OpenLDAP-software... For example openldap-devel's current answer is: "... Discussions regarding the use of the software, including use of provided SDKs, should be directed to the OpenLDAP-software mailing list. ..."

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by michael＠stroeder.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. We had this request many times before. And similar the one to avoid base64-encoding of non-ASCII chars. IMO LDIF should simply comply to RFC 2849. There are enough decent LDIF parser modules out there for one of your favourite scripting languages. OpenLDAP should not support half-baked LDIF parsing. Ciao, Michael.

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by hyc＠symas.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: * > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. This is a duplicate of ITS#4269, #6149, and probably a few others. Closing. -- -- 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#6577) OL failes to delete valid entries
by quanah＠zimbra.com 18 Jun '10

18 Jun '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When running test008 in a loop, it will occasionally fail. Investigation shows that it fails to delete an entry known to exist in the database: Here we can see a search that finds the entry: conn=1028 op=433 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(cn=james*)" conn=1028 op=433 SRCH attr=cn sn => hdb_search bdb_dn2entry("dc=example,dc=com") search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 => hdb_dn2idl("dc=example,dc=com") => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_substring_candidates (cn) => key_read bdb_idl_fetch_key: [0d554a2b] <= bdb_index_read 4 candidates <= bdb_substring_candidates: 4, first=12, last=148 bdb_search_candidates: id=4 first=12 last=148 => send_search_entry: conn 1028 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" ber_flush2: 157 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 4,ou=People,dc=example,dc=com" ber_flush2: 122 bytes to sd 34 <= send_search_entry: conn 1028 exit. A few lines further, this entry is deleted: => send_search_entry: conn 1049 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 47 bytes to sd 29 ber_flush2: 146 bytes to sd 32 <= send_search_entry: conn 1056 exit. send_ldap_result: conn=1056 op=289 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=290 tag=101 err=0 ber_flush2: 15 bytes to sd 29 conn=1056 op=289 SEARCH RESULT tag=101 err=0 nentries=1 text= bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") <=- hdb_delete: no such object cn=James A Jones 4,ou=People,dc=example,dc=com send_ldap_result: conn=1002 op=44 p=3 send_ldap_result: err=10 matched="ou=People,dc=example,dc=com" text="" send_ldap_response: msgid=45 tag=107 err=32 ber_flush2: 41 bytes to sd 14 The resulting diff show the entry still exists in the generated database: [root@build01 tests]# diff -u testrun/ldapsearch.flt testrun/ldif.flt --- testrun/ldapsearch.flt 2010-06-17 16:12:41.000000000 -0700 +++ testrun/ldif.flt 2010-06-17 16:12:41.000000000 -0700 @@ -308,25 +308,6 @@ facsimileTelephoneNumber: +1 313 555 8688 telephoneNumber: +1 313 555 7334 -dn: cn=James A Jones 4,ou=People,dc=example,dc=com -objectClass: OpenLDAPperson -cn: James A Jones 4 -cn: James Jones -cn: Jim Jones -sn: Jones -uid: jaj -postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 -seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -userPassword:: OiBhbUZx -homePostalAddress: 3882 Beverly Rd. $ Anytown, MI 48105 -homePhone: +1 313 555 4772 -description: Outstanding -title: Mad Cow Researcher, UM Alumni Association -pager: +1 313 555 3923 -mail: jaj(a)mail.alumni.example.com -facsimileTelephoneNumber: +1 313 555 4332 -telephoneNumber: +1 313 555 0895 - dn: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Jane Doe

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 17 Jun '10

17 Jun '10

--Apple-Mail-174--9407050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Daniel and Quanah. > I've tested your patch against HEAD and there seems to be a bug left = open within (or even newly introduced by?) your patch: > I've added Quanah into cc as his Call for 2.4.43RE testing seems to = depend on this ITS. > *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): = invalid pointer: 0x09d507d8 *** Heh, oops. Extra & in the add case for one of the attributes. Sorry = for the noise. See attached patch. Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-174--9407050 Content-Disposition: attachment; filename=its-6572-amendment.txt Content-Type: text/plain; x-unix-mode=0644; name="its-6572-amendment.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.19.2.14 diff -u -r1.19.2.14 refint.c --- refint.c 13 Jun 2010 17:38:37 -0000 1.19.2.14 +++ refint.c 17 Jun 2010 18:04:18 -0000 @@ -263,8 +263,8 @@ break; case REFINT_MODIFIERSNAME: if ( !BER_BVISNULL( &c->value_ndn )) { - ch_free( &dd->refint_dn.bv_val ); - ch_free( &dd->refint_ndn.bv_val ); + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); dd->refint_dn = c->value_dn; dd->refint_ndn = c->value_ndn; rc = 0; --Apple-Mail-174--9407050--

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 17 Jun '10

17 Jun '10

Hi Matthew, I've tested your patch against HEAD and there seems to be a bug left open within (or even newly introduced by?) your patch: I've added Quanah into cc as his Call for 2.4.43RE testing seems to depend on this ITS. Executive summary: ;-) ====================== *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** Technical details: ;-) ====================== If I remove the following refint configuration directive from cn=config's refint-ldif file: olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar slaptest & slapd both startup fine. If the above statement is contained in the current configuration it results in an "invalid pointer" crash during slaptest and also during slapd startup (see below)... Cheers Daniel ldif_read_file: read entry file: "slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={4}refint.ldif" => str2entry: "dn: olcOverlay={4}refint objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {4}refint olcRefintAttribute: secretary olcRefintAttribute: manager olcRefintAttribute: roleOccupant olcRefintAttribute: member olcRefintAttribute: memberOf olcRefintAttribute: owner olcRefintNothing: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc= bar olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar structuralObjectClass: olcRefintConfig entryUUID: ac810092-0b82-102f-9080-ed6f5f0ebf63 creatorsName: cn=config createTimestamp: 20100613215924Z entryCSN: 20100614121813.528580Z#000000#000#000000 modifiersName: cn=ldapmanager,cn=config modifyTimestamp: 20100614121813Z " >>> dnPrettyNormal: <olcOverlay={4}refint> <<< dnPrettyNormal: <olcOverlay={4}refint>, <olcOverlay={4}refint> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=ldapmanager,cn=config> <<< dnPretty: <cn=ldapmanager,cn=config> >>> dnNormalize: <cn=ldapmanager,cn=config> <<< dnNormalize: <cn=ldapmanager,cn=config> <= str2entry(olcOverlay={4}refint) -> 0x9cd6a04 >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6(+0x6b321)[0xb735c321] /lib/i686/cmov/libc.so.6(+0x6cb78)[0xb735db78] /lib/i686/cmov/libc.so.6(cfree+0xAborted Matthew Backes schrieb: > Here's a patch that fixes 6572. > > * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead > * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) > * Should apply cleanly to RE24 and HEAD > * Older dyn-config refints (RE22, RE23) likely have the same problem > > Matthew Backes > Symas Corporation > mbackes(a)symas.com > >

1 0

(ITS#6576) Feature Request: logging actions by a particular ip/dn to a particular file/facility
by marco.pizzoli＠gmail.com 17 Jun '10

17 Jun '10

Full_Name: Marco Pizzoli Version: * OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) This is a feature request. I would like to log some particular remote IP address and/or some particular binddn activity to a special file and/or to some specific syslog facility. This would help me in case of debug of clients configuration. Thanks Marco Pizzoli

1 0

(ITS#6575) Feature Request: ldapsearch ldif export without wrap
by marco.pizzoli＠gmail.com 17 Jun '10

17 Jun '10

Full_Name: Marco Pizzoli Version: * OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.41.84.11) This is a feature request. I would like tools like ldapsearch have an option to produce a LDIF export without wrapping to the next row when the dn is too long. Thanks Marco Pizzoli

1 0

(ITS#6574) back-meta does not rebind as user when retrying
by masarati＠aero.polimi.it 15 Jun '10

15 Jun '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.2) Submitted by: ando While retrying, back-meta destroys the failed connection to a remote target, and re-creates it. However, it loses the credentials, while restoring the bound DN. As a consequence, the connection looks bound, but it's actually anonymous. A fix is coming. The fix either preserves the credentials, when rebind-as-user is set, or turns the connection into anonymous. The latter case is of little practical use, and should only be used in conjunction with idassert, so that in case of retry, from that point on identity is asserted. p.

1 0

Re: (ITS#6571) rebind-as-user only works on first connection attempt
by masarati＠aero.polimi.it 15 Jun '10

15 Jun '10

> Full_Name: Marcel Wysocki > Version: 2.4.22 > OS: Solaris/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.79.126.162) > > > Hello, > > i have the same problem as described here: > http://www.openldap.org/lists/openldap-software/200712/msg00283.html > > here are some logs: > > @(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $ > slapd starting > > Initial connection: > ########################## > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389) > conn=1000 op=0 BIND > dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > method=128 > conn=1000 op=0 BIND > dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > mech=SIMPLE ssf=0 > conn=1000 op=0 RESULT tag=97 err=0 text= > ########################## > > First ldapsearch: > ########################## > conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=2 SRCH attr=objectclass > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= > ########################## > > backend server has been restarted, sencond ldapsearch: > ########################## > conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=3 SRCH attr=objectclass > conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= > ########################## > > backend server has been stopped, third ldapsearch, fails as it should: > ########################## > conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=4 SRCH attr=objectclass > conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text= > ########################## > > backend server has been restarted, fourth ldapsearch, rebind fails: > ########################## > conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 > filter="(mobile=491721000227)" > conn=1000 op=5 SRCH attr=objectclass > conn=1000 op=5 ldap_back_dobind_int: > DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds, > binding anonymously > conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= > ########################## > > following the configuration for back-ldap: > > database ldap > suffix "o=bazbaz" > uri ldap://10.2.163.13:389 > rootdn "cn=PEX,o=bazbaz" > rootpw secret > idle-timeout 301 > rebind-as-user yes > single-conn yes > chase-referrals no > acl-bind bindmethod=simple > binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" > credentials=supersecret I don't clearly see why you consider this behavior incorrect. As soon as the client receives a err=52 (LDAP_UNAVAILABLE), the connection is compromised. Back-ldap destroys the cached connection, since it does not work. As a consequence, the related credentials are forgotten. The client should give up, as the proxy already retried and failed (if it succeeded, the whole point would be moot, as the client wouldn't even know that the connection between the proxy and the remote server was broken). p.

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 14 Jun '10

14 Jun '10

--0050450171a831aa7e0488f30c72 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 13, 2010 at 5:20 PM, Howard Chu <hyc(a)symas.com> wrote: > Mark A. Ziesemer wrote: > >> On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> >> online(a)mark.ziesemer.com <mailto:online@mark.ziesemer.com> wrote: >> >> Full_Name: Mark A. Ziesemer >> Version: 2.4.21 >> OS: Ubuntu Linux 10.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) >> >> >> Many "connection_read(): no connection!" warnings are written to >> /var/log/debug >> and /var/log/syslog by slapd. As stated at >> >> http://www.openldap.org/lists/openldap-software/200811/msg00079.html , >> this is >> apparently not a problem with slapd, but a client that is >> disconnecting without >> first unbinding. >> >> >> This also happens when the connection manager queues up a thread to >> handle >> a "socket is readable" event on a socket that's in the process of >> closing. >> Pretty much unavoidable, when a lot of threads are active. I don't see >> this as a high enough priority to warrant fixing. >> >> >> This was not happening under a high load, but with only 1-2 connections >> active. >> >> I might not have focused on it enough in the original report, but isn't >> this >> looking like it is probably an issue with the libldap client library >> (provided >> by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, >> it >> appears that no do_unbind request is received (not sent by the client) >> when >> using ldapi:/// with a bind DN. >> >> If it can't / won't be fixed, can the logging of the "connection_read(): >> no >> connection!" event in slapd at least be demoted to a lower level so that >> it >> doesn't fill the default logging output, without having to change the >> overall >> configured logging level and potentially missing other logged events that >> do >> require attention? >> > > "Fixing" libldap, if there's even a bug there, obviously won't help with > other clients using non-OpenLDAP libraries. At any rate, there's nothing > that requires an Unbind request to be sent, so there's no bug here. > As stated by one of the other OpenLDAP engineers in the above link, the recommendation was to "fix whatever client is disconnecting without unbinding". In this case, the client is the OpenLDAP libraries. Please at least re-consider for fixing, even in a "help wanted" or "pending" status, rather than just closing. Either the client library should be fixed to send an unbind before disconnecting in all circumstances (i.e. ldapi:/// as well as ldap:///), or it should be confirmed and documented that the unbind is not necessary, in which case the server should be fixed to not output the "connection_read(): no connection!" events at the default logging level. I don't see messages filling the log. I don't see any issue here at all. > I'm not the only one seeing this. My link to the OpenLDAP mailing list above, as well as Gergely's inquiry into this ITS are 2 directly related occurrences observed by others. I was only able to reproduce this by performing a Bind with invalid > credentials. In the case with correct credentials, there were no extraneous > messages. If you're seeing a lot of these cases, then you should think about > why you're getting a lot of Binds with invalid passwords. Fix the problem, > not the symptom. This ITS will be closed. While this may be true, in any production environment, you can almost be guaranteed that there will be login attempts with invalid credentials - even just due to users mistyping their password on occasion, using CAPS lock, etc. Again, the log entry should either be suppressed at the default logging level (preferred), or at least re-worded to something more meaningful, e.g. "Received invalid login attempt; disconnecting client". However, even then, this should be made to work the same regardless of protocol used for consistency. This may not be a high priority or interesting issue to fix, but please don't simply ignore what seems to be a very reasonable request. If this issue is not addressed, the effect becomes training other users and admins to ignore the logs if they regularly contain trivial updates at the default level - which I hope we can agree is not a good practice. This appears to be an issue with the libldap client library provided > by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", > but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 > sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle > pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" > sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): > > slap_listener(ldap:///) > > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Mark A. Ziesemer www.ziesemer.com --0050450171a831aa7e0488f30c72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sun, Jun 13, 2010 at 5:20 PM, Howard Chu = <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&gt= ; wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0= pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;= "> Mark A. Ziesemer wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class=3D"im"= > On Wed, May 12, 2010 at 10:05 AM, Howard Chu <<a href=3D"mailto:hyc@syma= s.com" target=3D"_blank">hyc(a)symas.com</a> </div> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote:<div><div></div><div class=3D"h5"> =A0 =A0<a href=3D"mailto:online@mark.ziesemer.com" target=3D"_blank">onlin= e(a)mark.ziesemer.com</a> <mailto:<a href=3D"mailto:online@mark.ziesemer.c= om" target=3D"_blank">online(a)mark.ziesemer.com</a>> wrote: =A0 =A0 =A0 =A0Full_Name: Mark A. Ziesemer =A0 =A0 =A0 =A0Version: 2.4.21 =A0 =A0 =A0 =A0OS: Ubuntu Linux 10.04 =A0 =A0 =A0 =A0URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D= "_blank">ftp://ftp.openldap.org/incoming/</a> =A0 =A0 =A0 =A0Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:e= e3d) =A0 =A0 =A0 =A0Many "connection_read(): no connection!" warnings= are written to =A0 =A0 =A0 =A0/var/log/debug =A0 =A0 =A0 =A0and /var/log/syslog by slapd. =A0As stated at =A0 =A0 =A0 =A0<a href=3D"http://www.openldap.org/lists/openldap-software/= 200811/msg00079.html" target=3D"_blank">http://www.openldap.org/lists/openl= dap-software/200811/msg00079.html</a> , =A0 =A0 =A0 =A0this is =A0 =A0 =A0 =A0apparently not a problem with slapd, but a client that is<b= r> =A0 =A0 =A0 =A0disconnecting without =A0 =A0 =A0 =A0first unbinding. =A0 =A0This also happens when the connection manager queues up a thread to= handle =A0 =A0a "socket is readable" event on a socket that's in th= e process of closing. =A0 =A0Pretty much unavoidable, when a lot of threads are active. I don&#3= 9;t see =A0 =A0this as a high enough priority to warrant fixing. This was not happening under a high load, but with only 1-2 connections act= ive. I might not have focused on it enough in the original report, but isn't= this looking like it is probably an issue with the libldap client library (provi= ded by OpenLDAP), rather than the slapd daemon? =A0Looking at the provided logs= , it appears that no do_unbind request is received (not sent by the client) when= using ldapi:/// with a bind DN. If it can't / won't be fixed, can the logging of the "connecti= on_read(): no connection!" event in slapd at least be demoted to a lower level so th= at it doesn't fill the default logging output, without having to change the o= verall configured logging level and potentially missing other logged events that d= o require attention? </div></div></blockquote> "Fixing" libldap, if there's even a bug there, obviously won&= #39;t help with other clients using non-OpenLDAP libraries. At any rate, th= ere's nothing that requires an Unbind request to be sent, so there'= s no bug here. </blockquote><div> As stated by one of the other OpenLDAP engineers in t= he above link, the recommendation was to "fix whatever client is disco= nnecting without unbinding".=A0 In this case, the client is the OpenLD= AP libraries.=A0 Please at least re-consider for fixing, even in a "he= lp wanted" or "pending" status, rather than just closing.=A0= Either the client library should be fixed to send an unbind before disconn= ecting in all circumstances (i.e. ldapi:/// as well as ldap:///), or it sho= uld be confirmed and documented that the unbind is not necessary, in which = case the server should be fixed to not output the "connection_read(): = no connection!" events at the default logging level. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.= 8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I don't see messages filling the log. I don't see any issue here at= all. </blockquote><div> I'm not the only one seeing this.=A0 My = link to the OpenLDAP mailing list above, as well as Gergely's inquiry i= nto this ITS are 2 directly related occurrences observed by others. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.= 8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I was only able to reproduce this by performing a Bind with invalid credent= ials. In the case with correct credentials, there were no extraneous messag= es. If you're seeing a lot of these cases, then you should think about = why you're getting a lot of Binds with invalid passwords. Fix the probl= em, not the symptom. This ITS will be closed.</blockquote> <div class=3D"h5">=A0 While this may be true, in any production environm= ent, you can almost be guaranteed that there will be login attempts with in= valid credentials - even just due to users mistyping their password on occa= sion, using CAPS lock, etc.=A0 Again, the log entry should either be suppre= ssed at the default logging level (preferred), or at least re-worded to som= ething more meaningful, e.g. "Received invalid login attempt; disconne= cting client".=A0 However, even then, this should be made to work the = same regardless of protocol used for consistency. This may not be a high priority or interesting issue to fix, but please= don't simply ignore what seems to be a very reasonable request.=A0 If = this issue is not addressed, the effect becomes training other users and ad= mins to ignore the logs if they regularly contain trivial updates at the de= fault level - which I hope we can agree is not a good practice. <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> =A0 =A0 =A0 =A0This appears to be an issue with the libldap client library= provided =A0 =A0 =A0 =A0by OpenLDAP =A0 =A0 =A0 =A0itself (2.4.21), and not the slapd daemon. =A0 =A0 =A0 =A0Issue is reproducible even by just using "ldapsearch -= H ldapi:///", =A0 =A0 =A0 =A0but only if =A0 =A0 =A0 =A0a bind DN is specified (-D) and external authentication is = not used. =A0 =A0 =A0 =A0Running slapd with logging enabled (-d 8) shows the followi= ng 3 =A0 =A0 =A0 =A0sequences - =A0 =A0 =A0 =A0ldapsearch command followed by the slapd logs. =A0Note that= the =A0 =A0 =A0 =A0"connection_read(): no connection!" is only visib= le on the middle pair. =A0 =A0 =A0 =A0$ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b ""<= br> =A0 =A0 =A0 =A0SASL/EXTERNAL authentication started =A0 =A0 =A0 =A0SASL username: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn= =3Dexternal,cn=3Dauth =A0 =A0 =A0 =A0SASL SSF: 0 =A0 =A0 =A0 =A0No such object (32) =A0 =A0 =A0 =A0slap_listener_activate(9): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldapi:///) =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 24 contents: =A0 =A0 =A0 =A0op tag 0x60, time 1273546410 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0conn=3D1000 op=3D0 do_bind =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber: =A0 =A0 =A0 =A0ber_scanf fmt ({m) ber: =A0 =A0 =A0 =A0ber_scanf fmt (m) ber: =A0 =A0 =A0 =A0ber_scanf fmt (}}) ber: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<> =A0 =A0 =A0 =A0<<< =A0dnPrettyNormal:<>,<> =A0 =A0 =A0 =A0do_bind: dn () SASL mech EXTERNAL =A0 =A0 =A0 =A0=3D=3D>slap_sasl2dn: converting SASL name =A0 =A0 =A0 =A0gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth to a DN =A0 =A0 =A0 =A0<=3D=3Dslap_sasl2dn: Converted SASL name to<nothing&g= t; =A0 =A0 =A0 =A0SASL Authorize [conn=3D1000]: =A0proxy authorization allowe= d authzDN=3D"" =A0 =A0 =A0 =A0send_ldap_sasl: err=3D0 len=3D-1 =A0 =A0 =A0 =A0do_bind: SASL/EXTERNAL bind: =A0 =A0 =A0 =A0dn=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3De= xternal,cn=3Dauth" sasl_ssf=3D0 =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D0 =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14 =A0 =A0 =A0 =A0<=3D=3D slap_sasl_bind: rc=3D0 =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 37 contents: =A0 =A0 =A0 =A0op tag 0x63, time 1273546410 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0conn=3D1000 op=3D1 do_search =A0 =A0 =A0 =A0ber_scanf fmt ({miiiib) ber: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<> =A0 =A0 =A0 =A0<<< =A0dnPrettyNormal:<>,<> =A0 =A0 =A0 =A0ber_scanf fmt (m) ber: =A0 =A0 =A0 =A0ber_scanf fmt ({M}}) ber: =A0 =A0 =A0 =A0send_ldap_result: conn=3D1000 op=3D1 p=3D3 =A0 =A0 =A0 =A0send_ldap_response: msgid=3D2 tag=3D101 err=3D32 =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14 =A0 =A0 =A0 =A0connection_get(14): got connid=3D1000 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1000 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 5 contents: =A0 =A0 =A0 =A0op tag 0x42, time 1273546410 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0conn=3D1000 op=3D2 do_unbind =A0 =A0 =A0 =A0connection_close: conn=3D1000 sd=3D14 =A0 =A0 =A0 =A0$ ldapsearch -H ldapi:/// -D "cn=3Dadmin,dc=3Dexample,= dc=3Dcom" -b "" -W =A0 =A0 =A0 =A0Enter LDAP Password: =A0 =A0 =A0 =A0ldap_bind: Invalid credentials (49) =A0 =A0 =A0 =A0slap_listener_activate(9): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldapi:///) =A0 =A0 =A0 =A0connection_get(14): got connid=3D1001 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1001 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 44 contents: =A0 =A0 =A0 =A0op tag 0x60, time 1273546420 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0conn=3D1001 op=3D0 do_bind =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber: =A0 =A0 =A0 =A0ber_scanf fmt (m}) ber: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3D= example,dc=3Dcom> =A0 =A0 =A0 =A0<<< =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>= ,<cn=3Dadmin,dc=3Dexample,dc=3Dcom> =A0 =A0 =A0 =A0do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc= =3Dcom" method=3D128 =A0 =A0 =A0 =A0send_ldap_result: conn=3D1001 op=3D0 p=3D3 =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D49 =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14 =A0 =A0 =A0 =A0connection_get(14): got connid=3D1001 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1001 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next on fd 14 failed errno=3D0 (Success) =A0 =A0 =A0 =A0connection_close: conn=3D1001 sd=3D14 =A0 =A0 =A0 =A0connection_read(14): no connection! =A0 =A0 =A0 =A0connection_read(14): no connection! =A0 =A0 =A0 =A0$ ldapsearch -H ldap:/// -D "cn=3Dadmin,dc=3Dexample,d= c=3Dcom" -b "" -W =A0 =A0 =A0 =A0Enter LDAP Password: =A0 =A0 =A0 =A0ldap_bind: Invalid credentials (49) =A0 =A0 =A0 =A0slap_listener_activate(8): =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0slap_listener(ldap:///) =A0 =A0 =A0 =A0connection_get(14): got connid=3D1002 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1002 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next: tag 0x30 len 44 contents: =A0 =A0 =A0 =A0op tag 0x60, time 1273546425 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0conn=3D1002 op=3D0 do_bind =A0 =A0 =A0 =A0ber_scanf fmt ({imt) ber: =A0 =A0 =A0 =A0ber_scanf fmt (m}) ber: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3D= example,dc=3Dcom> =A0 =A0 =A0 =A0<<< =A0 =A0 =A0 =A0 =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>= ,<cn=3Dadmin,dc=3Dexample,dc=3Dcom> =A0 =A0 =A0 =A0do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc= =3Dcom" method=3D128 =A0 =A0 =A0 =A0send_ldap_result: conn=3D1002 op=3D0 p=3D3 =A0 =A0 =A0 =A0send_ldap_response: msgid=3D1 tag=3D97 err=3D49 =A0 =A0 =A0 =A0ber_flush2: 14 bytes to sd 14 =A0 =A0 =A0 =A0connection_get(14): got connid=3D1002 =A0 =A0 =A0 =A0connection_read(14): checking for input on id=3D1002 =A0 =A0 =A0 =A0ber_get_next =A0 =A0 =A0 =A0ber_get_next on fd 14 failed errno=3D0 (Success) =A0 =A0 =A0 =A0connection_close: conn=3D1002 sd=3D14 </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </div></div> -- Mark A. Ziesemer <a href=3D"http://www.ziesemer.co= m">www.ziesemer.com</a> --0050450171a831aa7e0488f30c72--

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 14 Jun '10

14 Jun '10

Mark A. Ziesemer wrote: > On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > online(a)mark.ziesemer.com <mailto:online@mark.ziesemer.com> wrote: > > Full_Name: Mark A. Ziesemer > Version: 2.4.21 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) > > > Many "connection_read(): no connection!" warnings are written to > /var/log/debug > and /var/log/syslog by slapd. As stated at > http://www.openldap.org/lists/openldap-software/200811/msg00079.html , > this is > apparently not a problem with slapd, but a client that is > disconnecting without > first unbinding. > > > This also happens when the connection manager queues up a thread to handle > a "socket is readable" event on a socket that's in the process of closing. > Pretty much unavoidable, when a lot of threads are active. I don't see > this as a high enough priority to warrant fixing. > > > This was not happening under a high load, but with only 1-2 connections active. > > I might not have focused on it enough in the original report, but isn't this > looking like it is probably an issue with the libldap client library (provided > by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, it > appears that no do_unbind request is received (not sent by the client) when > using ldapi:/// with a bind DN. > > If it can't / won't be fixed, can the logging of the "connection_read(): no > connection!" event in slapd at least be demoted to a lower level so that it > doesn't fill the default logging output, without having to change the overall > configured logging level and potentially missing other logged events that do > require attention? "Fixing" libldap, if there's even a bug there, obviously won't help with other clients using non-OpenLDAP libraries. At any rate, there's nothing that requires an Unbind request to be sent, so there's no bug here. I don't see messages filling the log. I don't see any issue here at all. I was only able to reproduce this by performing a Bind with invalid credentials. In the case with correct credentials, there were no extraneous messages. If you're seeing a lot of these cases, then you should think about why you're getting a lot of Binds with invalid passwords. Fix the problem, not the symptom. This ITS will be closed. > This appears to be an issue with the libldap client library provided > by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", > but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 > sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: > > dnPrettyNormal:<> > > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): > > slap_listener(ldapi:///) > > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): > > slap_listener(ldap:///) > > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: > > dnPrettyNormal:<cn=admin,dc=example,dc=com> > > <<< > dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 -- -- 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#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by kralg＠robolution.eu 13 Jun '10

13 Jun '10

Hi! Do we have any chance that this bug will be rectified recently? I believe a communication issue like this should do taken as being important. It makes the log check a huge pain, and I don't think ,,hiding'' the log is a real solution. Thank You, Gergely Kral

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 13 Jun '10

13 Jun '10

> Here's a patch that fixes 6572. Heh, okay Quanah. This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the previous patch was = developed by me for Symas and the OpenLDAP project. I am authorized by = Symas, my employer, to release this work under the following terms. Portions Copyright 2010 Symas Corporation. Redistribution and use in source and binary forms, with or without = modification, are permitted only as authorized by the OpenLDAP Public = License. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 13 Jun '10

13 Jun '10

--Apple-Mail-322--405209956 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Here's a patch that fixes 6572. * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) * Should apply cleanly to RE24 and HEAD * Older dyn-config refints (RE22, RE23) likely have the same problem Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-322--405209956 Content-Disposition: attachment; filename=refint-patch-its-6572.txt Content-Type: text/plain; name="refint-patch-its-6572.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.46 diff -u -r1.46 refint.c --- refint.c 13 Apr 2010 20:18:25 -0000 1.46 +++ refint.c 13 Jun 2010 04:02:09 -0000 @@ -76,7 +76,6 @@ } refint_q; typedef struct refint_data_s { - const char *message; /* breadcrumbs */ struct refint_attrs_s *attrs; /* list of known attrs */ BerValue dn; /* basedn in parent, */ BerValue nothing; /* the nothing value, if needed */ @@ -210,21 +209,17 @@ rc = 0; break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing.bv_len = 0; - dd->nnothing.bv_len = 0; + ch_free( dd->nothing.bv_val ); + ch_free( dd->nnothing.bv_val ); + BER_BVZERO( &dd->nothing ); + BER_BVZERO( &dd->nnothing ); rc = 0; break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn.bv_len = 0; - dd->refint_ndn.bv_len = 0; + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); + BER_BVZERO( &dd->refint_dn ); + BER_BVZERO( &dd->refint_ndn ); rc = 0; break; default: @@ -256,22 +251,26 @@ } break; case REFINT_NOTHING: - if ( dd->nothing.bv_val ) - ber_memfree ( dd->nothing.bv_val ); - if ( dd->nnothing.bv_val ) - ber_memfree ( dd->nnothing.bv_val ); - dd->nothing = c->value_dn; - dd->nnothing = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free ( dd->nothing.bv_val ); + ch_free ( dd->nnothing.bv_val ); + dd->nothing = c->value_dn; + dd->nnothing = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; case REFINT_MODIFIERSNAME: - if ( dd->refint_dn.bv_val ) - ber_memfree ( dd->refint_dn.bv_val ); - if ( dd->refint_ndn.bv_val ) - ber_memfree ( dd->refint_ndn.bv_val ); - dd->refint_dn = c->value_dn; - dd->refint_ndn = c->value_ndn; - rc = 0; + if ( !BER_BVISNULL( &c->value_ndn )) { + ch_free( &dd->refint_dn.bv_val ); + ch_free( &dd->refint_ndn.bv_val ); + dd->refint_dn = c->value_dn; + dd->refint_ndn = c->value_ndn; + rc = 0; + } else { + rc = ARG_BAD_CONF; + } break; default: abort (); @@ -299,7 +298,6 @@ slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = ch_calloc(1,sizeof(refint_data)); - id->message = "_init"; on->on_bi.bi_private = id; ldap_pvt_thread_mutex_init( &id->qmutex ); return(0); @@ -335,7 +333,6 @@ { slap_overinst *on = (slap_overinst *)be->bd_info; refint_data *id = on->on_bi.bi_private; - id->message = "_open"; if ( BER_BVISNULL( &id->dn )) { if ( BER_BVISNULL( &be->be_nsuffix[0] )) @@ -354,7 +351,6 @@ ** foreach configured attribute: ** free it; ** free our basedn; -** (do not) free id->message; ** reset on_bi.bi_private; ** free our config data; ** @@ -369,7 +365,6 @@ slap_overinst *on = (slap_overinst *) be->bd_info; refint_data *id = on->on_bi.bi_private; refint_attrs *ii, *ij; - id->message = "_close"; for(ii = id->attrs; ii; ii = ij) { ij = ii->next; @@ -870,8 +865,6 @@ BackendDB *db = NULL; refint_attrs *ip; - id->message = "_refint_response"; - /* If the main op failed or is not a Delete or ModRdn, ignore it */ if (( op->o_tag != LDAP_REQ_DELETE && op->o_tag != LDAP_REQ_MODRDN ) || rs->sr_err != LDAP_SUCCESS ) --Apple-Mail-322--405209956--

1 0

(ITS#6572)
by daniel＠pluta.biz 09 Jun '10

09 Jun '10

short add-on note: any kind of modify operation on this attribute seems to crash slapd

1 0

Re: (ITS#6573) schema errors
by Kurt＠OpenLDAP.org 07 Jun '10

07 Jun '10

On Jun 6, 2010, at 8:27 PM, peychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: last > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.185.181.157) >=20 >=20 > Hi, >=20 > 1/- It seems there is one schema definition error : the "street" = attribute is > defined twice in the "domain" objectClass (cosine.schema) ... > So, the LDAP database repeat this error ; see: ldapsearch -x -b = "cn=3Dsubschema" > -s base objectclasses As far as the old RFC 1274 version of 'domain', cosine.schema is = correct. (It's not an error to list attributes multiple times in schema = descriptions. There's a number of multiple listings found in RFC = specifications of object classes.) =20 Of course, all of cosine.schema should be replaced with a new file = derived directly from RFC 4524 with non-conflicting deprecated stuff at = the end of the file or moved to cosine-old.schema file. >=20 > 2/- the attribute "internationaliSDNNumber" is defined with a "i" for = "iSDN" but > with a "I" in the "domain" objectClass definition ... (so, a compare = with no > sensitive case option must be done to find it ...) Names are case insensitive. >=20 > (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) > Regards, > Philippe EYCHART >=20

1 0

(ITS#6573) schema errors
by peychart＠mail.pf 07 Jun '10

07 Jun '10

Full_Name: Philippe EYCHART Version: last OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.185.181.157) Hi, 1/- It seems there is one schema definition error : the "street" attribute is defined twice in the "domain" objectClass (cosine.schema) ... So, the LDAP database repeat this error ; see: ldapsearch -x -b "cn=subschema" -s base objectclasses 2/- the attribute "internationaliSDNNumber" is defined with a "i" for "iSDN" but with a "I" in the "domain" objectClass definition ... (so, a compare with no sensitive case option must be done to find it ...) (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>) Regards, Philippe EYCHART

1 0

(ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 06 Jun '10

06 Jun '10

Full_Name: Daniel Pluta Version: 2.4.21 OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:6834:fd61:37f:67da) Hi, after a silly typo (removed the "," rdn-separator character) in refint's cn=config settings while modifying "olcRefintNothing" attribute the attribute contained the following escaped value: olcRefintNothing: cn=refintcn\3Dconfig Using ldapmodify with cn=config to correct this value back into e.g. "cn=refint,cn=config" caused slapd to crash. Re-starting slapd (recovering db files...) worked fine but the value of course is still the "ugly" one above. Trying to correct (using ldapmodify) this value once more caused slapd to crash again. Cheers Daniel

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 06 Jun '10

06 Jun '10

Hi, I have run slapd in valgrind now, which produced following error: ==15353== 1 errors in context 1 of 5: ==15353== Invalid write of size 4 ==15353== at 0x80E64B5: slap_sl_free (sl_malloc.c:492) ==15353== by 0x80A0EEA: ch_free (ch_malloc.c:137) ==15353== by 0x80E3DC9: mra_free (mra.c:43) ==15353== by 0x80855B0: filter_free_x (filter.c:556) ==15353== by 0x80836CD: do_search (search.c:230) ==15353== by 0x8080588: connection_operation (connection.c:1109) ==15353== by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685) ==15353== by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so) ==15353== by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so) ==15353== Address 0x843692b1 is not stack'd, malloc'd or (recently) free'd Full valgrind log can be found at http://pastebin.de/6914 -Dieter

1 0

(ITS#6571) rebind-as-user only works on first connection attempt
by maci＠satgnu.net 04 Jun '10

04 Jun '10

Full_Name: Marcel Wysocki Version: 2.4.22 OS: Solaris/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.79.126.162) Hello, i have the same problem as described here: http://www.openldap.org/lists/openldap-software/200712/msg00283.html here are some logs: @(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $ slapd starting Initial connection: ########################## conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" method=128 conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" mech=SIMPLE ssf=0 conn=1000 op=0 RESULT tag=97 err=0 text= ########################## First ldapsearch: ########################## conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=2 SRCH attr=objectclass conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been restarted, sencond ldapsearch: ########################## conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=3 SRCH attr=objectclass conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been stopped, third ldapsearch, fails as it should: ########################## conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=4 SRCH attr=objectclass conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text= ########################## backend server has been restarted, fourth ldapsearch, rebind fails: ########################## conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=5 SRCH attr=objectclass conn=1000 op=5 ldap_back_dobind_int: DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds, binding anonymously conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= ########################## following the configuration for back-ldap: database ldap suffix "o=bazbaz" uri ldap://10.2.163.13:389 rootdn "cn=PEX,o=bazbaz" rootpw secret idle-timeout 301 rebind-as-user yes single-conn yes chase-referrals no acl-bind bindmethod=simple binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" credentials=supersecret

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

On Jun 2, 2010, at 11:11 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> However, one issue I have with this code is that highly dependent =3D >> behaviors which, aside from not be standardized, aren't even = specified =3D >> in RFCs. For instance, there is no RFC describing dnsHostName or =3D >> ldapServiceName or any specification detailing how GSS-SPNEGO is to = be =3D >> used in LDAP. Without a formal specification (e.g., RFC), I oppose =3D= >> release of this code. That is, it should stay HEAD only until such = time =3D >> that a formal specification (e.g., RFC) is available. >=20 > Kurt, I somewhat can understand your concerns. > But as a general answer to your comment above: There is already a lot = of code > in OpenLDAP for which no RFC or at least an I-D was specified but = which serves > a certain use-case. Strictly (following your statement above) speaking = one > would have to hunk out all the stuff only specified in I-Ds. An I-D would be a start. I would think there's a number of interesting = security considerations that would bubble up if someone would ever have = taken the time to submit a specification regarding use of SPNEGO in SASL = and in application protocols such as LDAP to an open standards = organization such as the IETF. > So I don't see > the strong need to be overly strict here. It's long been a stated goal of the project to promote interoperability = through open standards. This work seems more to come from a community = whose stated goal is to behave like one particular vendor. I'm not a = fan of chasing any particular vendor. > Quality of certain code is another story. But I cannot comment on = this. How can one independently verify the code acts as intended without a = specification of the intended behavior? (Saying it should act like = some particular commercial product, is not a specification.) -- Kurt >=20 > Ciao, Michael.

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by michael＠stroeder.com 02 Jun '10

02 Jun '10

Kurt(a)OpenLDAP.org wrote: > However, one issue I have with this code is that highly dependent = > behaviors which, aside from not be standardized, aren't even specified = > in RFCs. For instance, there is no RFC describing dnsHostName or = > ldapServiceName or any specification detailing how GSS-SPNEGO is to be = > used in LDAP. Without a formal specification (e.g., RFC), I oppose = > release of this code. That is, it should stay HEAD only until such time = > that a formal specification (e.g., RFC) is available. Kurt, I somewhat can understand your concerns. But as a general answer to your comment above: There is already a lot of code in OpenLDAP for which no RFC or at least an I-D was specified but which serves a certain use-case. Strictly (following your statement above) speaking one would have to hunk out all the stuff only specified in I-Ds. So I don't see the strong need to be overly strict here. Quality of certain code is another story. But I cannot comment on this. Ciao, Michael.

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

On Jun 2, 2010, at 4:28 AM, gcarter(a)likewise.com wrote: >=20 > Is it just the public ldap_bind_gssapi_s() signature that you > have an issue with? If, as you suggest, we give you a patch > that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep > the same (existing) ldap_bind_gssapi_s() internals, would that > be acceptable? There's already LDAP_AUTH_NEGOTIATE which does this. So technically, = the API is already exposed via ldap_bind_s. But I strongly oppose the introduction of abuse of the LDAP_AUTH_* = enumeration of LDAP authentication methods and ldap_bind_s(). This = enumeration and method are intended to have a one-to-one relationship = with the wire protocol. There is no "negotiate" LDAP authentication = mechanism. If this code is going to pursued (see my other comments), I think it = should be treated as a high level negotiation wrapper similar to = ldap_sasl_interactive_bind_s(). If at all possible, it should be = integrated into ldap_sasl_interactive_bind_s() (which can handle = non-interactive cases as well). However, I could (*) see it desirable = for it to be separately accessible as well, so = ldap_sasl_gss_spnego_bind_s() would be better. (* it might be easier to = see this if a proponent of this feature would implement it in = ldapwhoami(1) and slapd(8).) However, I still have objections to releasing code which implements = undocumented protocol features. Someone really needs to specify the the = SASL GSS-SPNEGO mechanism and how its used in LDAP. -- Kurt=20 >=20 >=20 >=20 >=20 >=20 >=20 > cheers, jerry > - --=20 > Director of Engineering http://www.likewise.com/ > Likewise-CIFS http://www.likewiseopen.org/ > "What man is a man who does not make the world better?" --Balian >=20 >=20 >=20 >=20 >=20 > On 6/2/10 12:10 AM, Scott Salley wrote: >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Tue 6/1/2010 6:07 PM >> To: Scott Salley >> Cc: openldap-its(a)openldap.org >> Subject: Re: (ITS#6567) Enable GSSAPI support and expose = ldap_gssadpi_bind_s >>=20 >> ssalley(a)likewise.com wrote: >>> Full_Name: Scott Salley >>> Version: HEAD >>> OS: Linux >>> URL: >> = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >>> Submission from: (NULL) (67.51.54.234) >>>=20 >>>=20 >>> Note that a similar issue/contribution was submitted in 2008 >> (Contrib/5369) and >>> appears to have been 'lost'. >>=20 >>> The patch >> = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >>> makes it possible to use the GSSAPI support in OpenLDAP by: >>>=20 >>> 1. Defining --with-gssapi in configure which >>> a. Checks for appropriate header files >>> b. Checks for the appropriate library >>> c. Defines HAVE_GSSAPI to 1 in everything is in order >>>=20 >>> 2. Exposing ldap_gssapi_bind_s in ldap.h >>=20 >> I am still disinclined to publish any of this. The standard mechanism = for >> using GSSAPI in LDAP is via SASL. I see no benefit to propagating = more >> non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach >> and it >> increases our support workload for no appreciable gain. It increases >> application developer's workload as well, if they have to test for = the >> existence of multiple flavors of ldap_XXX_bind and code for them each >> separately in their apps. >>=20 >> If you really want to have "direct" access to other authentication >> mechanisms, >> the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can >> be muxed out from a single ldap_bind API. Of course, by the time = you've >> implemented option parsing so that generic client code can be = configured >> with >> arbitrary Bind mechanisms, you would have re-implemented SASL. >>=20 >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>=20 >=20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu > 9/F8j8UQJ5C3X0sW5LytRq8=3D > =3DtkYo > -----END PGP SIGNATURE----- >=20 >=20

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

Lastly, I note that it might be good for proponent of this feature to at = least offer extensions to ldapwhoami(1) and other command line tools. = Aside from the educational value that would provide to developers in how = this feature would be used along side other libldap features (such as = ldap_sasl_interactive_bind_s), it would provide a means to test the = code. Of course, without support in OpenLDAP's slapd(8), testing would = be cumbersome for many. -- Kurt On Jun 1, 2010, at 6:08 PM, hyc(a)symas.com wrote: > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >>=20 >>=20 >> Note that a similar issue/contribution was submitted in 2008 = (Contrib/5369) and >> appears to have been 'lost'. >=20 >> The patch = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >>=20 >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >>=20 >> 2. Exposing ldap_gssapi_bind_s in ldap.h >=20 > I am still disinclined to publish any of this. The standard mechanism = for=20 > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20= > non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach and it=20 > increases our support workload for no appreciable gain. It increases=20= > application developer's workload as well, if they have to test for the=20= > existence of multiple flavors of ldap_XXX_bind and code for them each=20= > separately in their apps. >=20 > If you really want to have "direct" access to other authentication = mechanisms,=20 > the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can=20 > be muxed out from a single ldap_bind API. Of course, by the time = you've=20 > implemented option parsing so that generic client code can be = configured with=20 > arbitrary Bind mechanisms, you would have re-implemented SASL. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs