openldap-bugs November 2014

openldap-bugs@openldap.org

15 participants
43 discussions

Re: (ITS#7985) Recursive values
by michael＠stroeder.com 18 Nov '14

18 Nov '14

belykh.o(a)gmail.com wrote: > Error details: request returns recursive values on some leaves. What does the slapcat output look like? Also which overlays are configured? slapo-rwm? Ciao, Michael.

1 0

Re: (ITS#7985) Recursive values
by andrew.findlay＠skills-1st.co.uk 18 Nov '14

18 Nov '14

On Tue, Nov 18, 2014 at 11:47:10AM +0000, belykh.o(a)gmail.com wrote: > Error details: request returns recursive values on some leaves. Some sensitive > values replaced with '…' Please check: That is certainly an odd one. You are going to have to supply a lot more information before the developers will consider this a usable bug report, but before getting into that I suggest you stop the server and use slapindex to re-build all the indexes. If you have been modifying the configuration after loading data it is possible that the index data is inconsistent. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

(ITS#7985) Recursive values
by belykh.o＠gmail.com 18 Nov '14

18 Nov '14

Full_Name: Oleg Belykh Version: 2.4.40 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.99.40.12) We are testing latest OpenLDAP 2.4.40 with mdb (FreeBSD 10) with our custom schema and structure. Error details: request returns recursive values on some leaves. Some sensitive values replaced with 'âŠ' Please check: custom schema: # Telephone Attributes attributetype ( 1.3.6.1.4.1.4203.666.6273.2.1 NAME 'telephoneNumberAccessCode' DESC 'Access code for telephoneNumber services' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.2 NAME 'faxDeliveryMailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.3 NAME 'voiceDeliveryMailbox' DESC 'Voice Mailbox' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.4203.666.6273.2.4 NAME 'phoneGroupName' DESC 'Telephone Group Name'D0D EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) objectclass ( 1.3.6.1.4.1.4203.666.6273.2.100 NAME 'telephoneNumberAccount' DESC 'Telephone account' SUP top STRUCTURAL MUST ( telephoneNumber ) MAY ( userPassword $ telephoneNumberAccessCode $ macAddress $ faxDeliveryMailbox ) ) ldapsearch results: root@sw:/lib/ldap # ldapsearch -H 'ldapi://%2fvar%2frun%2fopenldap%2fldapi/' -W -b 'dc=âŠ' -D 'cn=ldroot,dc=âŠ' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=âŠ> with scope subtree # filter: (objectclass=*) # requesting: ALL # # âŠ dn: dc=âŠ objectClass: dcObject objectClass: organization objectClass: top dc: ... o: ... # accounts, âŠ dn: ou=accounts,dc=âŠ objectClass: top objectClass: organizationalUnit ou: accounts # persons, accounts, âŠ dn: ou=persons,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: persons # kerberos, accounts, âŠ dn: ou=kerberos,ou=accounts,dc=âŠ objectClass: organizaonalalUnit ou: kerberos # mails, accounts, âŠ dn: ou=mails,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: mails # phones, accounts, âŠ dn: ou=phones,ou=accounts,dc=âŠ objectClass: organizationalUnit ou: phones # groups, âŠ dn: ou=groups,dc=âŠ objectClass: top objectClass: organizationalUnit ou: groups # userGroups, groups, âŠ dn: ou=userGroups,ou=groups,dc=âŠ objectClass: organizationalUnit ou: usergroups # phoneGroups, groups, âŠ dn: ou=phoneGroups,ou=groups,dc>2E2Š objectClass: organizationalUnit ou: phonegroups # computers, âŠ dn: ou=computers,dc=âŠ objectClass: top objectClass: organizationalUnit ou: computers # services, âŠ dn: ou=services,dc=âŠ objectClass: top objectClass: organizationalUnit ou: services # manager, accounts, âŠ dn: uid=manager,ou=accounts,dc=âŠ objectClass: account objectClass: simpleSecurityObject uid: manager userPassword:: ... # freeswitch, accounts, âŠ dn: uid=freeswitch,ou=accounts,dc=âŠ objectClass: account objectClass: simpleSecurityObject uid: freeswitch userPassword:: ... # admins, userGroups, groups, âŠ dn: cn=admins,ou=userGroups,ou=groups,dc=âŠ objectClass: posixGroup cn: admins gidNumber: 10000 description: Group account memberUid: ... # users, userGroups, groups, âŠ dn: cn=users,ou=userGroups,ou=groups,dc=âŠ objectClass: posixGroup cn: users gidNumber: 10001 description: Group account # ..., persons, accounts, âŠ dn: uid=...,ou=persons,ou=accounts,dc=2%2Š objectClass: posixAccount objectClass: top objectClass: inetOrgPerson gidNumber: 10000 givenName: ... initials: v sn: .. displayName: ... uid: ... homeDirectory: /dev/null loginShell: /bin/sh cn: ... uidNumber: 20107 userPassword:: ... telephoneNumber: 2020 ( !!!! ) # 1000, phones, accounts, âŠ dn: telephoneNumber=1000,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 2020, phones, accounts, âŠ dn: telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 2020 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephonumumber=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=0000,telephoneNumber=2020,ou=phones,o u=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 2020, phones, accounts, â080Š dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000% 1 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=... telephoneNumber: 1000 telephoneNumberAccessCode:86864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=p hones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 64%0 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, time. kz dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 2020, phones, accounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=1000,telephoneNumber=2020,ou=phones,ou=accou nts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. # 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000, 1000!01000, 2020, phones, acc ounts, âŠ dn: telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNu mber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,tele phoneNumber=1000,telephoneNumber=1000,telephoneNumber=1000,telephoneNumber=20 20,ou=phones,ou=accounts,dc=âŠ telephoneNumber: 1000 telephoneNumberAccessCode: 8864 objectClass: telephoneNumberAccount userPassword:: âŠ. if you need screenshots from some ldap management utils, please mail me.

1 0

Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no 15 Nov '14

15 Nov '14

__sync_synchronize() needs an #ifdef around it. #ifdef __GNUC__, or something more general? Not sure what to do for the #else. We could mostly avoid using mm_txnid when the lockfile is initialized and use mti_txnid instead (e.g. in pick_meta). And penalize MDB_NOLOCK with some sync call in the #else. -- Hallvard

1 0

(ITS#7982) Add tls cipher suite, protocol to ldapsearch debug logging
by quanah＠openldap.org 14 Nov '14

14 Nov '14

Full_Name: Quanah Gibson-Mount Version: 2.4.40 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.14.70.124) Support for logging the TLS protocol and cipher suite being used was added for slapd connections in ITS#7683. However, there's no way from the client side (for those who don't have access to the LDAP server) to see what protocol and cipher suite were negotiated. This can be useful information to have on hand.

1 0

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2014