openldap-software February 2010

openldap-software@openldap.org

30 participants
22 discussions

dynlist: unable to fetch objectClass "groupOfURLs"
by Adam Tauno Williams 10 Feb '10

10 Feb '10

Playing on my test server with dynlist, trying to set it up via cn=config. I issue - awilliam@linux-m3mt:~> ldapadd -x -h 172.16.55.129 -D 'cn=Adam Williams,ou=People,ou=Entities,ou=SAM,o=Morrison Industries,c=US' -W -f dynlist.ldif Enter LDAP Password: where dynlist.ldif is - dn: olcOverlay=dynlist,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: dynlist - and it fails with error - adding new entry "olcOverlay=dynlist,olcDatabase={1}hdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: unable to fetch objectClass "groupOfURLs" - and slapd crashes at the next operation. Anyone recognize that one or know how to work around? Am I somehow missing the "groupOfURLs" schema? If I dump my cn=SubSchema I don't see a reference to "groupOfURLs". Version: Telkomsa openldap2.4-2.4.20-1.el5

3 2

Failure to delete entry with multi-master replication
by Kyle Blaney 10 Feb '10

10 Feb '10

I have encountered a situation with multi-master replication in OpenLDAP 2.4.21 where an entry deleted on one server is not deleted from its peer. I'm using Redhat Enterprise Linux 5. Here's what I did: 1. Configure Network Time Protocol with server A as the NTP master and server B as the NTP slave. 2. Configure multi-master replication between server A (server ID=1) and server B (server ID=2). 3. Start OpenLDAP service on servers A and B. 4. Add an entry to server A and ensure it's replicated to server B. 5. Add an entry to server B and ensure it's replicated to server A. 6. Stop OpenLDAP service on server A. 7. Delete an entry on server B. 8. Start OpenLDAP service on server A with sync debugging enabled (-d sync). At this point, I expected that the entry deleted from server B would be deleted from server A. Instead, the entry remained on server A and slapd displayed the following (with the entry's DN X'ed out): slapd starting do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Entry XXXXXX CSN 20100209193028.621799Z#000000#001#000000 older or equal to ctx 20100209193028.621799Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20100202210831.101462Z#000000#000#000000;2010 0209193028.621799Z#000000#001#000000;20100209193118.342038Z#000000#002#0 00000 Why wouldn't the entry deleted on server B also deleted from server A? Is the failure to delete the entry related to the "entry CSN older or equal to context CSN" message? Unfortunately, I have been unable to reproduce the failure since I first saw it. All subsequent tests have shown that the entry deleted from server B is deleted from server A when the OpenLDAP service on server A is restarted. Kyle Blaney

1 0

opeldap back-sql oracle with password-hash MD5 enabled
by Nikethan Nagula Raja 10 Feb '10

10 Feb '10

All, We are implementing openldap using oralce as backend and every thing is up and running fine with out any issues. Now we have an additional requirement to hash the cleartext passwords in oracle database for ldap users. Now instead of storing cleartext passwords, I'm storing passwords in the same database column but prefix of the schema in braces and MD5 hash value. Lets say if we have a user - jsmith with password 123456 I would store the {MD5}e10adc3949ba59abbe56e057f20f883e in the database column (userPassword). But for some reason I was able to bind with admin creds, but the authentication fails with err=49 I can send detailed openldap logs if required. Thanks, Nikethan Nagula Raja

2 2

searching for attributes without index in 2.4.19 with bdb 4.5
by Christoph Herrmann 09 Feb '10

09 Feb '10

Hello, after upgrading from openldap-2.3.39 with bdb-4.2.52 to openldap 2.4.19 with bdb-4.5 searching for attributes without index is about three times slower. (same machine, same data, all data fit in DB cache) Are there any known problems or magic tuning options we have missed? regards Christoph &:-) -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Michel Lepert Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196

1 1

Strange ssl certificate checking issue
by Guillaume Rousse 08 Feb '10

08 Feb '10

Hello list. That's not really an openldap issue, but I guess its developper knows openssl behaviour better then myself: how could a simple distribution-provided update of root certificates affect the way openldap uses my own root certificate ? Before the update, the root certificate is correctly read from /etc/pki/tls/rootcerts, as per openldap configuration (TLS_CACERTDIR variable). After the update, the root certificate is still read, but ignored, then looked for again in /etc/pki/tls/certs, triggering a failure if not also present/symlinked from there. The only file change affecting the tool between the two scenarios, according to strace, is /etc/pki/tls/cert.pem, which doesn't contains anything useful in my case. May a syntax error, or a too large size, triggers side-effects ? Full traces available at https://qa.mandriva.com/show_bug.cgi?id=57512 -- BOFH excuse #61: not approved by the FCC

1 0

simple bind with external Kerberos V password store
by Tim Mooney 05 Feb '10

05 Feb '10

All- I'm interested in what the state of Kerberos (external) password storage scheme is, as mentioned in the Admin Guide, section 14.4.7. We're currently using openldap 2.3.mumble (it's old) and will be upgrading to 2.4.21 or later soon, on RHEL 5.x. We don't currently do user or application authentication to our OpenLDAP. Because of the number of applications we're seeing that support "ldap authentication" but don't have any way to do true or even fake Kerberos V authentication, I've been asked to determine what would be involved in allowing ldap authentication, but having slapd use our MIT krb5 infrastructure behind the scenes. Section 14.4.7 of the admin guide seems to indicate that OpenLDAP can already do exactly what we need, but no additional details are provided. Searching the openldap-software archives, Kurt Zeilenga provides a bit more info on how I might go about configuring this here: http://www.openldap.org/lists/openldap-software/200010/msg00462.html grep'ing the source for '{KERBEROS}', the only place that shows up is in contrib/slapd-modules/passwd/kerberos.c. Can anyone shed any more light on what state this is in? Kurt's 9 year old post and the current admin guide seem to imply that using an external kerberos password store for userPasswords is a standard part of OpenLDAP, but the source seems to imply otherwise. If the {KERBEROS}princ@REALM method works and isn't completely deprecated I would choose that route, otherwise I suppose I'll have to investigate SASL as described in section 14.4.6 and 14.5 of the admin guide. I understand the warning at the end of the section in the admin guide, that using a krb5 KDC as a fancy network-based password checking database is not Kerberos at all, and that if we go this route we'll want to make certain that at a minimum binds are done over TLS. Thanks, Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

4 3

slapadd hung during converting from slapd.conf to cn=config
by Steven Truong 04 Feb '10

04 Feb '10

This happened on my Centos 5 KVM host on Intel and my VM machines are Centos 5 x64/Ubuntu 9.10 i386. On Centos 5 vm, I installed from source openldap 2.4.21 and on Ubuntu I installed openldap from Ubuntu software repository. I first tried my installation on Ubuntu and got stucked, then I tried the one on Centos 5 and got stucked with exactly same strace outputs. I experienced similar hangs on both and found data in /var/lib/ldap but nothing else in my slapd.d directory on both vm instances. slapadd -v -q -f slapd.conf -F slapd.d ..... gettimeofday({1265234787, 777676}, NULL) = 0 open("/dev/urandom", O_RDONLY) = 6 fcntl(6, F_GETFD) = 0 fcntl(6, F_SETFD, FD_CLOEXEC) = 0 getuid() = 0 getppid() = 26516 gettimeofday({1265234787, 781981}, NULL) = 0 gettimeofday({1265234787, 782533}, NULL) = 0 read(6, "g#\3\232\366\1I\255\17\202\270\274\367\230n\221", 16) = 16 gettid() = 26517 write(2, "hdb_monitor_db_open: monitoring "..., 79hdb_monitor_db_open: monitoring disabled; configure monitor database to enable ) = 79 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0) = 0x407c1000 mprotect(0x407c1000, 4096, PROT_NONE) = 0 clone(Process 26518 attached child_stack=0x40fc11d0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40fc19d0, tls=0x40fc1940, child_tidptr=0x40fc19d0) = 26518 [pid 26517] fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 [pid 26517] fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 [pid 26517] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaab000 [pid 26517] read(0, <unfinished ...> [pid 26518] set_robust_list(0x40fc19e0, 0x18) = 0 [pid 26518] futex(0x2acb21450744, FUTEX_WAIT_PRIVATE, 1, NULL I ran the same command on Ubuntu this time I got the following but in other runs I got the same strace output with the Centos's strace output. gettimeofday({1265234943, 880676}, NULL) = 0 open("/etc/localtime", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa2e7e000 read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"..., 4096) = 2819 _llseek(7, -24, [2795], SEEK_CUR) = 0 read(7, "\nPST8PDT,M3.2.0,M11.1.0\n", 4096) = 24 close(7) = 0 munmap(0xa2e7e000, 4096) = 0 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 7 read(7, "\2\343", 2) = 2 close(7) = 0 gettimeofday({1265234943, 883682}, NULL) = 0 open("/dev/urandom", O_RDONLY|O_LARGEFILE) = 7 read(7, "\235i\375\366\377~", 6) = 6 close(7) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xa2e7e000 read(0, I am wondering if there are some problems with KVM that prevent this operation to carry out successfully. Thank you very much.

3 2

Re: Question about contextCSN's
by Ryan Steele 04 Feb '10

04 Feb '10

Rein Tollevik wrote: > Ryan Steele wrote: >> I'm replicating both the config and backend databases between two >> boxes. Everything seems fine, but for some reason >> when I query them both for the contextCSN, the config database returns >> only one while the backend database returns two, >> as seen below: > > The contextCSN attribute with any given sid is added to a database only > after the server with that serverID modifies the database. The count of > contextCSN values in a database does not need to reflect the number of > master servers that could modify it, and it have no relation to the > values in other databases. > > In your example, all modifications to cn=config was probably made on the > first server (assuming it have serverID 1 that is). The example db have > been modified by both. > > Rein Thanks a lot for clarifying; I didn't realize that the contextCSN for each SID was added to a given database only after being modified by that SID. And yes, I do understand that the different databases (e.g., backend and config) will have different contextCSN's reflecting the last time they were written to, but my question was mostly about the same database on different nodes. Namely, I thought that verifying whether replication was complete was done by comparing the contextCSN's for the same database on each node (SID) in the replication group. That is, if replication is working, each server to whom the given database is being replicated should have the same contextCSN for that database, to verify that each received the same last write operation. I'm not quite sure how to interpret that though, given the results I'm seeing in my master-master pair. Should the contextCSN's in the backend database for both SID 001 and SID 002 match? E.g.: contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20100126210305.876171Z#000000#002#000000 Or should both nodes agree about the timestamps for each SID independently? E.g.: ### ldap1 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000 ### ldap2 contextCSN: 20100126210305.876171Z#000000#001#000000 contextCSN: 20091018205321.288716Z#000000#002#000000 It would intuitively seem to me that each node (SID) to whom the database is being replicated should have the same contextCSN, so that one could verify the replication status by looking at the attribute values for each SID on one node, instead of querying each node to see if the timestamp for each individual SID matched on every node. But, which is correct? Thanks again for the insight. Respectfully, Ryan

3 3

dynlist overlay and ldapsearch
by ben thielsen 03 Feb '10

03 Feb '10

hi- i'm using the dynlist overlay and am not getting back the search results i expected. i'm using 2.4.11 courtesy of debian. here is my overlay config: >ldapsearch -xWLLLD 'cn=admin,cn=config' -b 'cn=config' "(objectclass=olcdynamiclist)" dn: olcOverlay={5}dynlist,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {5}dynlist olcDLattrSet: {0}groupOfNames memberURL member olcDLattrSet: {1}mailGroup labeledURI here is the entry in question: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' -s base -b 'cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groundnoise,dc=net' dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net objectClass: mailGroup objectClass: top objectClass: extensibleObject cn: abuse member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail ,dc=groundnoise,dc=net labeledURI: ldap:///ou=domains,ou=mail,dc=groundnoise,dc=net?host?sub?(objectC lass=mailDomain) host: phone.dipswitch.net host: luna.mpls.mn.us host: groundnoise.net host: thielsen.org host: sjva1991.org host: dipswitch.net host: bitrate.net searched for another way: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))' host dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net host: phone.dipswitch.net host: luna.mpls.mn.us host: groundnoise.net host: thielsen.org host: sjva1991.org host: dipswitch.net host: bitrate.net however, the results from this search are missing that entry: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=dipswitch.net)' dn dn: host=dipswitch.net,ou=domains,ou=mail,dc=groundnoise,dc=net or another search: ldapsearch -xvWD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(host=*))' host ldap_initialize( <DEFAULT> ) Enter LDAP Password: filter: (&(objectclass=mailgroup)(host=*)) requesting: host # extended LDIF # # LDAPv3 # base <dc=groundnoise, dc=net> (default) with scope subtree # filter: (&(objectclass=mailgroup)(host=*)) # requesting: host # # search result search: 2 result: 0 Success # numResponses: 1 if i remove the labeledURI attribute and populate with static entries, things appear to work as expected: here's the entry: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(&(objectclass=mailgroup)(cn=abuse))' dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net objectClass: mailGroup objectClass: top objectClass: extensibleObject cn: abuse member: cn=postmaster,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail ,dc=groundnoise,dc=net host: foo host: bar host: com host: net host: org and a search: >ldapsearch -xWLLLD 'cn=admin,dc=groundnoise,dc=net' '(host=foo)' dn dn: cn=abuse,ou=distribution_groups,ou=all_domains,ou=domains,ou=mail,dc=groun dnoise,dc=net what am i doing wrong? thanks -ben

3 3

Can ldap backend strip paged result critial extension?
by Loving, Kent 03 Feb '10

03 Feb '10

I am trying to install an application that sets the paged result extension as critical in all its searches. I tried to connect this application to an existing LDAP server which does not support that extension and I get error=12, Critical extension is unavailable. I am not able to modify the settings of the application nor the existing LDAP server. I thought to try OpenLDAP as a proxy between the app and the existing server. I installed OpenLDAP 2.4 and added database of type ldap, with suffix and uri for the existing LDAP server. Searches work great using ldapsearch (data is retrieved from the existing server) but searches from the application still return error 12. Is there any way I can instruct the ldap backend to strip the paged result request to the existing server, yet still have the OpenLDAP proxy honor the app's request? Kent Loving

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software February 2010