November 2008 - openldap-software

by Clowser, Jeff (Contractor)

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

13 years, 8 months

11
29
0 / 0

TLS client certificates and memory use

by David Hawes

I was doing some testing and noticed that when I search for entries using TLS, significantly more memory is used when using client certificates than without them. In fact, memory will eventually be exhausted if the searches are performed indefinitely. Without using them, memory use stays (around) the same value. I stripped down the config, removed all ACLs except one (to disallow access), and started with an empty database, and get the same results. I've noticed this in 2.4.11, 2.4.12, and 2.4.13 with OpenSSL 0.9.8i. I do not notice it with an old 2.3.39 instance. Has anyone noticed anything similar, or can anyone reproduce this? Dave

14 years, 3 months

3
6
0 / 0

Re: bdb_search: 112 does not match filter

by Net Warrior

Hi Quanah My bad, did not reindex the database, sorry, I'll do that right now and see what happens. and yes, it's and old release, I'm aware of that, and we should upgrade as soon as posible. Thanks for your time and support. Best regards. 2008/11/11, Quanah Gibson-Mount <quanah(a)zimbra.com>: > > --On Tuesday, November 11, 2008 6:12 PM -0200 Net Warrior < > netwarrior863(a)gmail.com> wrote: > > Hi there guys. >> >> A costumer of us were having problems with the slapd service ( unexpected >> hangs ), it's an ubuntu installation running slapd 2.2.26 >> In the logs I noticed that there were no indexes available, the >> index_param failed were reported in the logs, the systems uses ldap for >> user authentication and nothing else. >> >> After that, I added the following in the slapd.conf, >> >> index cn,gidNumber,memberUid,uid eq >> index uniqueMember eq >> index uidNumber eq >> >> The performance where better and there were no more hangs, but I'm >> getting the following error. >> and the user cannot authenticate, so I went back to the original >> configuration without indexes. >> > > Did you reindex the database after you added the indices via slapindex > while the server was offline, as is required when you add indices to > existing objects? > > And, I'll note that OpenLDAP 2.2 is very old and no longer supported. > Numerous bugs have been fixed since that release, even in the OpenLDAP 2.2 > series. > > --Quanah > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

14 years, 3 months

3
3
0 / 0

slapd-meta and acls

by Irina Shetukhina

Hi. I have meta-backend o=vega and two databases o=vega-main and ou=devel on the same server. I'd configure meta-backend o=vega with suffixmassage "o=vega" "o=vega-main" and suffixmassage "ou=devel,ou=sites,o=vega" "ou=devel" I'd like to write acls per database, but provide DIT as single suffix o=vega. Members of cn=sysadmins,ou=groups,o=vega (really cn=sysadmins,ou=groups,o=vega-main) should grant write permissions to ou=devel,ou=sites,o=vega (really ou=devel). But they grant only read to o=vega. Where am I wrong? My slapd.conf: database meta suffix "o=vega" uri "ldap://ldap.irka.int.masterhost.ru/ou=devel,ou=sites,o=vega" suffixmassage "ou=devel,ou=sites,o=vega" "ou=devel" rootdn "cn=ldapadm,o=vega" rootpw X uri "ldap://ldap.irka.int.masterhost.ru/o=vega" suffixmassage "o=vega" "o=vega-main" database hdb suffix ou=devel rootdn "cn=ldapadm,ou=devel" rootpw XX directory /var/db/openldap-data/devel checkpoint 32 8 access to dn.sub="ou=devel" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,ou=vega-main" write by * read database hdb suffix o=vega-main rootdn "cn=ldapadm,o=vega-main" rootpw XXX directory /var/db/openldap-data/vega-main checkpoint 32 8 access to dn.sub="ou=SUDOers,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=mail,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.regex="ou=.*,ou=groups,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=groups,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" attrs=userPassword by self write by anonymous auth by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write access to dn.sub="ou=users,o=vega-main" attrs=mail by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" attrs=@inetOrgPerson,@inetLocalMailRecipient,@intraPerson,cn by self write by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="ou=users,o=vega-main" by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by users read access to dn.sub="o=vega-main" by anonymous auth by group/groupOfUniqueNames/uniqueMember="cn=sysadmins,ou=groups,o=vega-main" write by * read My openldap version 2.4.11 on FreeBSD 7.0-amd64. -- Irina Shetukhina

14 years, 3 months

1
0
0 / 0

Can't get olcPasswordHash to take effect...

by Andrzej Jan Taramina

Howard had said in a post last year: > For better backward compatibility, olcPasswordHash is allowed in both the > olcGlobal entry and the frontendDB entry. The preferred location for this > setting is now in the frontendDB entry. When generating a slapd.d from a > slapd.conf file, only the frontendDB entry will carry the attribute. Existing > slapd.d configs with the attribute in the global entry should continue to work > but they should be manually updated to use only the frontendDB entry. I'm trying to set my OpenLDAP config to use MD5 as the default password hashing algorithm (to be compatible with some other things we use). I'm using the latest OpenLDAP install for Ubuntu Intrepid, which is version 2.4.11. I added the olcPasswordHash attribute, and the relevant output of my cn=config (using ldapsearch -xLLL -b cn=admin,cn=config -W) now looks like this: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcPasswordHash: {MD5} But my passwords, when added/modified using ldappasswd still seem to use something other than MD5. Just wondering if anyone might have an idea what's causing the problem? Thanks! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com

14 years, 4 months

2
2
0 / 0

alternative listener and kerberos realm

by David Bonnafous

hi, My aim was to be able to communicate with slapd (2.3.43) using two hostnames (using alternative listeners), one HOSTNAME_A in a kerberos realm REALM_A and the second one, HOSTNAME_B, in realm REALM_B (according to krb5.conf section [domain_realm]). [domain_realm] HOSTNAME_A = REALM_A HOSTNAME_B = REALM_B slapd is running on a machine called HOSTNAME_A (command uname). My problem is that slapd only use HOSTNAME_A to create sasl context, as written in servers/slapd/sasl.c sc = sasl_server_new( "ldap", global_host, global_realm, iplocalport, ipremoteport, session_callbacks, SASL_SUCCESS_DATA, &ctx ); where global_host is not set according from where the connexion comes from. So my questions are: 1- is it a known stuff 2- do you think it is difficult to change this behavior so global_host depends on the hostname used to connect to slapd thank you, -- David Bonnafous Institut de Mathématiques Université de Toulouse - France

14 years, 4 months

1
0
0 / 0

delta-syncrepl problems with 2.4.12

by John Morrissey

I'm upgrading a site from OpenLDAP 2.3.42 to 2.4.12 in an attempt to alleviate http://www.openldap.org/its/index.cgi/Incoming?id=5631 (slapd crashes due to assertion failure). For us, doing so requires dumping and recreating two back-bdb databases since the OpenLDAP 2.4.x Debian packaging is linked against a newer version of BDB. The larger database contains about a million entries. Instead of slapcat(8)/slapadd(8)ding the old databases, we're removing the existing databases and allowing slapd(8) to delta-syncrepl a copy from scratch. Ironing out this use case is especially important for us since we expect to be adding a number of consumers in the coming months and would obviously prefer to bring them online without having to shut down any other slapd instances for slapcat(8)ting. The Administrator's Guide seems to indicate this is an accepted use case, since its guide to bringing up a new consumer involves simply configuring the consumer and starting slapd. When the consumer slapd comes up, it enters the refresh(?) phase and begins adding entries to the fresh, empty bdb database. When it finishes, contextCSN on the suffix entry is set to 20081111135024Z#000000#00#000000 (roughly when slapd was started) and this change is visible with ldapsearch(1). At this point, slurpd seems to start processing the accesslog. The first entry references a nonexistent DN (uid=nava209,...) and the backend operation returns LDAP_NO_SUCH_OBJECT. This is interesting, since this entry was created months ago should have been found during the refresh phase and created. ldapsearch(1)ing against the provider with the same filter used by the consumer syncrepl ('(objectclass=*)') yields this entry, so it doesn't appear to be index corruption on the provider. At this point, several hundred subsequent search entries are discarded; possibly due to the be_modify operation failing? After some time, slapd continues processing entries and does so successfully until it encounters another error (a modrdn that returns LDAP_ALREADY_EXISTS since the accesslog entry that modrdn'd the existing object out of the way was ignored by the consumer). After a while, slapd starts processing the same batch of modifications again, and repeats until the retry counter is exhausted. contextCSN on the suffix entry is never updated during this process, based on debugging output and ldapsearch(1). It's interesting that two consumers have successfully delta-syncrepl'd complete databases from scratch without experiencing this problem. At least four other consumer machines fail in this manner. There seems to be no rhyme or reason as to which machines succeed or fail; they're all running the same binaries, same OS release and patches, some are even on the same Ethernet segment as the provider. The provider slapd has been up consistently (without crash nor restart) during at least two attempts. Syncrepl (level 16384) debug output, sans ~400Mbytes of entry processing during the refresh phase, is at: http://horde.net/~jwm/slapd-syncrepl-debug john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

14 years, 4 months

4
8
0 / 0

unique_uri strict ?

by ghenry＠OpenLDAP.org

Hi, Do we have an example for an "unique_uri strict" uri? unique_uri strict ldap:///?mail?sub? says this is invalid, but it it probably my misunderstanding of what it expects. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

14 years, 4 months

4
7
0 / 0

Re: Uninvited listener?

by Chris Evans

Thanks Ralf and Howard. That fixed the problem, and all the tests succeeded except the illusive 007. C. > Am Sonntag 23 November 2008 20:57:46 schrieb Howard Chu: > > Most likely you are both seeing a bug in glibc, documented in our ITS#5251. > To workaround the problem remove "localhost", from the "::1" line in > /etc/hosts. The underlying glibc problem will be fixed with openSUSE 11.1. > regards, > Ralf > > Chris Evans wrote: > > > I am new to LDAP, and am trying to get OpenLDAP installed on a computer > > > running SUSE 11.0. (Actually, I did this on two similarly configured > > > machines with the same result.) Everything goes smoothly up until the > > > > > > "make test" step, which produces: [etc]

14 years, 4 months

1
0
0 / 0

Cannot start kerberos signing/sealing when using TLS/SSL

by Jeremiah Martell

I'm getting this error, but googling hasn't really explained what it means or what I'm doing wrong. Any ideas? Thanks, -- - Jeremiah Martell http://inlovewithGod.com

14 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software November 2008