openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

RE24 testing call (2.4.43)
by Quanah Gibson-Mount 03 Dec '15

03 Dec '15

If you know how to build OpenLDAP manually, and would like to participate in testing the next set of code for the 2.4.43 release, please do so. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & build. Execute the test suite (via make test) after it is built. Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

5 7

Strange LDAP searches for time, IP address and system users
by MI 03 Dec '15

03 Dec '15

I see very strange searches in my slapd.log, and wonder what I my have misconfigured. On every SSH connection (with ssh key, not password) : Search for the TTY: slapd[3183]: conn=1000 op=307 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=pts/2))" slapd[3183]: conn=1000 op=307 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass For the date: slapd[3183]: conn=1000 op=308 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=2015-12-03))" The time: slapd[3183]: conn=1000 op=309 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=16:28))" The IP: slapd[3183]: conn=1000 op=310 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=\28192.168.99.206\29))" (But I don't see "uid=root" when logging in over SSH with a key.) I wouldn't expect to see a search for "root", since it's a system account, and I use a key, so I would expect LDAP to be completely out of the picture. However, I do see many searches in the logs for other system accounts: filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=man))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=postfix))" filter="(&(objectClass=posixAccount)(uid=debian-spamd))" filter="(&(objectClass=posixAccount)(uid=amavis))" filter="(&(objectClass=posixAccount)(uid=\2A))" ... Most seem to be triggered by the standard system cron jobs or service restarts etc. The system is Debian 8.2 "Jessie". The following packages related to ldap or pam are installed: ldap-utils 2.4.40+dfsg-1+deb8u1 libaprutil1-ldap:amd64 1.5.4-1 libldap-2.4-2:amd64 2.4.40+dfsg-1+deb8u1 libnss-ldap:amd64 265-3+b1 libpam0g:amd64 1.1.8-3.1 libpam-ldap:amd64 184-8.7+b1 libpam-modules:amd64 1.1.8-3.1 libpam-modules-bin 1.1.8-3.1 libpam-runtime 1.1.8-3.1 nscd 2.19-18+deb8u1 slapd 2.4.40+dfsg-1+deb8u1 At this point, it's difficult for me to know what may be relevant, so I'm afraid I have to paste a lot of stuff here in the hope that it includes some clue for someone... # egrep 'cache|check' /etc/nscd.conf enable-cache passwd yes check-files passwd yes enable-cache group yes check-files group yes enable-cache hosts yes check-files hosts yes enable-cache services yes check-files services yes enable-cache netgroup yes check-files netgroup yes # grep ldap /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap # listconf /etc/pam_ldap.conf host 127.0.0.1 base dc=mydomain,dc=lan ldap_version 3 rootbinddn cn=admin,dc=mydomain,dc=lan pam_password crypt # listconf /etc/pam.d/common-auth auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so # listconf /etc/pam.d/common-account account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required pam_permit.so # listconf /etc/pam.d/common-password password [success=2 default=ignore] pam_unix.so obscure sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass password requisite pam_deny.so password required pam_permit.so # listconf /etc/pam.d/common-session session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so session optional pam_ldap.so My LDAP olcLogLevel is "filter stats sync". Please let me know if the other lines of that log may be useful, or if other log levels should be enabled (I tried, but didn't notice anything interesting). Well, if you have read so far, now is the time to tell me that this is all useless and that I should have posted that other essential config file which I missed ... :-) Thanks for any help in solving this mystery, MI

1 0

RE: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17)
by Sergio NNX 02 Dec '15

02 Dec '15

> What git revision of LMDB did you test? The last tag from git repository, 0.9.16 Thanks. > Subject: Re: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17) > To: sfhacker(a)hotmail.com > From: hyc(a)symas.com > Date: Wed, 25 Nov 2015 13:02:44 +0000 > > Sergio NNX wrote: > > Ciao, > > > > We are testing the latest version of Cyrus SASL against LMDB (on Windows, > > built from source) and when we run the testsuite app, we get a runtime > > exception shown below: > > Please use the -technical mailing list for LMDB discussions. > > > > > ... > > ... > > Testing sasl_listmech()... ok > > Testing serverstart... All memory accounted for! > > ok > > Testing client-first/no-server-last correctly... > > SRP --> start > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00000000 in ?? () > > (gdb) bt > > #0 0x00000000 in ?? () > > #1 0x00432a4d in mdb_node_search (mc=mc@entry=0x289608, > > key=key@entry=0x289850, exactp=exactp@entry=0x289604) at mdb.c:4943 > > #2 0x004361bc in mdb_cursor_set (mc=mc@entry=0x289608, > > key=key@entry=0x289850, data=data@entry=0x289858, op=op@entry=MDB_SET, > > exactp=exactp@entry=0x289604) at mdb.c:5725 > > #3 0x0043667c in mdb_get (txn=0x35c7b0, dbi=1, key=0x289850, data=0x289858) > > at mdb.c:5391 > > #4 0x00431a55 in _sasldb_getdata () > > #5 0x0042fda3 in sasldb_auxprop_lookup () > > #6 0x004119f7 in _sasl_auxprop_lookup () > > #7 0x00413a6c in _sasl_canon_user_lookup () > > #8 0x0042ea7e in srp_server_mech_step () > > #9 0x0040cddd in sasl_server_step () > > #10 0x0040d361 in sasl_server_start () > > #11 0x0040458f in doauth () > > #12 0x004060d6 in test_clientfirst () > > #13 0x00406405 in foreach_mechanism () > > #14 0x00733d1f in main () > > (gdb) > > > > > > Building SASL against Berkeley DB does not show the same issue. > > > > Any pointers will be greatly appreciated. > > > > Thanks. > > > > Sergio.

