openldap-software February 2009

openldap-software@openldap.org

48 participants
51 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

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

frequent slapd freeze with openldap 2.4.13
by Guillaume Rousse 16 Apr '09

16 Apr '09

Hello list. Since a recent upgrade 2.4.12 -> 2.4.13, I'm facing recurrent slapd hanging. On client side, ldapsearch requests receive this error: error.c:272: ldap_parse_result: Assertion `r != ((void *)0)' failed I'd expect in this case an automatic switch to slave server, but it doesn't work. Here is my ldap libraries configuration: BASE dc=msr-inria,dc=inria,dc=fr URI ldap://ldap1.msr-inria.inria.fr ldap://ldap2.msr-inria.inria.fr TLS_CACERTDIR /etc/pki/tls/certs TLS_REQCERT demand NETWORK_TIMEOUT 2 TIMEOUT 2 TIMELIMIT 2 On server side, slapd usually shows eating 100, 200 or 300% cpu, which make me think some specific repeated query trigger the issue, making the problem worse when several of them accumulates. strace on running slapd process shows it's waiting on a futex: [root@etoile main]# strace -p 2769 Process 2769 attached - interrupt to quit futex(0xb6bb4bd8, FUTEX_WAIT, 2774, NULL <unfinished ...> And gdb shows it waiting in __kernel_vsyscall (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d385c6 in pthread_join () from /lib/i686/libpthread.so.0 #2 0xb7f23d3f in ldap_pvt_thread_join () from /usr/lib/libldap_r-2.4.so.2 #3 0x0806e1b4 in slapd_daemon () #4 0x0805a507 in main () In both case, I think the lack of relevant information is caused by the multithreading nature of slapd, I don't know how to access the exact thread where the problem occurs. I already tried to regenerate indexes, without results. I dropped the base, and reconstructed it from latest backup, it made the problem temporarily disapear. I didn't found anything in the logs, even with debug level set to 'trace'. I'm using a bdb backend, with this configuration in slapd.conf: database bdb suffix "dc=msr-inria,dc=inria,dc=fr" rootdn "cn=root,dc=msr-inria,dc=inria,dc=fr" #rootpw root directory /var/lib/ldap/main cachesize 1000 idlcachesize 1000 checkpoint 256 5 And this one in DB_CONFIG: set_cachesize 0 1048576 0 set_lg_bsize 2097152 set_lg_max 10485760 set_flags DB_LOG_AUTOREMOVE The full slapd.conf is accessible at http://pastebin.mandriva.com/5801 db_stat -m output is accessible at http://pastebin.mandriva.com/5799 The main database itself is quite small, the ldiff backup is 1.4 only. I also have a log database for syncrepl purpose. I'm using openldap 2.4.13, with db 4.6.21, on mandriva linux 2008.1, 32 bits system. I'd be happy to provide additional informations if needed. -- Guillaume Rousse Service des Moyens Informatiques INRIA Saclay - Île-de-France Parc Orsay Université, 4 rue J. Monod 91893 Orsay Cedex France Tel: 01 69 35 69 62

5 8

delta-syncrepl missing changes
by Francis Swasey 20 Mar '09

20 Mar '09

I am running OpenLDAP 2.3.39 (locally built) on Red Hat Enterprise Linux 4 servers with several replicas. We use delta-syncrepl to keep the replicas in sync with the master server. We also use nagios and monitor the contextcsn value on the replica and alert if it gets too far out of sync with the master server. The issue we have now experienced a few times is that if there are a LOT of updates in the nightly batch update process, that not all of the updates make it to the replicas but the contextcsn stays in sync, so we see strange errors that eventually lead us to see that the replicas are not current even though they think they are. Is this a known issue? I haven't found a syslog entry on the server or the replicas that makes me think it is the flag of the root cause. I have downloaded and built the 2.3.43 release, having installed it on one replica. That replica is just as out of date this morning as the others -- so, if there was a solution between 2.3.39 and 2.3.43 -- it must have been on the provider side not the consumer side. Thanks for any insight. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

6 28

root-only configuration
by Peter Mogensen 11 Mar '09

11 Mar '09

Hi, With slapd.conf you had to be root on the host to reconfigure slapd. However, with cn=config anyone who can authenticate as rootdn for cn=config can reconfigure slapd. Is it in anyway possible to set up cn=config, so only root on the host can make changes? /Peter

4 4

New guy needs some help choosing an overlay
by Jonathan Knight 05 Mar '09

05 Mar '09

I'm a bit new to the openldap package - my experience really dates back to the X500 QUIPU days in the early 90's so while I understand the priciples, it's the details of the software package that are something of a mystery. We're implementing LDAP for a variety of applications and we're going to use boolean attributes in the schema to determine whether a service should be enabled or disabled for a particular user. So, for example, we have an attribute of "kdiremail" which is true if the user is allowed to use the email service and false if their not. This works well with tools like dovecot because we can set up the search filter to only authenticate users who have that attribute set to true. However, some applications are born into an Active Directory world where such things seem to be unknown. I'm battling the Blackboard WebCT Vista product which allows me to specify attributes to look up for the username, but does not allow me to specifically define the search filter. My plan is to use the rewrite/remap overlay to create a fake hierarchy within our exisiting DIT where the search filter values are re-written to include a check to see if kdirvle is true. So then any searches on that DN will only return users who are allowed to use the VLE, I can then point our WebCT service to that basedn. I think this overlay will do the job I want, but I can see that there are many overlays in the openldap package and I wanted to check with someone more experienced that I am that the rewrite/remap overlay is the right choice for this kind of job. Jon.

3 5

Single-master replication over TLS fails in 2.4.15
by Craig Worgan 28 Feb '09

28 Feb '09

Hi, I am trying to upgrade from 2.3.42 to 2.4.15 and my setup uses single-master replication over TLS. When I do the upgrade I have noticed that replication fails. I have reproduced the problem in my lab, using a single server and multiple slapd instances, and I get the following error on the slave: [root@otm-hp11 cnd]# ./slapd -f slapdSlave.conf -d sync -h "ldap://47.11.48.221:20389 ldaps://47.11.48.221:20636" @(#) $OpenLDAP: slapd 2.4.15 (Feb 25 2009 22:27:30) $ worganc@otm-hp11:/home/worganc/openldap_build/openldap-2.4.15/servers/sl apd bdb_db_open: warning - no DB_CONFIG file found in directory /opt/nortel/cnd/slave-data: (2). Expect poor performance for suffix "dc=Nortel,dc=com". slapd starting TLS certificate verification: Error, self signed certificate in certificate chain TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed. slap_client_connect: URI=ldaps://47.11.48.221:10636 DN="cn=replicationagent,ou=replication,dc=nortel,dc=com" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=983 retrying (4 retries left) The corresponding trace on the master is: TLS: can't accept: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca. Based on the error messages, I thought that there was a problem with the certificates I am using, but when I revert the slapd executable to the old 2.3.42 version, replication succeeds. Were more stringent CA checks added between 2.3.42 and 2.4.15? Note that the same OpenSSL version was used to build both slapd executables (0.9.8b). Also, the same configuration options were used to build both versions. Cheers, Craig

5 11

accesslog crashes server
by Pete Giesin 27 Feb '09

27 Feb '09

I am trying to configure OpenLDAP 2.4.13 on Red Hat 5.2. I have ran into this strange scenario that crashes the sever and corrupts the database. I was wondering if anyone else has seen anything like this? Enabled both accesslog and ppolicy overlays (configurations included below). All attempts to bind with an invalid password causes the server to crash and database to be corrupted. If you disable either of the overlays or just the "logold" setting of the accesslog the behavior is no longer noticed. Thanks, Pete ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ slapd.conf: overlay ppolicy ppolicy_default cn=Standard,ou=Policies,dc=amwater,dc=com ppolicy_use_lockout TRUE ppolicy_hash_cleartext TRUE overlay accesslog logdb cn=log logops all logold (objectclass=*) logpurge 5+00:00 1+00:00 logsuccess TRUE password policy: dn: cn=Standard,ou=Policies,dc=amwater,dc=com cn: Standard description: Standard password policy. pwdAttribute: 2.5.4.35 pwdMinAge: 60 # 30 days: 60 sec * 60 min * 24 hr * 30 days pwdMaxAge: 2592000 pwdCheckQuality: 1 pwdMinLength: 7 # Warn three days in advance pwdExpireWarning: 259200 pwdGraceAuthNLimit: 3 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxFailure: 3 pwdFailureCountInterval: 1200 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE objectclass: device objectclass: pwdPolicy

2 1

Recall: ldapmodify command line tool results in 'deferring operation: too many executing'
by Craig Worgan 26 Feb '09

26 Feb '09

Worgan, Craig (BVW:9T16) would like to recall the message, "ldapmodify command line tool results in 'deferring operation: too many executing'".

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software February 2009