openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#9114) pagedResultsControl not available in openldap search response
by quanah＠symas.com 07 Nov '19

07 Nov '19

--On Monday, November 4, 2019 11:52 AM +0000 prashanthmadduri(a)gmail.com wrote: > Full_Name: Prashanth Madduri > Version: 2.4.40 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.6.33.5) > > > Hi Team, > > I have huge data in OpenLDAP server and retrieve data using pagination. I > am using LDAPJS client library search functionality with paging to > retrieve the data. However as per my observation the response is not > returning pagedResultsControl in response. Hello, The ITS system is for bug reports, not help requests. Please redirect your question to the openldap-technical list for further assistance. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9113) i can not find memberOf.la file
by quanah＠symas.com 07 Nov '19

07 Nov '19

--On Tuesday, October 29, 2019 2:47 AM +0000 machao0605(a)qq.com wrote: > Full_Name: ma > Version: 2.4.44 > OS: centos 7.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (119.253.39.18) Hello, The ITS system is for bug reports, not help requests. Please redirect your question to the openldap-technical list for further assistance. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9115) It seems like the parameters about tlsCipherSuite not work
by bjmoya＠cn.ibm.com 06 Nov '19

06 Nov '19

Full_Name: nancy.mo Version: 2.4.46 OS: redhat7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.42.208.182) Hi, I set the parameter about cipher suite in client(ldap.conf) and server (slapd.conf) and restart the service, the tcp/ip log, find the cipher not changed. In ldap.conf: TLS_CIPHER_SUITE ALL:!TLSv1.3 In slapd.conf: TLSCipherSuite !TLSv1.3 openssl provide those cipher suites: [root@ ~]# openssl ciphers -v 'TLSv1.3' TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD when openldap worked as a client, it send 4 cipher suites to server in TLS1.3 client hello. Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) When openldap worked as a server, it used TLS_AES_256_GCM_SHA384 to connect in TLS server hello. And when i set one specific cipher in client, TLS_CIPHER_SUITE TLS_CHACHA20_POLY1305_SHA256 It also send same four suites in client hello. Could you help me to have a look? thanks.

1 0

(ITS#9114) pagedResultsControl not available in openldap search response
by prashanthmadduri＠gmail.com 04 Nov '19

04 Nov '19

Full_Name: Prashanth Madduri Version: 2.4.40 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (103.6.33.5) Hi Team, I have huge data in OpenLDAP server and retrieve data using pagination. I am using LDAPJS client library search functionality with paging to retrieve the data. However as per my observation the response is not returning pagedResultsControl in response. Please assist. Thanks in advance. Regards, Prashanth

1 0

(ITS#9113) i can not find memberOf.la file
by machao0605＠qq.com 28 Oct '19

28 Oct '19

Full_Name: ma Version: 2.4.44 OS: centos 7.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.253.39.18) Dear develops: I hava some trouble use openldap . I use openldap-2.4.44.tgz package. when i install this software . I can not find olcModulePath. i see /usr/local/etc/openldap/slapd.ldif it show this dir is /usr/local/libexec/openldap but i can not find it . i need a file name is memberOf.la . so could you help me to find it ? thanks ! This is me install openldap step: 1../configure --with-tls=openssl --enable-syslog --enable-module -- enable-debug CPPFLAGS="-I/usr/local/bdb_5.2.42/include" LDFLAGS="- L/usr/local/bdb_5.2.42/lib -Wl,-rpath,/usr/local/bdb_5.2.42/lib" 2.make depend 3.make 4.make install

1 0

(ITS#9112) Fixup socket error handling
by hyc＠openldap.org 28 Oct '19

28 Oct '19

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.203.24.208) Submitted by: hyc During connection setup, there are a couple of places where we perform operations on a socket and log an error if it fails, but otherwise keep going. It turns out, if the error is EBADF, eventually this gets back to the event loop, which always does a clean shutdown on any socket error. We should instead stop init'ing the socket, and not hand it over to the event loop. This situation only arose because of a long-standing bug in 3rd party code that was double-closing an fd. https://github.com/heimdal/heimdal/issues/431 . In normal situations, none of this can ever occur. Regardless, tracking this here and committing the debug code we used to track it down, in case we ever need it again in the future.

1 0

Re: (ITS#9107) new feature
by quanah＠symas.com 28 Oct '19

28 Oct '19

--On Monday, October 28, 2019 2:33 AM +0000 ydgdsnn(a)163.com wrote: > Full_Name: Nannan Song I would ask in the future that you not spam the bug system with 8 copies of the same report. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9100) Issue with domainScope controlValue implementation
by hyc＠symas.com 28 Oct '19

28 Oct '19

Philip Brusten wrote: >=20 > On 25/10/2019 18:41, Howard Chu wrote: >> philip.brusten(a)kuleuven.be wrote: >>> That fix was based on (old?) documentation of MS from >>> https://msdn.microsoft.com/en-us/library/aa366979%28v=3Dvs.85%29.aspx >>> The is no current version of this document. >> The above URL redirects me to https://docs.microsoft.com/en-us/previou= s-versions/windows/desktop/ldap/ldap-server-domain-scope-oid >> >> Our implementation conforms to the above spec. > Correct, but the URL path contains "previous-versions", hence I was loo= king for the current version, which does not exist. >> This is the correct response to a malformed message according to RFC45= 11. >=20 > Could you please quote the RFC4511 on this?=C2=A0 This is not 100% clea= r to me... This is simply the definition of the protocolError result code. RFC 4511 = Appendix A, section A.2. >>> We observed that the controlValue is than missing via Wireshark. So w= e see a >>> difference on the line for empty octet strings, but should it matter? >> Yes, in ASN.1 "empty value" and "absent value" are not the same thing.= E.g., you can >> store zero-length strings as attribute values. Those values are "prese= nt" even though >> they are empty. >=20 > IMHO Microsoft and OpenLDAP are doing the same thing on a protocol leve= l. You are both setting the controlValue to a struct {0,NULL}. >=20 > However with Microsoft, this is still translated to the network level, = whereas with OpenLDAP this controlValue is omitted. >=20 > The "value" of the "controlValue" struct is however still NULL. So it's= not clear to me why it's translated to empty, not null. (is there an som= ewhere an > assumption that translates zero-length octet string to non null values?= ) See the ASN.1 specification of controls, RFC 4511 section 4.1.11. The val= ue must be absent if there is no value information that is associated with a control of its= type. >> MS is playing fast and loose with their specifications and implementat= ion. This is >> at the very least a doc bug in their control specification, if it's no= t just a bug >> in their client libraries. You should at least open a bug report with = them so that >> it's on the record somewhere (even if they ultimately ignore it). >> >> We can alter our parser to relax this check, I guess. Along with a com= ment explaining >> that this is done for compatibility with MS's broken clients. This is = not the first >> time we've run into MS spec and implementation disagreeing with each o= ther... >=20 > We will submit the issue to MS. But in the case of this domainScope con= trol, it should not matter if the value is empty or missing, only the con= trolType is > relevant. Could Postel's law be applied in this case? As I already said, we can relax this check. But considering that Microsoft are the authors of both the spec and their= implementation of this control, and the two don't agree, and this is not the only instance = of such occurrences (the pagedResults control also comes to mind) you have to wonder - are th= ey just too stupid and incompetent to implement their own spec, or have they broken things i= ntentionally, to prevent their clients from working with non-Microsoft servers... --=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/

1 0

Re: (ITS#9100) Issue with domainScope controlValue implementation
by philip.brusten＠kuleuven.be 28 Oct '19

28 Oct '19

On 25/10/2019 18:41, Howard Chu wrote: > philip.brusten(a)kuleuven.be wrote: >> That fix was based on (old?) documentation of MS from >> https://msdn.microsoft.com/en-us/library/aa366979%28v=vs.85%29.aspx >> The is no current version of this document. > The above URL redirects me to https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ldap/lda… > > Our implementation conforms to the above spec. Correct, but the URL path contains "previous-versions", hence I was looking for the current version, which does not exist. > This is the correct response to a malformed message according to RFC4511. Could you please quote the RFC4511 on this? This is not 100% clear to me... >> The LDAP Extended Control spec of MS states [2]: >>> If the controlValue field contains data that is not in conformance with the >>> specification of the control, including the case where the controlValue field contains data and the specification of the control states that the controlValue field is omitted, then if the control is marked critical the server returns the error unavailableCriticalExtension / ERROR_INVALID_PARAMETER. If the controlValue field is incorrect but the control is not marked critical, the server ignores the control. > MS seems to be inventing their own protocol here since RFC4511 contains no such language. >> So the server should only return an error when the control is marked critical. >> Otherwise it should *ignore* the control. >> >> Is it possible to relax the validation of the LDAP control at [3]? Since there >> is no value associated with this control, it should not matter if the >> controlValue is missing or an empty octet string {0,NULL}... >> >> The ldapsearch code sets the controlValue to [4]: >>> c[i].ldctl_value.bv_val = NULL; >>> c[i].ldctl_value.bv_len = 0; >> We observed that the controlValue is than missing via Wireshark. So we see a >> difference on the line for empty octet strings, but should it matter? > Yes, in ASN.1 "empty value" and "absent value" are not the same thing. E.g., you can > store zero-length strings as attribute values. Those values are "present" even though > they are empty. IMHO Microsoft and OpenLDAP are doing the same thing on a protocol level. You are both setting the controlValue to a struct {0,NULL}. However with Microsoft, this is still translated to the network level, whereas with OpenLDAP this controlValue is omitted. The "value" of the "controlValue" struct is however still NULL. So it's not clear to me why it's translated to empty, not null. (is there an somewhere an assumption that translates zero-length octet string to non null values?) > MS is playing fast and loose with their specifications and implementation. This is > at the very least a doc bug in their control specification, if it's not just a bug > in their client libraries. You should at least open a bug report with them so that > it's on the record somewhere (even if they ultimately ignore it). > > We can alter our parser to relax this check, I guess. Along with a comment explaining > that this is done for compatibility with MS's broken clients. This is not the first > time we've run into MS spec and implementation disagreeing with each other... We will submit the issue to MS. But in the case of this domainScope control, it should not matter if the value is empty or missing, only the controlType is relevant. Could Postel's law be applied in this case? Regards, Philip

1 0

ITS#9106 published: SECURITY: new feature
by openldap-its＠OpenLDAP.org 27 Oct '19

27 Oct '19

Private ITS#9106 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9106

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