2 2

memberOf-overlay and custom schema (slapd.logs attched)
by Dora Paula 02 Dec '15

02 Dec '15

Hi, I want to have some kind of dn-based association between two custom entries (e.g. account<--dn-->device). Therefore I use a combination of the memberOf- and refint overlay (configuration inspired by test057). I use a custom schema: An auxiliary objectClass called "association". It has only one may-attribute called "associate". The custom 'memberOf'-Attribute is called "associationOf", which is a may-attribute of the objectClass "myAccount" (derived from account): OpenLDAP Version: git OPENLDAP_REL_ENG_2_4 #example.com.schema # attributeType ( 1.3.6.1.4.1.9999999.10.1.1 NAME 'associate' DESC 'an associate' SUP distinguishedName ) attributeType ( 1.3.6.1.4.1.9999999.10.1.2 NAME 'associateOf' DESC 'associate of' SUP distinguishedName ) objectClass ( 1.3.6.1.4.1.9999999.10.2.1 NAME 'association' DESC 'association' SUP top AUXILIARY MAY ( associate ) ) objectClass ( 1.3.6.1.4.1.9999999.10.2.2 NAME 'myAccount' DESC 'my account' SUP account STRUCTURAL MAY ( associateOf ) ) #slapd.conf # include /opt/slapd_example.com/etc/openldap/schema/core.schema include /opt/slapd_example.com/etc/openldap/schema/cosine.schema include /opt/slapd_example.com/etc/openldap/schema/ppolicy.schema include /opt/slapd_example.com/etc/example.com.schema pidfile /opt/slapd_example.com/var/run/slapd.pid argsfile /opt/slapd_example.com/var/run/slapd.args loglevel none password-hash {CLEARTEXT} attributeOptions lang- access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootdn "cn=admin,dc=example,dc=com" database mdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw "admin" directory /opt/slapd_example.com/var/openldap-data index objectClass,cn,ou,o,dc eq add_content_acl on overlay memberof memberof-group-oc association memberof-member-ad associate memberof-memberof-ad associateOf memberof-dangling ignore memberof-refint FALSE memberof-dn olcOverlay={1}memberof,olcDatabase={2}mdb,cn=config overlay refint refint_attributes associate associateOf refint_nothing olcOverlay={0}refint,olcDatabase={2}mdb,cn=config refint_modifiersname olcOverlay={0}refint,olcDatabase={2}mdb,cn=config #After starting the server, first I add a custom account: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: uid=myAccount,dc=example,dc=com changetype: add objectClass: top objectClass: myAccount uid: myAccount EOF #Then I add a naked device: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: add objectClass: top objectClass: device cn: device EOF Now I try to associate them using a single modify operation (adding the aux-objectClass association and the associate attribute). This approach fails, that means: The operation passes without error, but the account's associationOf attribute isn't added. #This modify operation seems to be ignored by memberOf-overlay: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association - add: associate associate: uid=myAccount,dc=example,dc=com - EOF #slapd-log (loglevel -1), see attached all-inclusive-modify.log #Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL # # device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com # myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 The second approach (resetting the device and myAccount entry and split the above modify operation into two operations works fine. Details see here: #Splitting the previous modify operation into two works fine: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association EOF cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: associate associate: uid=myAccount,dc=example,dc=com EOF #slapd-log (loglevel -1), see attached split-modify.log #Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL # # device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com # myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount associateOf: cn=device,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Long story, short question: Is this the intended behaviour? If not is it caused by a misconfiguration or a bug? Thank you very much for your help! Best regards Dora

2 1

OpenLDAP 2.4.43 packages for RedHat/CentOS
by Clément OUDOT 02 Dec '15

02 Dec '15

Hi all, you can find RPM packages for OpenLDAP 2.4.43 on LTB project : http://ltb-project.org/wiki/download?&#packages_for_red_hatcentos Debian packages should be available soon. -- Clément OUDOT Consultant en logiciels libres, Expert infrastructure et sécurité Savoir-faire Linux

