openldap-technical

openldap-technical@openldap.org

3 participants
9990 discussions

Search issue (objectclass=person) (Possible dupe email)
by Tuc 16 May '14

16 May '14

Hi, We're having an issue with a slightly older version of openldap. (2.4.23-26 on CentOS). Using Apache Directory Studio I do a search: "(objectclass=person)" on a search base of "ou=People,dc=example,dc=com" This should be the easiest and simplest search in the world. However, I get entries like : dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson cn: PLACEHOLDER_example agent gidNumber: 100 homeDirectory: /home/example_agent sn: agent uid: PLACEHOLDER_example_agent uidNumber: 621 givenName: example loginShell: /bin/bash userPassword:: DELETED and dn: uid=BDTestUser,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson cn: BD sn: User displayName: BD User givenName: BD mail: seo(a)example.com mobile: +1 1111111111 ou: Sales telephoneNumber: +1 222222222 title: BD Sample User uid: BDTestUser userPassword:: DELETED Where am I going wrong? Tuc

5 17

ldapadd errors
by Brendan Kearney 16 May '14

16 May '14

[root@test mdb]# slapd -V @(#) $OpenLDAP: slapd 2.4.39 (Feb 4 2014 09:07:17) $ mockbuild@buildvm-25.phx2.fedoraproject.org:/builddir/build/BUILD/openldap-2.4.39/openldap-2.4.39/servers/slapd i am trying to add ipNetwork entries to my tree, and at first i was getting "index generation failed" errors after several thousand entries were added. i removed the indexing of the cn attribute and restarted slapd and reran the loading of the entries. the existing objects were moved past, and some new objects were added. then some new errors came out. adding new entry "cn=64.89.32.0,c=US,ou=GeoLocation,dc=bpk2,dc=com" ldap_add: Other (e.g., implementation specific) error (80) additional info: entry store failed i am using lmdb. i have checked filesystem space, and that is not an issue. the data.mdb is about 10 MB in size. the job i am running is an ldapadd, using the rootdn ID. this is only because it is going against a test instance. the job is started with: ldapadd -h test.bpk2.com -D cn=Manager,dc=my-domain,dc=com -W -f geolocation.ldif -S geo_errors.out -c the data is a parsed version of the IpToCountry.csv geolocation info. there are 137951 unique dn's to be added (with cn, ipnetworknumber, ipnetmasknumber, l, and 2 objectclasses per dn), and i am part way through the list. the ldif file is about 25 MB in size. all of the parent objects exist, as that was a previous job to add them. this is just to create the networks below each of the parent objects. where can i look for places to identify the issue? has anyone run into something like this before? a quick google only shows threads for BDB/HDB backends, but i am using LMDB. thanks in advance, brendan kearney

4 3

replica of schema info
by Francesco Malvezzi 16 May '14

16 May '14

good morning, I would like to be able to replicate the schema info only from cn=config. I tried to add the olcSyncrepl to cn=schema dn: cn=schema,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: .... but doesn't work: <olcSyncrepl> only allowed within database declaration I tried to push a whole new olcDatabase={0}config (next step would be to add glue overlay to olcDatabase={1}config,cn=config) dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break olcAccess: {1}to dn.base="cn=config" by * none olcSuffix: cn=schema,cn=config olcRootDN: cn=admin,cn=schema,cn=config olcRootPW:: e1NTSEF9bnNNYkxIMFhFTm0zaXA5N0JXaHRVb3RwTlRsRXRxNTA= olcMonitoring: FALSE olcSyncrepl: .... but it doesn't work: olcSuffix: value #0: suffix <cn=schema,cn=config> not allowed in config database. It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with a filter like: olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple search base="cn=schema,cn=config" filter="(!(cn=core))" but then the whole olcDatabase={0}config,cn=config becomes a shadow context and I'm unable to ldapmodify anything (olcLoglevel for example). What am I missing? thank you for reading me, Francesco

2 5

Need Schema for aci attribute
by neel 16 May '14

16 May '14

Hi, I have compiled and configured OpenLDAP 2.4.39 with ACI. I am trying to integrate one application with LDAP. I have entered all settings. Authentication is working fine. Only thing when it tries to add some entries to ldap, it says that "err=17 text=aci: attribute type undefined" Can you please provide schema for aci attribute? Regards Neelesh

7 20

[LMDB] Choosing right environment flags
by Alain 14 May '14

14 May '14

I need to better understand the best way to configure the various environment flags related to sync and map. When we converted from BDB to LMDB, we instinctively kept #MDB_NOSYNC true. This proved to make the database subject to corruption if it was killed or stopped too harshly. It also had the effect on Windows at least to make Windows gradually use up all available RAM for the memory mapped file and to bring the server to its knees. After carefully reading the documentation about leaving "the system with no hint for when to write transactions to disk" when MDB_NOSYNC was turned on, we completely went without setting any options. The results were that we can't corrupt the database, but the speed degradation makes this approach unusable, as we are very heavily write focused (at least in this part of our process, where we perform analysis and load the database with 100's millions of records). In looking at the documentation I'm tempted to try MDB_WRITEMAP with MDB_MAPASYNC but do I then need to also issue some manual mdb_env_sync and if so at what frequency and what should trigger this? What are best practices combinations of those flags here. We absolutely can't afford database corruption, but we can deal with one (or maybe more with some re-design) transactions that are lost. Please guide us. Thanks Alain

2 1

password policy module memory leaks / excessive replication?
by Paul B. Henson 13 May '14

13 May '14

I've been testing the password policy module lately. I updated our development LDAP infrastructure Monday, basically loading and enabling the module, adding a default policy: dn: cn=default,ou=ppolicy,dc=csupomona,dc=edu cn: default objectClass: organizationalRole objectClass: pwdPolicy pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 And a policy specific for service accounts: dn: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu cn: serviceaccount objectClass: organizationalRole objectClass: pwdPolicy pwdAttribute: userPassword After some initial testing and determining that the current implementation is not suitable for account lockouts, I haven't touched it since Monday. Yesterday, I started getting alerts that the systems were low on memory, and upon looking, found extremely bloated slapd processes. Next, I started getting alerts that the accesslog mdb was running out of space. Upon investigation, I found that the service account that is used to gather statistics was generating a considerable amount of churn every time it authenticated (every 30 seconds). This account was explicitly configured to use the service account password policy: dn: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu objectClass: person cn: slapd-monitor sn: LDAP monitoring account pwdPolicySubentry: cn=serviceaccount,ou=ppolicy,dc=csupomona,dc=edu Which should be pretty much "do nothing". (I realize now that this policy will actually result in pwdFailureTime entries being created for failed authentications, and accumulating forever until a successful authentication, but there are no failed authentications for this service account, only successful ones, in this case). There were 1662836 entries in the access log for this dn since Monday that as far as I can tell solely change the CSN: dn: reqStart=20140502031556.000000Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20140502031556.000000Z reqEnd: 20140502031558.000000Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=csupomona,dc=edu reqDN: cn=slapd-monitor,ou=user,ou=service,dc=csupomona,dc=edu reqResult: 0 reqMod: entryCSN:= 20140501211559.348458Z#000000#003#000000 reqMod: modifiersName:= cn=ldaproot,dc=csupomona,dc=edu reqMod: modifyTimestamp:= 20140501211559Z reqEntryUUID: c16729b0-ce1e-4f9d-9123-e0b8f115133c entryUUID: 240ec245-0bac-4e20-b387-19243f720674 creatorsName: cn=accesslog createTimestamp: 20140501211559Z entryCSN: 20140501211559.348458Z#000000#003#000000 modifiersName: cn=accesslog modifyTimestamp: 20140501211559Z This explains why the accesslog was running out of space, it was full of these. It doesn't explain why the slapd process exploded in memory use, unless I suppose the steady-state memory usage of a slapd this busy processing replication is higher than one that's not quite so busy. But I'm confused as to why loading the password policy module, for an account with a policy configured to pretty much not do anything, results in a modification of the CSN for every authentication? I'm going to go peruse the source code to see if I can determine what's going on, but any expert opinions would be most welcome. Thanks much.

3 21

autoreconf failing with automake errors
by rajesh＠linux.vnet.ibm.com 13 May '14

13 May '14

Hi, I am trying to build the openldap package from the source following the release tarball from ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz. I am building this package in a new architecture ppc64le ( IBM PowerPC Little endian ). As the config.guess and libtool did not have the required patches to identify this new architecture, I did autoreconf -f -i in my build system whose latest automake and libtool has the patches of ppc64le. but the autoreconf failed with the following error automake: error: no 'Makefile.am' found for any configure output autoreconf: automake failed with exit status: 1 As the config.guess and configure scripts were updated with the ppc64le patches, i went ahead building the package. IT subsequently failed during 'make' with the following errors make[2]: Entering directory `/home/rajesh/openldap/openldap/libraries/liblber' rm -f version.c ../../build/mkversion -v "2.X" liblber.la > version.c /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c assert.c ../../libtool: 1: eval: base_compile+= cc: not found ../../libtool: 1: eval: base_compile+= -g: not found ../../libtool: 1: eval: base_compile+= -O2: not found ../../libtool: 1: eval: base_compile+= -I../../include: not found ../../libtool: 1: eval: base_compile+= -I../../include: not found ../../libtool: 1: eval: base_compile+= -DLBER_LIBRARY: not found ../../libtool: 1: eval: base_compile+= -c: not found libtool: compile: you must specify a compilation command libtool: compile: Try `libtool --help --mode=compile' for more information. make[2]: *** [assert.lo] Error 1 FYI, I also tried verified building the package in x86 ( Intel Box ) to get some clues if it is specific to ppc64le architecture. Without doing a autoreconf (which I dont require in my x86 laptop), the package building was sucessful. When I did autoreconf in my x86 laptop, I was struck with the similar errors as I had mentioned above. So, can anyone provide any clues how to progress or redirect this mail to the right person if this is not the right place to discuss this issue? Thanks and Regards Rajeshkumar S Linux Technology Center, IBM

2 1

LDAP_OPT_X_TLS_CACERTDIR not working.
by Seshadri, Anitha 13 May '14

13 May '14

Hi, I would like to open a discussion with OpenLDAP team. I hope this is the right email address. If not please let me know the correct to which this mail should be directed to. Issue: We are currently using OpenLdap 2.4.16 version on Win 64 .We are using RSA and MES Shareadapter internally to build the openldap libs. I am getting the below error when I use Sha-256 (2048 key length) certificates: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I am using the option LDAP_OPT_X_TLS_CACERTDIR and pass the cert directory which has the certificates. This fails. But the same passes when I use LDAP_OPT_X_TLS_CACERTFILE and point to the certicate which is of .pem format. Can you please let me know I am missing something here or is this a bug? Any help on this is appreciated. Thanks Anitha

3 2

Moving From Debian 2.4.31/hdb to LTB 2.4.39/mdb
by Andy Dorman 13 May '14

13 May '14

Hi. We have been using OpenLDAP for about 11 years now and have an MMR set up with 2 masters and 18 delta-syncrepl clients/slaves, all but 3 slaves are currently using back_hdb. Our beta test server and two load balancers are using back_mdb. The db is not too big with about 50,000 entries, 9 indexes (7 eq & 2 sub) and the slapdump ldif is about 41 MB. All our servers are Debian "testing" with a few packages from unstable and even experimental so we have the latest security and feature fixes for the work we do (email security filtering). Unfortunately, even the "bleeding edge" debian releases are waaaay behind in OpenLDAP. Last year we lost our system admin that set all this up, and I have been on a very steep learning curve since then. At this time I believe we need to move to a current version of OpenLDAP via ltb-project and switch to mdb, but I have run into a couple of questions we need to resolve first. FWIW, I would dearly like to help out the Debian community and compile & maintain an up-to-date version of OpenLDAP for them, but I need at least a couple more years of experience before it is even marginally safe to have other companies depending on my expertise with debian packaging. Anyway, after reading the OpenLDAP & ltb-project docs I have a couple of questions for anyone already using the ltb-project debian release, slapd.d & mdb. I hope the answers will help make our and others' transition go more smoothly. So here we go.... Question #1. I see that slapd.conf is deprecated and we should move to a slapd.d config db. However, the slapd.conf file (with git & cfengine) meets 3 key requirements for our service's configuration management: (1) audit trail, (2) peer review & staff notification, (3) automatic, staggered release to all servers so our users experience 0 downtime. I do not yet see an "easy" way to meet the first two requirements using slapd.d. To satisfy #3 I hope we can just update our master server slapd.d and config changes will be replicated to the slaves. Someone please correct me if I am wrong about that. To meet the requirement for an audit trail & staff review & notification, in the absence of someone's experience and/or knowledge from this group, we currently plan to use our ticket-tracking system (Request Tracker). Within an RT queue dedicated to our db systems we will document, review & manage slapd.d changes prior to actually making a change in the master which will then (I hope) propagate through delta-syncrepl. How does anyone else that is using slapd.d with an MMR setup with multiple client/slaves take care of their needs for an audit trail, peer review/staff notification, and release to all those servers? Question #2. This may be a simple one....When reading the latest OpenLDAP docs at http://www.openldap.org/doc/admin24/slapdconf2.html I noticed that there are no references to back_mdb in the configuration documentation...Specifically, "Table 5.2: Database Backends" and "Table 6.2: Database Backends" do not show an "mdb" option. Is this an oversight or is mdb going away already or am I completely confused? I suspect the answer is #3 ;-) Basically I need to know what to use in the "backend" & "database" directives (slapd.conf) or "olcBackend" attribute (slapd.d) if we want the mdb backend? Thank you for your insights and any information you can share. -- Andy Dorman Ironic Design, Inc. AnteSpam.com, ComeHome.net CONFIDENTIALITY NOTICE: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any erroneous transmission. If you receive this message in error, please immediately destroy it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, or copy any part of this message if you are not the intended recipient.

2 1

problems in memberof overlay
by goal jeff 13 May '14

13 May '14

hi. I configured the function of 'memberof overlay' these days. At first I used the methods on the webpage of http://www.openldap.org/doc/admin24/overlays.html, I add the codes of "overlay memeberof" in the file of slapd.conf,then I started the slapd service, the system give me an error "overlay "memberof" not found" . second,I googled the internet and found an article on this webpage:http://www.redmine.org/projects/redmine/wiki/RedmineLDAP,so I create two LDIF files as follow: the first file : dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: memberof the second file: dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf after I entered the command "ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f 1.ldif",the system give an error:"ldap_add: Insufficient access (50)" please help me ,thanks.

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical