openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8588) microsecods in pwdFailureTime and .net Framework
by quanah＠symas.com 14 Feb '17

14 Feb '17

--On Tuesday, February 14, 2017 7:37 PM +0000 iovchelupoff(a)live.com wrote: > Full_Name: Ilya Ovchelupov > Version: 2.4.42 > OS: Windows Server 2008R2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (143.112.32.4) > > > Hi, > We are testing 2.4.42 in our environment and found an issue with > pwdFailureTime attribute. > > It seems to me that it started after the new enhancement in 2.4.40 > (Fixed slapo-ppolicy timestamp resolution to use microseconds (ITS#7161)) > .net DirectorySearcher class doesn't support microseconds in the new > format and we're not able to receive the attribute value. > > I'm thinking about different options how to resolve it. > > Do you know any idea how to resolve it? Hello Ilya, The ITS system is for reporting bugs in OpenLDAP. Help requests are better directed to the openldap-technical(a)openldap.org list. I would note that microsecond timestamps are per the RFC, so I would suggest filing a bug with .NET to support the RFC. 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#8588) microsecods in pwdFailureTime and .net Framework
by iovchelupoff＠live.com 14 Feb '17

14 Feb '17

Full_Name: Ilya Ovchelupov Version: 2.4.42 OS: Windows Server 2008R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (143.112.32.4) Hi, We are testing 2.4.42 in our environment and found an issue with pwdFailureTime attribute. It seems to me that it started after the new enhancement in 2.4.40 (Fixed slapo-ppolicy timestamp resolution to use microseconds (ITS#7161)) .net DirectorySearcher class doesn't support microseconds in the new format and we're not able to receive the attribute value. I'm thinking about different options how to resolve it. Do you know any idea how to resolve it? Thank you, Ilya

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 14 Feb '17

14 Feb '17

I wrote: > datacount*datasize (passed to page_spill) can overflow on 32-bit, I > thought that's what you meant. That is, I thought you meant checking data[1].mv_size <= UINT_MAX will stop the multiply from overflowon on 64-bit, but that doesn't help on 32-bit.

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 14 Feb '17

14 Feb '17

On 14/02/17 03:09, hyc(a)symas.com wrote: > Hallvard Breien Furuseth wrote: >> On 13/02/17 13:16, hyc(a)symas.com wrote: >>> We should probably check if mv_size is greater than UINT_MAX and return >>> EINVAL. (Or ERANGE.) >> >> If you mean check for overflow, that doesn't work on 32-bit hosts. > > It's not possible to pass in a datacount > UINT_MAX on 32bit so there's no > need for such a check. It's only needed on 64bit where uint is smaller than > size_t. I don't get it. You want to add this check for the sake of avoiding to change dcount,mcount from unsigned to double? Why? datacount*datasize (passed to page_spill) can overflow on 32-bit, I thought that's what you meant. But come to think of it, page_spill() itself more than doubles mv_size which can also overflow on 32-bit or with 64-bit MDB_MULTIPLE, it needs some tweaks.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by ryan＠nardis.ca 14 Feb '17

14 Feb '17

FWIW, tls_g already has the behaviour that (I think) this ticket asks for: if you set TLSCertificateFile to a file containing concatenated server and intermediate certs, it sends the chain of both. I found that useful in a setup very similar to what Andreas and Michael describe: slapd with a server certificate issued by an external/public CA, but trusting only a specific internal CA to authenticate clients. The comparison to mod_ssl is apt. Note that in recent versions httpd also supports loading the entire chain from SSLCertificateFile.

1 0

Re: (ITS#8335) MDB_MULTIPLE issues
by hyc＠symas.com 14 Feb '17

14 Feb '17

Hallvard Breien Furuseth wrote: > On 13/02/17 13:16, hyc(a)symas.com wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> (...) >>> datacount > UINT_MAX is truncated to unsigned int: >>> data[1].mv_size = 0x100000002 puts 2 items. >> >>> datacount * datasize can exceed UINT_MAX, which mdb_page_spill() >>> truncates to unsigned int. Such a massive put() will likely >>> fail anyway, but it should at least try to spill properly first. >> >> We should probably check if mv_size is greater than UINT_MAX and return >> EINVAL. (Or ERANGE.) > > If you mean check for overflow, that doesn't work on 32-bit hosts. It's not possible to pass in a datacount > UINT_MAX on 32bit so there's no need for such a check. It's only needed on 64bit where uint is smaller than size_t. -- -- 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#8335) MDB_MULTIPLE issues
by h.b.furuseth＠usit.uio.no 13 Feb '17

13 Feb '17

On 13/02/17 13:16, hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> (...) >> datacount > UINT_MAX is truncated to unsigned int: >> data[1].mv_size = 0x100000002 puts 2 items. > >> datacount * datasize can exceed UINT_MAX, which mdb_page_spill() >> truncates to unsigned int. Such a massive put() will likely >> fail anyway, but it should at least try to spill properly first. > > We should probably check if mv_size is greater than UINT_MAX and return > EINVAL. (Or ERANGE.) If you mean check for overflow, that doesn't work on 32-bit hosts. We can do a general overflow check (assuming dcount i size_t here) xdata.mv_size = data[0].mv_size * dcount; if (xdata.mv_size / dcount != data[0].mv_size) return <error>; or if you want a compile-time max safe dcount on 32-bit, that's EVEN((size_t)-1 / (MAX_PAGESIZE/MDB_MINKEYS)) So - MDB_BAD_VALSIZE or a new MDB_* code: Not EINVAL, that should be reserved for obvious error conditions. And not ERANGE, we should not add new errno.h codes.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by michael＠stroeder.com 13 Feb '17

13 Feb '17

Howard Chu wrote: > It's pretty much unheard of for an LDAP server to trust TLS client certs issued by a CA > different from the LDAP server's own CA. Since client certs are usually issued only to > allow authentication, an LDAP server will only trust its own CA to issue identities to > clients. Not sure what you consider to be "pretty much unheard of". But I vaguely remember having already described this use case: 1. Assume *all* clients have to authenticate to the LDAP server to get properly authorized to even see data (no anon access). 2. Furthermore there is a config management system available at the site which already issues client certs for its own internal use (e.g. puppet with master and CA). In this case you want to (re)use the config mgmt client certs to simple authenticate those particular LDAP clients but not want to use the config mgmt CA to be trusted also to issue server certs which ensures MITM protection for all other LDAP clients probably sending bind requests with clear-text passwords. => OpenLDAP's configuration should it possible to define different root CA chains for the local server cert and accepted client certs validation. Ciao, Michael. P.S.: You might have guessed: I'm using this in Æ-DIR to avoid having to set server passwords for thousands of servers.

1 0

Re: (ITS#8586) load cert+chain from TLSCertificateFile
by hyc＠symas.com 13 Feb '17

13 Feb '17

michael(a)stroeder.com wrote: > sca+openldap(a)andreasschulze.de wrote: >> as discussed on the technical ML it's uncommon to put chain certificates in >> TLSCACertificateFile or TLSCACertificatePath. In case of a intermediate CA like >> "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to >> /TRUST/ that intermediate for a unrelated purpose. > > We should be more precise here - especially regarding the term "user". > > IMO it is common to put the whole CA cert chain in the cert configuration of a TLS > server. This is required so that the TLS *client* only has to know the root CA cert > (trust anchor) and the TLS server sends the intermediate certs. Note that some TLS > implementations like GnuTLS require the CA cert chain to be "in order" (bottom-up). > > The real issue here is that TLSCACertificateFile and TLSCACertificatePath are also used > to specify the set of trusted CA certs to validate TLS client certs used by the TLS > client to authenticate. It's pretty much unheard of for an LDAP server to trust TLS client certs issued by a CA different from the LDAP server's own CA. Since client certs are usually issued only to allow authentication, an LDAP server will only trust its own CA to issue identities to clients. -- -- 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#8586) load cert+chain from TLSCertificateFile
by hyc＠symas.com 13 Feb '17

13 Feb '17

sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: RE24 testing call (2.4.45) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-20170211.patch > Submission from: (NULL) (2001:a60:f0b4:e502:80b6:610b:8fc2:abfe) > > as discussed on the technical ML it's uncommon to put chain certificates in > TLSCACertificateFile or TLSCACertificatePath. It is explicitly documented. http://www.openldap.org/doc/admin24/tls.html Section 16.2.1.1. You may argue that it is uncommon for people to read the docs but that doesn't constitute a software bug. > In case of a intermediate CA like > "Let's Encrypt Authority X3" it may be wrong becaus the user is forced to > /TRUST/ that intermediate for a unrelated purpose. That doesn't follow. The file used by slapd is only used to authenticate LDAP clients. There is no bug here, this ITS is invalid. -- -- 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