1 0

updated my openSUSE packages (was: OpenLDAP 2.4.43 available)
by Michael Ströder 01 Dec '15

01 Dec '15

OpenLDAP Project wrote: > OpenLDAP 2.4.43 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ Thanks to OpenLDAP team for the new release. I've updated my private openSUSE packages to this release. The OBS source: https://build.opensuse.org/package/show/home:stroeder:branches:network:ldap… Repos for various SUSE versions: http://download.opensuse.org/repositories/home:/stroeder:/branches:/network… Please test. Ciao, Michael.

2 2

OpenLdap Clear-text Password in Debug Mode
by Rich Alford 01 Dec '15

01 Dec '15

Hi All: I'm not sure if this issue results from my ignorance of OpenLdap, or it's not capable of resolving. Regardless, any direction you can provide would be greatly appreciated: I have a basic OpenLdap installation with TLS encryption. Passwords are hashed in the ldap directory. The user password travels from client to server encrypted as it should, then gets unencrypted by slapd, and IF IN DEBUG MODE gets displayed in *clear-text*. Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database. What am I missing?? Thank you, Rich

3 3

playing with ldap protocol
by Friedrich Locke 28 Nov '15

28 Nov '15

i am trying to understand ldap protocol! i have read the RFC 4511 (i believe) about it. In order to understand it better, i wrote a program that reads from internet and writes to an output file. I have issued the following ldapsearch command: ldapsearch -x -h localhost -p 2000 -D ou=ufv,dc=br -w 123456 What i got on the output file was: sioux@scallop$ hexdump -C o 00000000 30 1e 02 01 01 60 19 02 01 03 04 0c 6f 75 3d 75 |0....`......ou=u| 00000010 66 76 2c 64 63 3d 62 72 80 06 31 32 33 34 35 36 |fv,dc=br..123456| 00000020 I have the following understanding o f the protocol: 60 19 [02 01 [3] 04 0c [ou=ufv,dc=br] 80 06 [123456]] What about the first "30 1e 02 01 01" ? 1e means the size is bigger than 30 and 2 bytes is specified ? Is it for the message id ? What about the rest of 27 bytes of message what is not accounted ? Shoud it not account for the 27 bytes length ? Thanks in advance. BTW: what is the message id for the message sent ?

4 3

LMDB overflow pages - MDB_RESERVE
by Christian Sell 27 Nov '15

27 Nov '15

I forgot to mention: I am using MDB_RESERVE to avoid extra memcpy. Could it be that this is the cause for the extreme database bloat? > Hello, > > something wrong with the question below? > > I am trying to use LMDB to store large (huge) amounts of binary data which, > for > the reason of limiting memory footprint, are split into chunks. Each chunk ist > stored under a separate key, made up of [collectionId, chunkId], so that I can > later iterate the chunks using a LMDB cursor. Chunk size is configurable. > > During my tests, I encountered a strange scenario where, after inserting some > 2000 chunks consisting of 512KB each, the database size had grown to a value > that was roughly 135 times the calculated size of the data. I ran the stat > utility over the db and saw that there were > 12000 overflow pages vs. approx. > 2000 data pages. When I reduced the chunk size to 4060 bytes, the number of > overflow pages went down to 1000, and the database size went down to the > expected number (I experimented with different sizes, this was the best > result). > I did not find any documentation to explain this behaviour, or how to deal > with > it. Of course it makes me worry about database bloat and the consequences. Can > anyone shed light on this? > > thanks, > Christian > Christian Sell

1 1

Getting around the single-threaded syncrepl model?
by Bannister, Mark 25 Nov '15

25 Nov '15

I was speaking with Howard in person last week at LDAPCon about the problems I might hit if I wanted to run hundreds of replicas off a single master. If I heard right, Howard told me that OpenLDAP uses a single thread for replication, and therefore processes each replica in a serial fashion, one at a time. If any replica is going slowly (high network latency for example), it would have a knock-on effect to the time it takes to get changes replicated across the whole estate. We have an aggressive target to meet - updates out in 5 minutes. Updates are small, but alarm bells are now ringing in my head about OpenLDAP's ability to deliver this. This leads to a couple of questions: 1 - How easy would it be to patch OpenLDAP 2.4 to get the master to use multiple threads for replication? Is that a reasonably straightforward fix, or is this quite a sizeable architectural change? 2 - If my master server has 40 cores, would there be mileage in setting up a number of slapd processes (say 10) on the same host, bound to different sockets, all acting as first-level replicas, and then all the replicas fanning out across the WAN synchronise from these processes rather than from the master process? That would be a way, I suppose, of getting the master server to make better use of the available cores to get updates out quicker? Thanks, Mark. ________________________________ NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

8 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical