openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

How to import user certificates in OpenLDAP?
by Vaclav Barta 16 Jul '15

16 Jul '15

Hi, I'd like to have a test setup for a module I'm maintaining, which basically authenticates IIS users against an LDAP server. I've installed OpenLDAP (OpenLDAP for Windows, 64-bit, version 2.4.40, to be specific) and added some user accounts to it, which worked, except I'm having trouble including X.509 certificates in the user definitions (which the tested module is supposed to check). I've found "Publishing digital certificates with LDAP" at http://www.tldp.org/HOWTO/archived/LDAP-Implementation-HOWTO/certificates.h… , which sounds like what I need, but it's old, and recommends "using the ldif utility provided with OpenLDAP" - which the latest OpenLDAP for Windows (nor any other OpenLDAP packages I've checked) doesn't have. How do I publish digital certificates with OpenLDAP? Bye Vaclav -- http://www.mangrove.cz

5 10

2.4.41 RPMs for openSUSE
by Michael Ströder 16 Jul '15

16 Jul '15

HI! I've updated my OpenLDAP builds for openSUSE and SLES12 to release 2.4.41. Build status and files: https://build.opensuse.org/package/show/home:stroeder:branches:network:ldap… If you're using the openldap packages shipped with openSUSE make sure to read the .changes files to see whether something could break your current setup. I've tested openSUSE Tumbleweed x86_64 and Factory_ARM on rasperry pi. The download repos are here: http://download.opensuse.org/repositories/home:/stroeder:/branches:/network… Make yourself familiar with zypper commands. Example: Add the repo in openSUSE 13.1 (command in one line): zypper addrepo --refresh http://download.opensuse.org/repositories/home:/stroeder:/branches:/network… Please test. Your feedback is appreciated. Especially have a look at whether the RPMs behave well regarding config files, package descriptions etc. Compared to stock SUSE packages there are two additional packages 1. openldap2-contrib with a selection of overlays from, you might have guessed, the contrib/ source directory. 2. openldap2-back-sock (see http://www.openldap.org/software/man.cgi?query=slapd-sock) Ciao, Michael.

2 1

Re: Optimization for OpenLdap 2.4.40
by PRATIK SINGAL 15 Jul '15

15 Jul '15

Hello all, Below are my db_stat -m and db_stat -c ouptput. Can any one help me if there is any problem with my BDB database perfromance. [root@AlepoHSS1 openldap-data]# db_stat -c 193 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 1000 Maximum number of locks possible 1000 Maximum number of lockers possible 1000 Maximum number of lock objects possible 80 Number of lock object partitions 3 Number of current locks 796 Maximum number of locks at any one time 10 Maximum number of locks in any one bucket 1 Maximum number of locks stolen by for an empty partition 1 Maximum number of locks stolen for any one partition 58 Number of current lockers 76 Maximum number of lockers at any one time 3 Number of current lock objects 331 Maximum number of lock objects at any one time 4 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 996M Total number of locks requested (996002179) 995M Total number of locks released (995952531) 0 Total number of locks upgraded 20 Total number of locks downgraded 551604 Lock requests not available due to conflicts, for which we waited 49643 Lock requests not available due to conflicts, for which we did not wait 0 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 744KB The size of the lock region 527185 The number of partition locks that required waiting (0%) 104625 The maximum number of times any partition lock was waited for (0%) 535 The number of object queue operations that required waiting (0%) 330905 The number of locker allocations that required waiting (0%) 11 The number of region locks that required waiting (0%) 4 Maximum hash bucket length [root@AlepoHSS1 openldap-data]# [12:35:48] Bhushan Gaikar: ##################### [12:35:48] Bhushan Gaikar: [root@AlepoHSS1 openldap-data]# db_stat -m 320MB 2KB 24B Total cache size 1 Number of caches 1 Maximum number of caches 320MB 8KB Pool individual cache size 0 Maximum memory-mapped file size 0 Maximum open file descriptors 0 Maximum sequential buffer writes 0 Sleep after writing maximum sequential buffers 0 Requested pages mapped into the process' address space 59M Requested pages found in the cache (98%) 849192 Requested pages not found in the cache 0 Pages created in the cache 849190 Pages read into the cache 285976 Pages written from the cache to the backing file 816982 Clean pages forced from the cache 0 Dirty pages forced from the cache 0 Dirty pages written by trickle-sync thread 31916 Current total page count 31863 Current clean page count 53 Current dirty page count 32771 Number of hash buckets used for page location 60M Total number of times hash chains searched for a page (60607061) 5 The longest hash chain searched for a page 95M Total number of hash chain entries checked for page (95749492) 250939 The number of hash bucket locks that required waiting (0%) 41624 The maximum number of times any hash bucket lock was waited for (0%) 81360 The number of region locks that required waiting (3%) 0 The number of buffers frozen 0 The number of buffers thawed 0 The number of frozen buffers freed 902887 The number of page allocations 2022291 The number of hash buckets examined during allocations 93 The maximum number of hash buckets examined for an allocation 817263 The number of pages examined during allocations 40 The max number of pages examined for an allocation 105981 Threads waited on page I/O Pool File: dn2id.bdb 4096 Page size 0 Requested pages mapped into the process' address space 5052618 Requested pages found in the cache (98%) 86602 Requested pages not found in the cache 0 Pages created in the cache 86603 Pages read into the cache 0 Pages written from the cache to the backing file Pool File: id2entry.bdb 16384 Page size 0 Requested pages mapped into the process' address space 34M Requested pages found in the cache (98%) 445111 Requested pages not found in the cache 0 Pages created in the cache 445111 Pages read into the cache 285976 Pages written from the cache to the backing file Pool File: objectClass.bdb 4096 Page size 0 Requested pages mapped into the process' address space 299999 Requested pages found in the cache (99%) 2 Requested pages not found in the cache 0 Pages created in the cache 2 Pages read into the cache 0 Pages written from the cache to the backing file Regards, Pratik On Fri, Jul 10, 2015 at 3:49 PM, PRATIK SINGAL <pratik.singal13(a)gmail.com> wrote: > Hello all, > > Can any one help to with the parameters which can optimize the openldap > performance. > > We are having high end machines(rhel 6.5 ,RAM-32GB) but could not achieve > more than 1000 TPS. > > Kindly help me with all the tuning parameters which will firstly improve > the ldap performance. > > Regards, > Pratik >

1 0

LDAP over TLS
by Aneela Saleem 14 Jul '15

14 Jul '15

Hi all, I have followed the following link to configure LDAP with TLS: https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ch-ldap-tls.htm… but when i run the search command: i.e., *ldapsearch -x -b "dc=platalytics,dc=com" -H 'ldap://localhost:389' -ZZ* i get the following error: ldap_start_tls: Protocol error (2) additional info: unsupported extended operation Following is my *ldap.conf* file: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=platalytics,dc=com URI ldap://127.0.0.1:389 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ldap/cacert.pem TLS_REQCERT allow TLSVerifyClient never Following is my *cn=config.ldif* file: # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 0cd16f20 dn: cn=config objectClass: olcGlobal cn: config *TLSCertificateFile: /etc/ldap/servercrt.pem* *TLSCertificateKeyFile: /etc/ldap/serverkey.pem* *TLSCACertificateFile: /etc/ldap/cacert.pem* olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: none olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 59729584-bdf0-1034-90b9-fdf431101d87 creatorsName: cn=config createTimestamp: 20150713211745Z entryCSN: 20150713211745.443612Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20150713211745Z Can anyone please help what could be the issue?

3 7

Columnar databases
by Kristoffer Sjögren 13 Jul '15

13 Jul '15

Hi I'm doing some experiments with LMDB trying to emulate a columnar storage database using roaring bitmaps and other tricks. The initial results are promising, but I ask myself, is a row based storage like LMDB appropriate for implementing a columnar database or are there better, more efficient ways/formats? Cheers, -Kristoffer

2 3

MODRDN with same RDN and delold: 0 and slapo-constraint
by Michael Ströder 11 Jul '15

11 Jul '15

HI! When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein? Ciao, Michael.

1 0

Crash while aborting connection on timeout...
by Emilio Pombo 11 Jul '15

11 Jul '15

Hi everyone! I'm working on a project using openLDAP C API (version 2.4.36) in a asynchronous way. Everything works quite well after two years of development cycles and product evolution. Since a year ago we have a few clients successfully running our LDAP module on their servers. Recently I've received a core dump file from one of our clients, with this stack frames: ... libc frames ... #6 0x00007f68887d3068 in ldap_int_bisect_find (v=<value optimized out>, n=<value optimized out>, id=<value optimized out>, idxp=<value optimized out>) at abandon.c:334 #7 0x00007f68887d32d2 in do_abandon (ld=0x7f67dcb0bbe0, origid=-1, msgid=-1, sctrls=<value optimized out>, sendabandon=1) at abandon.c:300 ... my application frames ... >From my code, I'm calling openldap_ldap_abandon_ext(ld, msgid, NULL, NULL) because a timeout has been reached after doing a openldap_ldap_sasl_bind(...) and getting LDAP_X_CONNECTING state, while waiting for the result of an LDAP_SUCCESS. As I've read on *abandon.c*, the assert( id >= 0 ) is executed only on certain flows, I guess... those which are involved in communication handshake with the server in advanced stages. So I think, I'm calling openldap_ldap_abandon_ext(...) at the wrong time. My question is: can I use something from the API (ldap.h) to prevent calling openldap_ldap_abandon_ext on this specific situation? I think I may add code in my application to prevent crashing, but also ensure aborting the connection correctly, as I have to respect my timeout policy. BTW, the calls to the openLDAP API in my code are all protected with the same boost::unique_lock<boost::mutex> to ensure thread safety. Logs shows that my module was under heavy load when the application crashed. I've only this core information, and I haven't been able to reproduce this situation on my integration tests, even doing a simulation of a slowdown in networking communications and shrinking timeouts. Thanks in advance for your help!

1 0

Re[2]: Replication mode - glibc detected *** slapd: double free or corruption
by Sterling Sahaydak 09 Jul '15

09 Jul '15

Thanks Quanah for the prompt reply as you've always provided on this list. Yes, just after I sent this, I realized the next question was going to be what version of OpenLDAP, which is, "OpenLDAP: slapd 2.4.39 " Yes, I'm using hdb: database hdb suffix "dc=example,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=example,dc=com" So, with 2.4.39 I should use ??? bdb or mdb? or? And as mentioned about slapo-rwm, I'm using ldap proxy to Active Directory mapping to: overlay rwm rwm-map objectclass posixAccount user rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute sn sn rwm-map attribute uidNumber uidNumber rwm-map attribute gidNumber gidNumber rwm-map attribute homeDirectory unixHomeDirectory rwm-map attribute loginShell loginShell rwm-map attribute mail mail rwm-map attribute * Is there a better way instead? Thanks a bunch! Sterling ------ Original Message ------ From: "Quanah Gibson-Mount" <quanah(a)zimbra.com> To: "Sterling Sahaydak" <sterling.sahaydak(a)pi-coral.com>; openldap-technical(a)openldap.org Sent: 7/9/2015 5:18:44 PM Subject: Re: Replication mode - glibc detected *** slapd: double free or corruption >--On Thursday, July 09, 2015 9:53 PM +0000 Sterling Sahaydak ><sterling.sahaydak(a)pi-coral.com> wrote: > >> >>I've had replication working for the last few months and now running >>into >>the following when I run: >>slapd -h "ldapi:/// ldap:/// ldaps:///" -d 4 >> >>I installed GIT on the server, version 1.7.1 which is a couple years >>old, >>but was wondering would that have anything causing replication to stop >>working? > >The openldap version is what is important, not the version of git. >However, it looks like you have a corrupt database: > >559edda4 hdb_db_open: database "dc=pi-coral,dc=com": unclean shutdown >detected; attempting recovery. > >back-hdb is deprecated in current OpenLDAP, and back-mdb is the >supported backend. I also note you appear to be using slapo-rwm, which >is known to have a variety of issues. > >--Quanah > > >-- > >Quanah Gibson-Mount >Platform Architect >Zimbra, Inc. >-------------------- >Zimbra :: the leader in open source messaging and collaboration

1 0

Replication mode - glibc detected *** slapd: double free or corruption
by Sterling Sahaydak 09 Jul '15

09 Jul '15

I've had replication working for the last few months and now running into the following when I run: slapd -h "ldapi:/// ldap:///ldaps:///" -d 4 I installed GIT on the server, version 1.7.1 which is a couple years old, but was wondering would that have anything causing replication to stop working? ... <= ldap_bv2dn(cn=Database 3,cn=Databases,cn=Monitor)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=database 3,cn=databases,cn=monitor)=0 559edda4 hdb_db_open: "dc=pi-coral,dc=com" 559edda4 hdb_db_open: database "dc=pi-coral,dc=com": unclean shutdown detected; attempting recovery. 559edda4 => bdb_entry_get: ndn: "dc=pi-coral,dc=com" 559edda4 => bdb_entry_get: oc: "(null)", at: "contextCSN" 559edda4 bdb_idl_fetch_key: 559edda4 bdb_idl_fetch_key: 559edda4 send_ldap_result: err=0 matched="" text="" 559edda4 [rw] searchDN: "ou=Users,ou=example,dc=ad,dc=example,dc=com" -> "ou=Users,ou=example,dc=ad,dc=example,dc=com" *** glibc detected *** slapd: double free or corruption (out): 0x00007f3382f44bb0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75e66)[0x7f339ab17e66] /lib64/libc.so.6(+0x789b3)[0x7f339ab1a9b3] slapd(filter_free_x+0x13a)[0x7f339ebd72da] /usr/lib64/openldap/rwm-2.4.so.2(+0xb34d)[0x7f3397d0c34d] /usr/lib64/openldap/rwm-2.4.so.2(rwm_filter_map_rewrite+0x2b)[0x7f3397d0c99b] /usr/lib64/openldap/rwm-2.4.so.2(+0x6c3a)[0x7f3397d07c3a] slapd(overlay_op_walk+0x4a)[0x7f339ec41efa] slapd(+0xbaa3b)[0x7f339ec42a3b] slapd(+0xb87ab)[0x7f339ec407ab] slapd(overlay_op_walk+0x4a)[0x7f339ec41efa] slapd(+0xbaa3b)[0x7f339ec42a3b] /usr/lib64/openldap/syncprov-2.4.so.2(+0x70ae)[0x7f3397afb0ae] /usr/lib64/openldap/syncprov-2.4.so.2(+0x72a0)[0x7f3397afb2a0] /lib64/libpthread.so.0(+0x79d1)[0x7f339b0489d1] /lib64/libc.so.6(clone+0x6d)[0x7f339ab8a8fd] ======= Memory map: ======== 7f337c000000-7f337c021000 rw-p 00000000 00:00 0 7f337c021000-7f3380000000 ---p 00000000 00:00 0 7f3381743000-7f3382745000 rw-p 00000000 00:00 0 7f3382745000-7f3382746000 ---p 00000000 00:00 0 7f3382746000-7f3382f46000 rw-p 00000000 00:00 0 7f3382f46000-7f3382f4e000 rw-s 00000000 ca:01 795307 /var/lib/ldap/__db.006 7f3382f4e000-7f3383006000 rw-s 00000000 ca:01 795306 /var/lib/ldap/__db.005 7f3383006000-7f3383246000 rw-s 00000000 ca:01 794767 /var/lib/ldap/__db.004 7f3383246000-7f3397248000 rw-s 00000000 ca:01 794749 /var/lib/ldap/__db.003 7f3397248000-7f3397af4000 rw-s 00000000 ca:01 794744 /var/lib/ldap/__db.002 7f3397af4000-7f3397b00000 r-xp 00000000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 7f3397b00000-7f3397cff000 ---p 0000c000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 7f3397cff000-7f3397d00000 r--p 0000b000 ca:01 538738 /usr/lib64/openldap/syncprov-2.4.so.2.10.2 ... 7f339f6ac000-7f339f9ee000 rw-p 00000000 00:00 0 [heap] 7fff8ad37000-7fff8ad4c000 rw-p 00000000 00:00 0 [stack] 7fff8ad84000-7fff8ad85000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Aborted

2 1

mdb wont replicate
by Brendan Kearney 08 Jul '15

08 Jul '15

at some point in the past, i wound up taking drastic measures and rebuilt my two ldap boxes after taking a backup of the data. i think my process could use some fine tuning and polishing, as a weird nuance has found its way into my environment. i am replicating, using MMR, both config and data between two servers. the config and schemas replicate without issue, as well as the data in the mdb, but not any of the settings for the mdb. if i try, for example, to add an ACL or Index to the mdb, i get an error "ObjectClass modifications are not allowed". i think the root of my issue is that i backed up one of the two boxes and restored the one backup to both boxes while they were both offline. i believe that because they both have the same backed up data on them, some of the internal attributes are identical and therefore conflict. i have seen logs about ContextCSNs being identical, but haven't had time to investigate those messages till now. in any case, whatever i did wrong now does not allow the mdb settings to be replicated between the boxes. what i am looking to understand is how to i correct the situation. i am looking to avoid recreating all of the data, so using backups, exports, etc is something i want to do, and do correctly. would i need to capture slapcat output to a file, or is ldapsearch the correct way to export the data for backup/restore needs? do i need to follow a destructive path to correct this issue or will surgery on the mdb correct my issue? i am running 2.4.39 on Fedora 20. any pointers would be appreciated. brendan

3 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical