openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

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

27 Oct '19

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

1 0

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

27 Oct '19

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

1 0

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

27 Oct '19

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

1 0

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

27 Oct '19

ydgdsnn(a)163.com wrote: > 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. We saw this the first time, no need to resubmit it 10 times. Supposing you could put an encrypted password into ldap.conf - where would you put the key for decrypting the password, so that the software can use it? When LDAP is *correctly* used to manage user and group information, the credentials used to contact the LDAP server belong to a low-privilege account, so that theft of those credentials is of minimal harm. And they are used by a single authentication daemon (like nslcd in the nss-pam-ldapd package) and as such never appear in any world-readable files. Closing this ITS and all the other copies of it. -- -- 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#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

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