openldap-software June 2009

openldap-software@openldap.org

22 participants
27 discussions

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

Re: solaris compile options
by Brett ＠Google 24 Jan '10

24 Jan '10

i am using CFLAGS="-fast -xtarget=ultraT1 -xarch=sparcvis2 -xcode=pic32 -g -xs -O" one set of solaris docs i read implied that -xarch=sparcvis2 was equivalent to -xarch=v9 (which used to trigger 64 bit), but looking at the sun studio 12 compiler options, the more specific versions of -xarch (ie. other than -xarch=v9 or v9a or v9b) may no longer imply that the 64 bit memory model should be used. so maybe i need to add a -m64 to the above ? (compiling on a Sun T2000, with a homegenous build / execute environment, so favouring speed over cpu compatibility is ok) On Thu, Mar 12, 2009 at 1:31 AM, Aaron Richton <richton(a)nbcs.rutgers.edu>wrote: > On Wed, 11 Mar 2009, Brett @Google wrote: > > /data/openldap/backups/ldap_090302.ldif: Value too large for defined data >> type >> > > man lfcompile, and/or switch to 64-bit binaries? >

2 3

password policy - alternate lockout mechanism
by Aravind Gottipati 17 Jul '09

17 Jul '09

Hi, The current password policy module can lock folks out after some configurable number of failed attempts. The module currently does not differentiate between a user failing with the same wrong password a bunch of times versus a crack attempt where someone tries multiple different wrong passwords. Are there any modules that take into account if the same password is being used a bunch of times or if multiple different passwords are failing? Could this be a useful feature worth requesting (if it doesn't exist already)? Thank you, Aravind.

6 24

Supported RFC's and "features"
by Clowser, Jeff (Contractor) 13 Jul '09

13 Jul '09

I'm currently doing a review to see how OpenLDAP compares, *feature wise* ATM, to other directory servers and specifically to the Sun DS - i.e. to get a definitive list of features it's missing that Sun has and what it has that Sun doesn't have, etc. For brevity, I haven't included all the potentially useful features of OpenLDAP, but have just focused on those associated with 1) RFC compliance (of which Sun may or may not meet) and 2) features to match the Sun DS (which it would be replacing). So far, here's what I have for OpenLDAP: RFC 4510 (which includes 4511-4519). There was recent discussion on the list around this, such that in some cases, not everything that changed from 3377 (which includes 2251-2256, 2829, and 2830) to 4510 has been updated in OpenLDAP, but I think those issues are fairly minor. The following additional RFC's are supported in OpenLDAP: - RFC 2247 and RFC 3088 - RFC 2696 simple paged results - RFC 2849 ldif - RFC 3062 password mod op - RFC 3296 named referals, manageDSAit - RFC 3673 All Op attrs + feature - RFC 3687 Component matching rules - RFC 3866 Languange tag and range - RFC 3876 matched values control - RFC 4370 proxy auth - RFC 4522 binary encoding - RFC 4523 x.509 cert schema - RFC 4524 COSINE schema - RFC 4525 Mod-increment - RFC 4526 Absolute true/false filters - RFC 4527 pre/post read control - RFC 4528 assertion control - RFC 4529 request attrs by objectclass - RFC 4530 entryUUID - RFC 4532 whoamI - RFC 4533 Content Sync op (replication) RFC's NOT supported are: - RFC 2589 dds Seems with 2.4, this has gone from experimental to production quality? - RFC 2891 server side sorting - RFC 3671 collective attributes - RFC 3928 LCUP mainly for updating cached addressbooks, etc - not replication between servers - RFC 3384 looks like just reqs for replication, not an actual replication protocol - RFC 4533 is used instead Unknown: - RFC 3672 (subentries) - RFC 3698 and 3727 (additional matching rules) - RFC 3909 LDAP Cancel operation - RFC 5020 entryDN operational attribute (There are some other, often obscure, LDAP related RFC's that I didn't include, but this seems to be the major/useful ones) Other features not supported: - VLV browse indexes (per http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09). Not an RFC, but supported by Sun and MS directories, and used by things like Outlook and Solaris. Other supported features: - dyngroup/dynlist/memberof overlay (A much more useful feature than Sun's groupOfURLs "dynamic" group and "roles" mechanism) - ppolicy overlay (matches Sun DS 5.x reasonably close, but is account lockout replicated to all servers? Sun DS 6.x claims to) - refint overlay (similar to Sun's referential integrity plugin) - unique overlay (similar to Sun's uniqueness plugin) - audit and accesslog overlays, syslog logging - much more useful/complete than Sun's access/audit/error logs. - live acl changes via LDAP Unknown features: - Per user resource limits (sizelimit, timelimit, idletimeout, etc). I think Howard Chu said OpenLDAP has some of this, but I haven't seen any reference to it or how to use it in the docs (does this functionality exist, and if so, is there any documentation?) - Tracking of last login (i.e. last successful ldap authentication) Is this still fairly accurate? The ones that are really problematic are the lack of: - VLV Browse indexes - RFC 2891 (server side sorting) - per user/entry resources limits (if they don't exist) Are there any unofficial updates/patches/overlays/plans for any of this functionality? Thanks, - Jeff

11 29

mirror mode replication
by Brett ＠Google 09 Jul '09

09 Jul '09

Hello, I am having two problems one i think an issue with mirrormode replication, and two i think the docs might be are wrong for mirrormode. The openldap admin quide states : MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on MirrorMode node 2: # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on I have configured something like this, and it does an initial syncronise, but subsquent writes to "node 1" are not replicated to node 2. Eg. changes to data use "ldap.example.com" LDAP are always made to node 1 (ldap://ldap-sid1.example.com), and only to node 2 (ldap://ldap-sid2.example.com) if node 1 is unavailable (via a content switch). When a change happens via node 1, i get : Node 1 (seems to be correct): Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 939789 local4.debug] syncprov_sendresp: to=002, cookie=rid=001,sid=001,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 905511 local4.debug] do_syncrep2: cookie=rid=001,sid=002,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 977386 local4.debug] syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 565591 local4.debug] syncrepl_entry: rid=001 be_search (0) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 709484 local4.debug] syncrepl_entry: rid=001 mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 819441 local4.debug] syncrepl_entry: rid=001 entry unchanged, ignored (mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com) Jun 18 10:42:46 qgmlr01 slapd[492]: [ID 784563 local4.debug] syncprov_matchops: skipping relayed sid 002 Node 2 (indicates a problem maybe): Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 905511 local4.debug] do_syncrep2: cookie=rid=001,sid=001,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 977386 local4.debug] syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 565591 local4.debug] syncrepl_entry: rid=001 be_search (0) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 709484 local4.debug] syncrepl_entry: rid=001 mail=user(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 824931 local4.debug] syncprov_matchops: skipping original sid 001 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 939789 local4.debug] syncprov_sendresp: to=001, cookie=rid=001,sid=002,csn=20090618004246.225914Z#000000#001#000000 Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 933660 local4.debug] syncrepl_entry: rid=001 be_modify mail=sitescop(a)popmail.example.com,jvd=popmail.example.com,o=hosting,dc=example,dc=com (0) Jun 18 10:42:46 qgmlr02 slapd[12018]: [ID 824931 local4.debug] syncprov_matchops: skipping original sid 001 I'm presuming it is wrong (correct me if i am wrong) as the second change change from node 2 is coming in, using the same sid as node 1, hence "skipping original sid 001" In previous example configs, each mirrormode node has had two rid's, 001 for "node 1" and 002 for "node 2" so the protocol can tell which node made the change, one node should accept the change as it came from the other node, the other should reject it as it came from itself. FYI, The previous example was something like below (eg. node 1, same for node 2 but with "serverID 2") : # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" syncrepl rid=002 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on Is this still required ? I thought mirrormode meant any node may be updated, but typically always the same one (unless one fails). Cheers Brett

2 1

ldif.h
by Eric Nichols 02 Jul '09

02 Jul '09

I've spent the past few days rooting around the openldap site. I am developing currently on Debian lenny using the libldap2-dev package. My small goal is to try and write my own rootdse program to better understand the lib. I am stuck on one piece of code. I have no idea where to get an LDIF library to parse/write ldif files. Can anyone point me in the right direction on this? It's been a long time since I was coding in C and it took me a while just to gather that I needed -lldap to make what I have work. I believe this is the only piece I'm missing, the LDAP library calls work flawlessly. I also did learn that many of the depreciated functions are still documented as valid functions (ldap_get_values, ldap_count_values, ldap_value_free). I couldn't find anything that replaced these.. Many thanks Eric

3 3

Delta-Sync w/ TLS troubles
by Peter Clark 01 Jul '09

01 Jul '09

Hello, I have a FreeBSD 7.2 Release box with openldap-2.4.16 installed on it. I have followed the Admin guide to setting up Delta-Sync replication and it works as long as I do not use either the "ldaps" or "starttls=yes" on the slave. ie: syncrepl rid=0 provider=ldap://joe.pdq.edu starttls=yes bindmethod=simple binddn="cn=ldaproot,dc=pdq,dc=edu" credentials="XXXXXXXXX" searchbase="dc=pdq,dc=edu" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog or syncrepl rid=0 provider=ldaps://joe.pdq.edu bindmethod=simple binddn="cn=ldaproot,dc=mtmary,dc=edu" credentials="XXXXXXXX" searchbase="dc=pdq,dc=edu" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog I have set my loglevel to -1 on both boxes and the only thing that shows up in the logs referring to tls is: (Master server) slapd[9572]: conn=1 op=0 EXT oid=1.3.6.1.4.1.1466.20037 slapd[9572]: do_extended: oid=1.3.6.1.4.1.1466.20037 slapd[9572]: conn=1 op=0 STARTTLS slapd[9572]: send_ldap_extended: err=0 oid= len=0 slapd[9572]: send_ldap_response: msgid=1 tag=120 err=0 slapd[9572]: conn=1 op=0 RESULT oid= err=0 text= slapd[9572]: daemon: activity on 1 descriptor slapd[9572]: connection_read(16): checking for input on id=1 slapd[9572]: connection_read(16): TLS accept failure error=-1 id=1, closing slapd[9572]: connection_closing: readying conn=1 sd=16 for close slapd[9572]: connection_close: conn=1 sd=16 slapd[9572]: daemon: removing 16 slapd[9572]: conn=1 fd=16 closed (TLS negotiation failure) (Slave Server) slapd[10846]: =>do_syncrepl rid=000 slapd[10846]: daemon: activity on 1 descriptor slapd[10846]: daemon: waked slapd[10846]: daemon: select: listen=6 active_threads=0 tvp=zero lapd[10846]: daemon: select: listen=7 active_threads=0 tvp=zero slapd[10846]: daemon: select: listen=8 active_threads=0 tvp=zero slapd[10846]: daemon: select: listen=9 active_threads=0 tvp=zero slapd[10846]: slap_client_connect: URI=ldap://joe.pdq.edu Warning, ldap_start_tls failed (-11) slapd[10846]: slap_client_connect: URI=ldap://joe.pdq.edu DN="cn=ldaproot,dc=pdq,dc=edu" ldap_sasl_bind_s failed (-1) Is there some way to see what exactly is failing between the units? I have tried the credentials line with quotes around the password and without. I have made sure the provider= the fqdn of the master. Any help would be appreciated. Peter.

3 3

Multimaster question
by Clowser, Jeff 24 Jun '09

24 Jun '09

I want to set up a cluster of ldap servers. In that cluster, I want: - One primary supplier server - One hot standby supplier server - N read only consumer replicas. - a load balancer that directs all writes to the primary master if it's up, or the standby if it's down. However, I want operational attributes like password policy attributes to be replicated across the cluster. My understanding is that if I set up two suppliers and N consumers, operational attribute changes (such as password policy attrs) on the consumers will not replicate across the cluster. I was thinking that to resolve this, I should instead set up as follows: - All servers are "master" supplier servers (N+2 way multi-master). - On designated primary and hot standby suppliers, create all my read/write aci's. - On all the other servers (the N consumers), define only non-write aci's. - a load balancer that directs all writes to the primary "master" if it's up, or the standby if it's down. My thinking is that this would allow all the servers to exchange operational attribute changes (i.e. password policy, etc), but limit writes from external clients to the designated "master" servers. Would this work as I am thinking? Any caveats? Or am I completely missing something important that will invalidate this idea? Thanks, - Jeff

3 4

Configure openldap with fetch on Debian
by Sven Schöppner 24 Jun '09

24 Jun '09

Hi list, i attempt the fist time to configure openldap with fetch support. It seems to me Debian do not support fetch as packet. Can anyone help? I know it's a Diabian question mayby onyone here has a solution. Sven checking fetch(3) library... no configure: error: no suitable API for --with-fetch=yes -- Department of Biotechnology and Molecular Genetics University of Bremen, FB2-UFT Gebäude UFT (Room 1570) Leobener Strasse 28359 Bremen Germany Phone: +49 (0) 421 218-63421 eMail: schoeppner(a)biotec.uni-bremen.de

2 1

N-Way Replication works first time only
by Calos Lopez 23 Jun '09

23 Jun '09

Hi there again, I'm running OpenLDAP 2.4.11. I followed the 18.3.3. N-Way Multi-Master on the http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master documentation. I setup only two servers. When I run the new configuration on the first change in one server is replicated to the other server. After that all changes that I made are not replicated. What can be causing this problem? Here is the configuration that I used for cn=config: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://192.168.139.10 olcServerID: 2 ldap://192.168.139.11 dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://192.168.139.10 binddn="cn=admin,cn=config" bindmethod=simple credentials="ii" searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +" timeout=1 olcSyncRepl: rid=002 provider=ldap://192.168.139.11 binddn="cn=admin,cn=config" bindmethod=simple credentials="ii" searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE And the configuration for bdb database dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcRootDN olcRootDN: cn=admin,dc=arquis,dc=local - add: olcSyncRepl olcSyncRepl: rid=003 provider=ldap://192.168.139.10 binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly interval=00:00:00:10 retry="5 10 10 +" timeout=1 olcSyncRepl: rid=004 provider=ldap://192.168.139.11 binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly interval=00:00:00:10 retry="5 10 10 +" timeout=1 - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov Here is some output debug: root@ubuntu:~# /usr/sbin/slapd -d 16384 @(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $ buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd slapd starting do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE That's equal to the output of the 2nd server: root@ubuntu:~# /usr/sbin/slapd -d 16384 @(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $ buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd slapd starting do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT Thanks in advances

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software June 2009