openldap-bugs October 2019

openldap-bugs@openldap.org

20 participants
54 discussions

(ITS#9111) new feature:using the encrypted text to save password for read only user
by ydgdsnn＠163.com 27 Oct '19

27 Oct '19

Full_Name: Nannan Song Version: 2.4.44 OS: SUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.226.97.96) When LDAP is used to manage user and user group information, openldap only supports the configuration of the plain text password of the read-only user in the '/etc/ldap.conf/'. The password of the read-only user only supports plain text storage. so there is a security issue that the authentication credential file is readable to all users. Now we hope ldap can support the feature that using the encrypted text to save password for read only user.

1 0

(ITS#9110) new feature
by ydgdsnn＠163.com 27 Oct '19

27 Oct '19

Full_Name: Nannan Song Version: 2.4.44 OS: SUSE URL: Submission from: (NULL) (221.226.97.96) When LDAP is used to manage user and user group information, openldap only supports the configuration of the plain text password of the read-only user in the '/etc/ldap.conf/'. The password of the read-only user only supports plain text storage. so there is a security issue that the authentication credential file is readable to all users. Now we hope ldap can support the feature that using the encrypted text to save password for read only user.

1 0

(ITS#9109) new feature
by ydgdsnn＠163.com 27 Oct '19

27 Oct '19

1 0

(ITS#9108) new feature
by ydgdsnn＠163.com 27 Oct '19

27 Oct '19

1 0

(ITS#9107) new feature
by ydgdsnn＠163.com 27 Oct '19

27 Oct '19

1 0

(ITS#9102) Update sasl-secprops ssf wording
by quanah＠openldap.org 25 Oct '19

25 Oct '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.154.120) The slapd.conf(5)/slapd-config(5) man pages contain this wording for the sasl-secprops keyword: 0 (zero) implies no protection, 1 implies integrity protection only, 56 allows DES or other weak ciphers, 112 allows triple DES and other strong ciphers, 128 allows RC4, Blowfish and other modern strong ciphers. The default is 0. I think it's been quite a while since RC4 was considered a "modern strong cipher".

1 0

Re: (ITS#9101) man pages don't reflect some global options are actually global/database
by ryan＠nardis.ca 25 Oct '19

25 Oct '19

On Fri, Oct 25, 2019 at 09:15:33PM +0000, quanah(a)symas.com wrote: >Correction, slapd-config(5) handles this via discussion of the frontend >database. Sort of - at least it has that distinction, but the three attrs you mentioned are still documented only in the GLOBAL CONFIGURATION OPTIONS section and not in the GLOBAL DATABASE OPTIONS section, while they actually are accepted on both, as you noted.

1 0

Re: (ITS#9101) man pages don't reflect some global options are actually global/database
by quanah＠symas.com 25 Oct '19

25 Oct '19

--On Friday, October 25, 2019 10:09 PM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.48 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.154.120) > > > The slapd.conf(5)/slapd-config(5) man pages list the security/olcSecurity > configuration option as a "GLOBAL" only config option. Correction, slapd-config(5) handles this via discussion of the frontend database. It's slapd.conf(5) where this is a mess (doesn't have any differentiation). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9101) man pages don't reflect some global options are actually global/database
by quanah＠openldap.org 25 Oct '19

25 Oct '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.154.120) The slapd.conf(5)/slapd-config(5) man pages list the security/olcSecurity configuration option as a "GLOBAL" only config option. However, inspection of the code reveals that it is in fact global OR a general database option. The man pages should be updated to reflect this fact. The same issue exists for the sizelimit and timelimit directives as well. May need to add a new structure to the manual pages to cover these 3 items, as they appear to be the only things that can exist as both global and per-db items. I.e., we should cover what happens if they are set both globally and per-db (what takes precedence, etc).

1 0

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

25 Oct '19

philip.brusten(a)kuleuven.be wrote: > Full_Name: Philip Brusten > Version: 2.4.47 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:2c40:100:b210::1:c3bc) > > > Hi > > we are experiencing issues with MS LDAP clients that connect to our OpenLDAP > servers since v2.4.47, because of the fix for issue ITS#8840 > > 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. > At > https://docs.microsoft.com/en-us/windows/win32/api/_ldap/ there is a link to > Lightweigt Directory Access Protocol > (https://docs.microsoft.com/en-us/windows/desktop/ldap), but it gives a 404. > > MS is the owner of that LDAPControl LDAP_SERVER_DOMAIN_SCOPE_OID > 1.2.840.113556.1.4.1339. According to the RFC4511 [1] the controlValue is > defined by its specification: > >> The controlValue may contain information associated with the >> controlType. Its format is defined by the specification of the >> control. Implementations MUST be prepared to handle arbitrary >> contents of the controlValue octet string, including zero bytes. It >> is absent only if there is no value information that is associated >> with a control of its type. When a controlValue is defined in terms >> of ASN.1, and BER-encoded according to Section 5.1, it also follows >> the extensibility rules in Section 4. > > The latest specification can be found at: > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/ba5f20… > >> "When sending this control to the DC, the controlValue field of the Control > structure is omitted." > > We observed that whenever MS clients are sending the domainScope control they > add an octet string as the controlValue with bytes "04 00". But this causes the > OpenLDAP code > if ( !BER_BVISNULL( &ctrl->ldctl_value )) { > to evaluate to true, which returns the LDAP_PROTOCOL_ERROR in OpenLDAP. This is the correct response to a malformed message according to RFC4511. > > 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. 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... > > Wireshark trace of MS LDAP client with domainScope control: > https://i.imgur.com/gwBjLMr.png > Wireshark trace of ldapsearch with domainScope control: > https://i.imgur.com/2RbFkIY.png > > Regards, > Philip > > > [1] https://tools.ietf.org/html/rfc4511#section-4.1.11 > [2] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c5e87… > [3] https://github.com/openldap/openldap/blob/master/servers/slapd/controls.c#L… > [4] https://github.com/openldap/openldap/blob/master/clients/tools/ldapsearch.c… > > -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2019