Re: (ITS#7985) Recursive values
by michael＠stroeder.com
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.
8 years, 6 months
Re: (ITS#7985) Recursive values
by andrew.findlay＠skills-1st.co.uk
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 |
-----------------------------------------------------------------------
8 years, 6 months
(ITS#7985) Recursive values
by belykh.o＠gmail.com
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.
8 years, 6 months
Re: (ITS#7969) LMDB: Globally shared fields of meta-data are not 'volatile'.
by h.b.furuseth＠usit.uio.no
__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
8 years, 6 months
(ITS#7982) Add tls cipher suite, protocol to ldapsearch debug logging
by quanah＠openldap.org
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.
8 years, 6 months
(ITS#7981) Feature request: Crypt scheme in pwdPolicy
by michael＠stroeder.com
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. ;-)
8 years, 6 months
(ITS#7980) LMDB added support for user context in compare function
by rouzier＠gmail.com
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/33f1dc8be4a8503e78930f130ff9c8...
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.
--
8 years, 6 months
Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com
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/
8 years, 6 months
Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by mreynolds＠redhat.com
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
>
8 years, 6 months
Re: (ITS#7979) mozNSS does not process TLS_PROTOCOL_MIN
by hyc＠symas.com
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/
8 years, 7 months
