openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#6435) Hidden schema elements
by rein＠OpenLDAP.org 21 Dec '09

21 Dec '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Some of the operational attributes defined in the slapd source are hidden from the clients unless slapd is compiled with LDAP_DEVEL enabled. Still, some of these elements are used in the database (as in the authz* and monitor related attributes). This causes my schema-aware application to complain when it sees (or worse tries to modify) these attributes. A patch that adds a new optional define that can be used to disable the schema hiding without enabling LDAP_DEVEL is coming. A better fix would be to not hide those schema elements that is actually being used.. Rein

1 0

Re : ITS#6434
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Hello,=0A=0AI=A0make a test=A0with servers/slapd/overlays/rwm.c=A0version= =A0=A01.124. It works fine. Thank you very much for your help.=0A=0ABest re= gards,=0A=A0Raphael KISTER=0A=0A=0A=0A----- Message d'origine ----=0ADe : P= ierangelo Masarati <masarati(a)aero.polimi.it>=0A=C0 : KISTER RAPHAEL <kraph@= yahoo.com>; openldap-its(a)openldap.org=0AEnvoy=E9 le : Lun 21 D=E9cembre 200= 9, 13 h 08 min 31 s=0AObjet=A0: ITS#6434=0A=0AThe problem has been fixed in= HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report= .=A0 Thanks, p.=0A=0A=0A=0A

1 0

ITS#6434
by masarati＠aero.polimi.it 21 Dec '09

21 Dec '09

The problem has been fixed in HEAD (servers/slapd/overlays/rwm.c 1.122 -> 1.223); please test and report. Thanks, p.

1 0

(ITS#6434) Problem with rewrite overlay
by kraph＠yahoo.com 21 Dec '09

21 Dec '09

Full_Name: Raphaël KISTER Version: 2.4.20 OS: Linux CentOS 5.4 URL: http://www.raphael-kister.fr/openldap_its Submission from: (NULL) (88.184.63.204) I would like to use OpenLDAP as an Active Directory Proxy. I configure ldap backend and i rewrite some attributes and objectclass. When i test my configuration file, i get this error : config error processing olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config: <olcRwmMap> handler exited with 1 slaptest: bad configuration directory! This is an extract of my config file : database ldap suffix dc=CNC,dc=LOCAL rootdn "cn=admin,cn=config" uri ldap://192.168.44.88:389 lastmod off acl-authcDN cn=admin,cn=config acl-passwd secret idassert-bind bindmethod="simple" binddn="CN=srv_ldap,OU=Services-account,OU=Administration,dc=CNC,dc=LOCAL" credentials="Azerty00" mode="legacy" overlay rwm #rwm-suffixmassage dc=CNC,dc=LOCAL rwm-map objectclass inetOrgPerson user rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute displayName displayName rwm-map attribute givenName givenName rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute userPassword userPassword rwm-map attribute *

1 0

(ITS#6433) patch for the sha2 module: hash methods for passwords generation
by cdelfosse＠mandriva.com 21 Dec '09

21 Dec '09

Full_Name: Cédric Delfosse Version: HEAD OS: Mandriva Linux URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch Submission from: (NULL) (62.212.120.90) Hello, this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes (provided by the sha2 module) with LDAP Password Modify Extended Operations. This patch contains the required hash methods. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mandriva. Mandriva has not assigned rights and/or interest in this work to any party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release this work under the following terms. Mandriva hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Regards, Cédric

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 19 Dec '09

19 Dec '09

rmeggins(a)redhat.com wrote: > You are right, Howard. It works as you described. I'm not sure what > happened in my testing. Mea culpa. > > This is a new patch with the SetURL changes backed out. > > ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200… OK. Another question - you're only using NSS_InitContext() for client initialization. Any particular reason not to always use it? Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I think these two lines should be enclosed in "if (c->tc_initctx) {}" -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

You are right, Howard. It works as you described. I'm not sure what happened in my testing. Mea culpa. This is a new patch with the SetURL changes backed out. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by hyc＠symas.com 18 Dec '09

18 Dec '09

rmeggins(a)redhat.com wrote: >>> I also had to call >>> SSL_SetURL in order to put the correct hostname in the SSL socket for cert >>> validation. >> >> I explicitly withheld the hostname to force our own cert validation function >> to be used. The NSS hostname validator's behavior is inconsistent with the >> LDAP spec. >> > That's the tlsm_session_chkhost() function? The problem is that the > chkhost function is called too late - NSS attempts to perform the > verification during the handshake process - by the time > ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's > too late - NSS has failed - ldap_int_tls_connect() has returned an error. That should not happen, since tlsm_bad_cert_handler() causes the bad hostname result to be returned as Success. That gives us the chance to check it on our own. It worked in my tests before... -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

This is a new patch, which #defines HAVE_NSS_INITCONTEXT based on the NSS version. ftp://ftp.openldap.org/incoming/openldap-2.4.20-tls_m_c-InitContext-PEM-200…

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 18 Dec '09

18 Dec '09

> > Thanks for the patch. > > Just blindly #defining HAVE_NSS_INITCONTEXT is no good. Isn't there an NSS > version symbol we can check in the preprocessor, to make sure it's 3.12.5 or > newer? Otherwise we'll need an autoconf test for the existence of the > NSS_InitCOntext() function. > Ok. I'll change it to check for NSS version >= 3.12.5 > > This allows apps and libraries to initialize NSS from different contexts. > I've > > also cleaned up some of the code around PEM file support. I also had to > call > > SSL_SetURL in order to put the correct hostname in the SSL socket for cert > > validation. > > I explicitly withheld the hostname to force our own cert validation function > to be used. The NSS hostname validator's behavior is inconsistent with the > LDAP spec. > That's the tlsm_session_chkhost() function? The problem is that the chkhost function is called too late - NSS attempts to perform the verification during the handshake process - by the time ldap_pvt_tls_check_hostname() is called in ldap_int_tls_start(), it's too late - NSS has failed - ldap_int_tls_connect() has returned an error.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs