openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

(ITS#7981) Feature request: Crypt scheme in pwdPolicy
by michael＠stroeder.com 14 Nov '14

14 Nov '14

Full_Name: Version: OS: URL: Submission from: (NULL) (79.219.125.95) It would be handy if the password storage/crypt scheme could be specified in a pwdPolicy entry. LDAP Modify Password Ext.Op. should use this information instead of global configuration olcPasswordHash. Rationale: There might be in one database several different account types needed with pwdPolicySubentry pointing to separate pwdPolicy entries. Example: - Normal account with strongly hashed password for direct LDAP simple bind - Clear-text userPassword for WLAN authenticated through RADIUS server Ideally this should be standardized when the ldapext WG is revived. ;-)

1 0

(ITS#7980) LMDB added support for user context in compare function
by rouzier＠gmail.com 13 Nov '14

13 Nov '14

Full_Name: James Rouzier Version: 2.4 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.222.129.11) https://github.com/rouzier/openldap/commit/33f1dc8be4a8503e78930f130ff9c8e5… I added support for user supplied context for lmdb in the compare functions. This make it much easier to integrate with scripting languages. -- The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by James Rouzier <rouzier(a)gmail.com>. I have not assigned rights and/or interest in this work to any party. I, James Rouzier, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --

1 0

Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com 13 Nov '14

13 Nov '14

Mark Reynolds wrote: > > On 11/12/2014 04:56 PM, Howard Chu wrote: >> mreynolds(a)redhat.com wrote: >>> Full_Name: Mark Reynolds >>> Version: 2.4.40 >>> OS: Fedora 20 >>> URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch >>> Submission from: (NULL) (174.60.44.17) >>> >>> >>> Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. >>> mozNSS >>> defaults to SSLv3/TLS1.0 which is no longer considered secure. If a >>> client only >>> supports TLSv1.1 and up, the openldap ldapsearch will fail to connect >>> over SSL. >>> >>> ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base >>> objectclass=* >>> >>> or >>> >>> LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H >>> "ldaps://localhost.localdomain:636" -b "" >>> -s base objectclass=* >>> >>> The fix is to grab the supported version range from NSS, adjust the >>> minimum >>> range if TLS_PROTOCOL_MIN is set, and then set the NSS default range >>> with the >>> min and max versions. >> >> Thanks for the patch. I'm concerned because I see you adding MozNSS >> constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap >> values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may >> well be identical values. But please make sure, and add a comment to >> that effect, so that it's clear that setting lt_protocol_min is >> actually doing what's expected. > Thanks for the feedback Howard. Yes, the SSL versions are the same in > NSS & openldap. I have uploaded a new patch with the requested > comments: mark-reynolds-141113.patch Thanks, committed to master. > On a side note, we are pushing the NSS team to update the NSS API to > provide the SSL version to version string mapping. So we will be able > to remove the hardcoded map(pvers) in openldap once this get addressed. Great. Nice to see they're finally addressing their usability issues. -- -- 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#7979) mozNSS does not process TLS_PROTOCOL_MIN
by mreynolds＠redhat.com 13 Nov '14

13 Nov '14

On 11/12/2014 04:56 PM, Howard Chu wrote: > mreynolds(a)redhat.com wrote: >> Full_Name: Mark Reynolds >> Version: 2.4.40 >> OS: Fedora 20 >> URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch >> Submission from: (NULL) (174.60.44.17) >> >> >> Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. >> mozNSS >> defaults to SSLv3/TLS1.0 which is no longer considered secure. If a >> client only >> supports TLSv1.1 and up, the openldap ldapsearch will fail to connect >> over SSL. >> >> ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base >> objectclass=* >> >> or >> >> LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H >> "ldaps://localhost.localdomain:636" -b "" >> -s base objectclass=* >> >> The fix is to grab the supported version range from NSS, adjust the >> minimum >> range if TLS_PROTOCOL_MIN is set, and then set the NSS default range >> with the >> min and max versions. > > Thanks for the patch. I'm concerned because I see you adding MozNSS > constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap > values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may > well be identical values. But please make sure, and add a comment to > that effect, so that it's clear that setting lt_protocol_min is > actually doing what's expected. Thanks for the feedback Howard. Yes, the SSL versions are the same in NSS & openldap. I have uploaded a new patch with the requested comments: mark-reynolds-141113.patch On a side note, we are pushing the NSS team to update the NSS API to provide the SSL version to version string mapping. So we will be able to remove the hardcoded map(pvers) in openldap once this get addressed. Regards, Mark >> >> Also updated the NSS version string map table to support up to TLSv1.3 >

1 0

Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com 12 Nov '14

12 Nov '14

mreynolds(a)redhat.com wrote: > Full_Name: Mark Reynolds > Version: 2.4.40 > OS: Fedora 20 > URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch > Submission from: (NULL) (174.60.44.17) > > > Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. mozNSS > defaults to SSLv3/TLS1.0 which is no longer considered secure. If a client only > supports TLSv1.1 and up, the openldap ldapsearch will fail to connect over SSL. > > ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* > > or > > LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H "ldaps://localhost.localdomain:636" -b "" > -s base objectclass=* > > The fix is to grab the supported version range from NSS, adjust the minimum > range if TLS_PROTOCOL_MIN is set, and then set the NSS default range with the > min and max versions. Thanks for the patch. I'm concerned because I see you adding MozNSS constants (SSL_LIBRARY_VERSION_TLS_1_2) in code that expects libldap values (LDAP_OPT_X_TLS_PROTOCOL_TLS1_2). I haven't checked; they may well be identical values. But please make sure, and add a comment to that effect, so that it's clear that setting lt_protocol_min is actually doing what's expected. > > Also updated the NSS version string map table to support up to TLSv1.3 -- -- 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#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hyc＠symas.com 12 Nov '14

12 Nov '14

Looking over this patch https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_nettle.patch You've added a new contributor: @@ -97,3 +99,5 @@ top-level directory of the distribution or, alternatively, at # ACKNOWLEDGEMENT This work was initially developed by HAMANO Tsukasa <hamano(a)osstech.co.jp> +Contributor: +Luca Bruno(lucab) We cannot accept 3rd party submissions; Luca will have to submit any relevant patches directly to us, along with a corresponding IPR statement as outlined in our Contributors guidelines. -- -- 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#7979) mozNSS does not process TLS_PROTOCOL_MIN
by mreynolds＠redhat.com 12 Nov '14

12 Nov '14

Full_Name: Mark Reynolds Version: 2.4.40 OS: Fedora 20 URL: ftp://ftp.openldap.org/incoming/mark-reynolds-141112.patch Submission from: (NULL) (174.60.44.17) Currently there is no check for TLS_PROTOCOL_MIN in the mozNSS code. mozNSS defaults to SSLv3/TLS1.0 which is no longer considered secure. If a client only supports TLSv1.1 and up, the openldap ldapsearch will fail to connect over SSL. ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* or LDAPTLS_PROTOCOL_MIN=3.2 ldapsearch -H "ldaps://localhost.localdomain:636" -b "" -s base objectclass=* The fix is to grab the supported version range from NSS, adjust the minimum range if TLS_PROTOCOL_MIN is set, and then set the NSS default range with the min and max versions. Also updated the NSS version string map table to support up to TLSv1.3

1 0

Re: (ITS#7832) Proposing ppolicy extended module for OpenLDAP
by dcoutadeur＠linagora.com 12 Nov '14

12 Nov '14

Hi, The ppm module is still alive, and is evolving. Last version is 1.2, and source code is now available on Github : https://github.com/davidcoutadeur/ppm There are also plans to package it. If anybody is interrested, I am always glad to hear about comments, ideas, improvements,... Sincerely, David

1 0

Re: (ITS#7977) Supported PBKDF2-SHA256 and PBKDF2-SHA512
by hamano＠osstech.co.jp 07 Nov '14

07 Nov '14

Hi, Please merge the additional patch: https://www.osstech.co.jp/download/hamano/openldap-pbkdf2_nettle.patch This patch include nettle support and fix a issue. https://github.com/hamano/openldap-pbkdf2/pull/4 https://github.com/hamano/openldap-pbkdf2/pull/3 Thank you. At Wed, 05 Nov 2014 11:57:33 +0000, Howard Chu wrote: > > Tsukasa HAMANO wrote: > > Hi, Howard > > > > At Wed, 05 Nov 2014 09:32:43 +0000, > > Howard Chu wrote: > >> > >> Any particular reason you've decreased the iterations from 60000 to 10000? > >> > > > > It was too slow when stretching 60000 on powerless server. > > My tiny VM needed over 1sec if iterate 60000 by PBKDF2-SHA512. > > RFC recommends more than 1000 iterations, it would be safe enough 10000 iterations. > > FYI: http://security.stackexchange.com/questions/3959/recommended-of-iterations-… > > OK. I've committed it without any changes, thanks for the patch. > > > It is desirable to be able to change the operator, but slapasswd does > > not read slapd.conf so I was stuck. > > I'm planning to change slappasswd that accept iteration count in the future. > > Thank you. > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 2285 2111 6D34 3816 3C2E A5B9 16BE D101 6069 BE55

1 0

Re: (ITS#7978) OpenLDAP 2.4 fails to build with LibreSSL
by hyc＠symas.com 05 Nov '14

05 Nov '14

Spil Oss wrote: > Hi Howard, > > Thanks for the pointer. --enable-lmpasswd was indeed enabled in the > FreeBSD port. Notifying maintainer of port to switch it off and > provided a patch for the port. > Hope the patch I created for OpenLDAP is usable after all! Deprecated > code in a function that should not be used, would it not be better to > remove it completely? (or is that violating the RFCs?) Very likely we should remove it. Will queue that up for 2.5. 2.4 is end-of-life and feature-frozen so nothing will be added or removed from it. > Kind regards, > > Bernard. > > On Wed, Nov 5, 2014 at 5:48 PM, Howard Chu <hyc(a)symas.com> wrote: >> spil.oss(a)gmail.com wrote: >>> >>> Full_Name: Bernard Spil >>> Version: 2.4.40 >>> OS: FreeBSD 10.1-RC2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (185.9.255.20) >>> >>> >>> When compiling OpenLDAP against the LibreSSL OpenSSL fork, compilation >>> fails >>> because deprecated types and functions are used. These types and functions >>> have >>> been marked deprecated by OpenSSL since 2002 and moved from des.h to >>> des_old.h. >>> LibreSSL removed these deprecated types and functions in April 2014 see >>> >>> https://github.com/libressl-portable/openbsd/commit/e0d211052a6946b9f8af112… >>> >>>> From the make output: >> >> >> It appears you're compiling with the old LANMAN hash support. Nobody should >> be using LANMAN any more, it's trivially insecure. I'm inclined to ignore >> this ITS. -- -- 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

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