openldap-technical

openldap-technical@openldap.org

9 participants
9873 discussions

objectClass index from slapd.conf is not working
by tim stone 14 Sep '10

14 Sep '10

Hello, I've a strange behavior while using index objectClass for searching. In my slapd.conf I have defined the index in the database section: index objectClass eq Other indexes follows in the config. All of them working fine. If I search via ldapsearch like: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(objectclass=Guest)" I can find following Message in the syslog (loglevel -1): Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read: failed (-30989) Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=0, first=0, last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=0 first=0 last=0 Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_filter_candidates Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=-1, first=228, last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=228 last=355772 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_list_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search_candidates: id=-1 first=112277 last=355755 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856]: <= test_filter 5 Sep 1 14:02:52 LDAP01 slapd[17856]: bdb_search: 112277 does not match filter Sep 1 14:02:52 LDAP01 slapd[17856]: entry_decode: "cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= entry_decode(cn=Aaa,cn=Bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_dn2id("cn=aaa,cn=bbb,... Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_dn2id: got id=0x1b696 Sep 1 14:02:52 LDAP01 slapd[17856]: => test_filter Sep 1 14:02:52 LDAP01 slapd[17856]: EQUALITY Sep 1 14:02:52 LDAP01 slapd[17856] ... all other entires following... As result, the entires are found, but not in the index and the search takes a very long time. After this, I have rebuild the complete database via slapcat/slapadd, rebuild the index via slapindex for objetClass, but nothing helped. In tried the test above on: * OpenSuSE 11.1 and openLDAP 2.4.21 and 2.4.23 (linked against libdb-4.5) * OpenSuSE 11.0 and openLDAP 2.4.9 (linked against libdb-4.5) * Debian Lenny and openLDAP 2.4.11 (linked against libdb-4.2) with different databases and a search against a objectClass. If I try another index (not objectClass) from the slapd.conf the index works, example: ldapsearch -x -h localhost -w password -D"cn=admin,ou=root" -b"ou=root" "(mypk=1234-234)" Sep 1 14:03:44 LDAP01 slapd[17856]: => bdb_equality_candidates (mypk) Sep 1 14:03:44 LDAP01 slapd[17856]: => key_read Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_index_read 1 candidates Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_equality_candidates: id=1, first=112838, last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_list_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: <= bdb_filter_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: bdb_search_candidates: id=1 first=112838 last=112838 Sep 1 14:03:44 LDAP01 slapd[17856]: => test_filter Sep 1 14:03:44 LDAP01 slapd[17856]: EQUALITY Sep 1 14:03:44 LDAP01 slapd[17856]: <= test_filter 6 Sep 1 14:03:44 LDAP01 slapd[17856]: => send_search_entry: conn 1002 dn="cn=Fff,cn=Eee,... Sep 1 14:03:44 LDAP01 slapd[17856]: <= send_search_entry: conn 1002 exit. Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_result: conn=1002 op=1 p=3 Sep 1 14:03:44 LDAP01 slapd[17856]: send_ldap_response: msgid=2 tag=101 err=0 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_get(12): got connid=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: connection_read(12): checking for input on id=1002 Sep 1 14:03:44 LDAP01 slapd[17856]: op tag 0x42, time 1283342624 Sep 1 14:03:44 LDAP01 slapd[17856]: conn=1002 op=2 do_unbind Sep 1 14:03:44 LDAP01 slapd[17856]: connection_close: conn=1002 sd=12 Why does only the objectClass index not work? The only difference I can see, is that all other indexes are based on "normal" attributes. I don't know, if it is necessary, but for objectClass I can't find a attribute definition in the schema. In the core.schema is the attribute definition for objectClass deactivated (aka #)... Here is the Config from the LDAP-Server: # Schema and objectClass definitions include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/my_ldap_attribute.schema include /etc/openldap/schema/my_ldap.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb sizelimit -1 timelimit 300 disallow bind_anon gentlehup on tool-threads 1 ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=root" rootdn "cn=root,ou=root" checkpoint 4096 15 rootpw password directory /var/lib/ldap dbnosync # Indices to maintain index objectClass,entryUUID,entryCSN eq index mypk,myusername pres,eq index myproperty,mylanguage eq index cn eq,sub Kindly regards Tim Stone

3 7

Re: invalid syntax on pwdPolicy object add
by mailing lists 14 Sep '10

14 Sep '10

Hello, I think that the pwdAttribute needs an OID value (specified by the syntax) so you would must use the OID of the userPassword attribute which is 2.5.4.35

3 2

Keep alive functionality when the remote closes the conenction due idle
by alin vasile 13 Sep '10

13 Sep '10

Hi guys, I have a question related to the open ldap client keep alive functionality. Our OS is SLES 11. In our client code we are reusing the ldap connections between requests uning a connection pool. For each conenction we are setting the keep-alive options (LDAP_OPT_X_KEEPALIVE_IDLE, LDAP_OPT_X_KEEPALIVE_PROBES and LDAP_OPT_X_KEEPALIVE_INTERVAL) and this works fine. My question is how the openl ldap library (libldap and libldap_r) handles the situation when the number of kee-alive probes for a connection is exceeded and the connection is closed at the server side. Did you dealt with this situation? Thanks, Alin

4 5

syncrepl incomplete database problem
by Islam Amer 13 Sep '10

13 Sep '10

Hello everyone, I have a problem with a simple master/slave syncrepl replication setup. Everytime I restart the slave it goes back to an empty state and then syncs about only 200 entries from thousands in the master. >From then on it gets the update events from the master fine. I have tried some of the things suggested in this mailing list but none have worked so far. For example I tried initializing the slave with a full slapcat of the master after deleting all files from /var/lib/ldap/ , but when I start the slave it deletes ALL entries and starts over. The master is debian etch with 2.3.30-5+etch2 ( critical, not easy to update ) The slave is 2.3.43 RHEL The slave config is : syncrepl rid=100 provider=ldaps://xxxxxxxxxxxxxx:636 type=refreshOnly tls_cert=/var/lib/ldap/ssl/clientcert.pem tls_key=/var/lib/ldap/ssl/clientkey.pem tls_cacert=/var/lib/ldap/ssl/cacert.pem interval=00:00:01:00 retry="5 60" searchbase="dc=xxxx" filter="(objectClass=*)" scope=sub schemachecking=off bindmethod=simple binddn="cn=xxxxx,dc=xxxx" credentials=xxxxxx slapd is started with options "-c rid=100,csn=0" ( the real values are obscured for security, sorry ) I switched to refreshOnly because the connection passes through a strict firewall, and I read that the persistent connection of refreshAndPersist has problems with that. Any help is appreciated. Thanks.

1 0

Re: invalid syntax on pwdPolicy object add
by Julien Vehent 13 Sep '10

13 Sep '10

On Mon, 13 Sep 2010 19:29:12 +0530, Kiran Ayyagari <kayyagari(a)apache.org> wrote: > On Mon, Sep 13, 2010 at 5:07 PM, Julien Vehent <julien(a)linuxwall.info> wrote: >> >> >> >> # slapd -V >> @(#) $OpenLDAP: slapd 2.4.23 (Aug 26 2010 18:33:04) $ >> root@monster:/tmp/buildd/openldap-2.4.23/debian/build/servers/slapd >> >> >> It's not a space/tab problem, and I've tried to put the request in an ldif file and insert it, with the same result. >> It's definitely a constraint that's not satisfied... but which one ?? > > think it is reproducible cause I have got the same error when I > followed the above steps > 'error code 21 - pwdAttribute: value #0 invalid per syntax' > > I have built OpenLDAP version 2.4.23 on Ubuntu 9.04 with berkeley db > version 4.7.25 > > Kiran Ayyagari > Alright, so it's either my steps that are wrong, or a problem with slapd. I'll be humble and suppose that my configuration is wrong first. Any hint on what I could have missed ? described here: http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:openldap:openlda… Julien

2 1

Logging practices of OpenLDAP
by Mark John Rank 13 Sep '10

13 Sep '10

List: UW-Milwaukee is in the process of reviewing IAM infrastructure and looking to harmonize logging, audit and data retention configuration for many of our IAM related services. Our OpenLDAP service is in scope for this review. To help frame the review, I am looking for guidance or best practices for configuring logging for OpenLDAP, especially for the HigherEd community. Of particular interest is the decision process around balancing log level, performance overhead and data retention. A search of the archives didn't result in much so I though I would just ask the question of the list. If individuals are interested in sharing, they can reply to the list or they can contact me directly at the address below. Regards, Mark ------------------------------------------ Mark Rank, Middleware Architect University Information Technology Services UW-Milwaukee Email: rankm(a)uwm.edu Phn: 414-229-3706 ------------------------------------------

1 0

Confused about password authentication formats
by 1.41421＠gmail.com 12 Sep '10

12 Sep '10

I have an OpenLDAP 2.4.23 server up and running in a Linux box L against which I can carry out password authentication on behalf of users logging into an embedded system E. To accomplish this, in LI have an LDIF file with entries along the following lines: dn: uid=xxx,ou=yyy,dc=zzz,dc=com uid: xxx cn: xxx objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword: ThisIsthePassword shadowLastChange: 14014 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1003 gidNumber: 1003 homeDirectory: /home/xxx gecos: ,,, I would like to change this so that, when sending password information from my LDAP client in E to the LDAP server in L, the password itself is never sent in the clear. So I thought to change the value of the userPassword attribute to read {SHA}3DRF4FXpG8r+Ki8i8azuZh7KwO8= instead, where the string above was obtained by means of slappasswd -v -s ThisIsthePassword -h "{SHA}" in L. After restarting the LDAP server in L, when user xxx logs into E with password "ThisIsthePassword" I can verify in the traces of the LDAP server (I am running it as slapd -d 255) that the client in E is sending the "3DRF4FXpG8r+Ki8i8azuZh7KwO8=" string, exactly as specified in the value of the userPassword attribute. However, the authentication is failing. What is it exactly that the LDAP client in L is supposed to be sending to the LDAP server in this case? I noticed that if the client sends the actual "ThisIsthePassword" string instead the authentication also fails. I am obviously missing something here but, what is it?

2 2

Re: objectClass index from slapd.conf is not working
by tim stone 10 Sep '10

10 Sep '10

> The very first time you start slapd, I always expect searches to be slow, as > it has to load up the dncache, entrycache, and idlcache. If you are only > seeing this slowness the first time the search executes after slapd is > started, then this is normal behavior. No, as I said, it takes always a long(er) time. It seems to me, that the index for objectClass returns too much entires?! If I search for an other indexed attribute in the same container (exist in this container also only one time), then the index returned the matched entity in only 0,05 sec (used command time for measuring). See my first posting. Only for the index objectClass I see this strange behavior. The index should return only one Candidate, if there is only one entry that match in this searchBase? kindly regards, Tim

1 0

Re: objectClass index from slapd.conf is not working
by tim stone 10 Sep '10

10 Sep '10

>> >> I tried to increase the cachesize and idlcachesize to 100000 and >> restarted the slapd, but it did not help. > > If you are using back-hdb, and using a subtree as the base (which it looked > like you were doing), the first time through the search will be very slow > while the cache is filled. That's a long-standing issue with back-hdb. > Subsequent searches are substantially faster. > Thanks, but I use bdb as backend (see config). Due more investigation today I find out, that if I use cachsize and idlcachsize about 500000 the second response (after first search) is quite faster, because now the entries are cached. But by configuring an index for objectClass it should avoid for searching all the entries? This Configuration is not applicable at the moment, because my Linux is 32bit (PAE) and the cachesize for the bdb-index is 1GByte. Slapd is using about 2Gby of RAM at the moment. But if I could increase the RAM, the problem of the index still exist. In one of my DN (Container) are 88000 entires. I placed my search there (searchBase) Only the Container itself has the searched objectClass, but all entires in this container will be examined too. Should the index for objectClass not only give back this _one_ (and not 355545) Candidate, or do I misunderstood this? ================================================== Sep 1 14:02:52 LDAP01 slapd[17856]: => bdb_equality_candidates (objectClass) Sep 1 14:02:52 LDAP01 slapd[17856]: => key_read Sep 1 14:02:52 LDAP01 slapd[17856]: <= bdb_index_read 355545 candidates ================================================== Thanks Tim

2 1

GSSAPI Bind across trusted realms
by Indexer 09 Sep '10

09 Sep '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have REALM.A and REALM.B in my KDC setup. There is a two way trust between REALM.A and REALM.B. I have a client computer on REALM.A, and can correctly kinit to get tickets from both realms via this trust pathway. I also have an OpenLDAP server on the server with REALM.B, and it is identified by ldap/ldap.realm.b(a)REALM.B When i obtain a ticket on REALM.A via this , and try to execute a SASL bind to the ldap server, i get an error of SASL/GSSAPI authentication started ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) It says that Minor code may provide more information (Server ldap/ldap.realm.b(a)REALM.B not found in Kerberos database). A user from REALM.B can access the LDAP server correctly with GSSAPI klist shows that i am getting a TGT for both REALM.A and REALM.B on my user(a)REALM.A. Is this an issue with kerberos being unable to find the ticket across the realm trust for ldap to be verified? What steps can i follow to help fix this issue? Are there principal flags that i am forgetting to add to my LDAP principal for this to work? Your help is appreciated. William Brown pgp.mit.edu -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iQIcBAEBAgAGBQJMiF0cAAoJEHF16AnLoz6J6mIP/0Jnfw8vG13LyOlv2gm3zwrF psHWASKmzaPngS0c7nbNSDDWi6jZJXogP9kF8uI/JQibUlYJb9TtfiG1K7l6yMol /jD8l3TGVy/VBrG6Yk0sqiQeHn52IaPTXv/xk0a8o6rk/wAUFzEnXH3+K/oRg+4A +Z5WHWHsdz73QBkMRVE+IY+IHwUB+GoglyocZmnQBjigU+2+So2hhlxp8XqmZPSZ jke2yk375LXHgv8/cppIIx3YV5VtvMe/O/lQoptBl39D8Y7CFwJsuQqGtyTRQVJh PpnMDARhqR+UKqJeZRksQLUeFZhQYzLWpTStm/8NhYAVBhTF32NPwgkcv5LohUdH yK3TCjvPodXCs27kGFX2s20tpFjLfpnx+gzyCTRQbbygPR4/Nn+11kmqDlrC05fW GpUOA8aknL7J6tN5twlO/wHtIaIvTPP4MmDD9DlS6OtNbBtaumDrS6ehWQ0j4FlA IfK+eHwIRgvjxCGa7N9S7jv5ZqxkAyeVArWWJczcCL6qKij7Zgh0w8nvzMTJq1Jj TwYK9O8RHL0d66NSFs2sTaEUZECnYA29oh6XppmvaOUdI5JOzQ4keG6xhTieRPBx Tdkq/1B51nl6EfJTu4fLOKfRz2UnOY2Uvms+2qdH0cZZIhOu98I3BsSdKhUgPtAB kZoLSAwYj33BL/KU/8Yj =RZcN -----END PGP SIGNATURE-----

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical