September 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

14 years, 4 months

11
29
0 / 0

Translucent overlays & replication.

by John Maddock

Hi. With OpenLDAP 2.4.10 is it possible to replicate a translucent overlay's local changes to another server? Regards, John. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

15 years, 1 month

7
10
0 / 0

chaining and proxy

by Guillaume Rousse

Hello. I successfully setup the chain overlay, so as to push changes from a slave to a master, with something as: overlay chain chain-uri "ldap://ldap1.domain.tld" chain-idassert-bind bindmethod="simple" binddn="cn=chain,ou=roles,dc=domain,dc=tld" credentials="s3cr3t" mode="self" chain-idassert-authzFrom "*" chain-tls start chain-return-error TRUE I'm curious, tough, why the slave has to use a proxy identity to authenticate on the master, instead of reusing original query credentials. Is there something preventing it, or is just that all examples I found sofar were using it ? I was also curious to know if the slapauth tool was usable to test such kind of proxy setup. Reading the man page, it seems rather adapted to testing identity mapping through authz-regexp directives.

15 years, 2 months

3
6
0 / 0

Synchronizing with backend mysql

by kiran madala

Hi, I was wondering if openLDAP has any connectors to synchronize the users, groups in the directory to an external database such as mysql. Thank you. _________________________________________________________________

15 years, 2 months

4
3
0 / 0

Securing cn=config

by Ron Aitchison

I'm using OpenLDAP 2.4.11 on FreeBSD 6.2 RELEASE. I have a one user DIT (dc=example,dc=com), a cn=monitor DIT (with a rootdn and rootpw) and cn=config DIT (with rootdn and rootpw). Access to all the DITs uses simple binds. I configured the system to use TLS/SSL on the standard 636 port. and every works perfectly for all DITs. I can log in either with ldap(389) or ldaps (636) schemes. So I decided to lock down the box and prevent any non-TLS access (to DITs). By simply removing the listen on 389 (slapd -h ldaps:/// -u ldap) I could accomplish this - but the (perhaps minor) collateral damage was that access to cn=subschema with an anonymous bind obviously no longer worked (but obviously did using ldaps scheme). In an attempt to get this feature back I put back the listen on port 389 (slapd -h "ldap:/// ldaps:///" -u ldap) and added a global ACL of access to * tls_ssf=128 break Which works perfectly for the user DIT but obviously since I login to cn=monitor an cn=config via the rootdn had no effect. I removed the global ACL and added security simple_bind=128 And this where is got interesting: 1. Access via ldap on the user DIT and on cn=monitor where both inhibited and connections (rightly) refused whereas in both cases access via ldaps was accepted. 2. I could bind anonymously to rootDSE and cn=subschema which I wanted 3. cn=config would accept either a ldap (389) or an ldaps (636) connection. Apparently by-passing the security simple_bind=128 check. a. Is this expected? b. is there a better way to do it? c. Am I (more than likely) missing something? (on searching the archives I saw a note from Quannah suggesting that he was using some sort of SASL service to inhibit access). Many thanks in advance for any help on this matter. Regards -- Ron Aitchison www.zytrax.com ZYTRAX ron(a)zytrax.com tel: 514-315-4296 Suite 22 6201 Chemin Cote St. Luc Hampstead QC H3X 2H2 Canada Author: Pro DNS and BIND (Apress) ISBN 1-59059-494-0

15 years, 2 months

2
3
0 / 0

syncrepl with hardware content switch

by Brett ＠Google

Hello, I was wondering if anybody is using syncrepl in the context of a hardware content switch or redundant environment. That is, having a "hidden" syncrepl master, and 1-N syncrepl clients which receive updates from the master, and those client nodes (and only those nodes) are visible via a content switch, for the purposes of load sharing and redundancy (more predominantly the latter). I am considering the edge case where a connection is redirected to a client, and : a) client has no current data (new node introduced) b) client decides it needs to do a full refresh - perhaps it was down and missed a large number of updates The problem is, that while a replica is b) significantly incomplete or a) has no data at all, it should not be given any ldap requests by the content switch. A standard content switch either blindly send connections round-robin to nodes 1-N, or if it determines that a server is "listening" (say by sending a SYN probe) before it sends through the ldap request. Few content switches are smart enough to examine the ldap failure code, as most just operate on tcp streams and don't do content inspection, so doing ldap content inspection is even less likely. So this means that during the time a replica is initializing, and ldap requests are going to incorrectly get "no results" where the answer should be "not applicable" and the content switch or ldap client should have tried again, getting another (already initialized) server. Ideally (in a content switch environment at least), the ldap server should not listen for requests while it is re-synchronising, but in the case of syncrepl push replication, replication can happens over the same port as ldap client requests. One answer would be if syncrepl could happen over it's own port, as then there could then be the option of not accepting (not listening?) or refusing connections on the client port, whilst syncrepl is (re)building on the syncrepl port. Alternatively, there could be a "health" port, which only accepted a connection and maybe returned "OK" if the replica was "healthy", this port could be specified as a "probe" port on the content switch, to determine the health of a syncrepl client. I was just wondering how other people are dealing with this issue and thier content switches. Cheers Brett

15 years, 2 months

6
6
0 / 0

size of DB files not decreasing

by Nikhil Mishra

hello all , While deleting the entries from openldap- Database I see that there is no change in the file size . I did an external checkpoint using db_checkpoint -1 and db_archive -d . The changes are reflected fro an add operation but it is not reflected for delete . I have a requirement where I need to externally poll the size of DB for openldap . But delete operation is not making any changes to actual DB file size . I am not sure if its a BDB limitation or something to do with the way openldap is being configured . Please help in understanding . regards Nikhil

15 years, 2 months

2
1
0 / 0

dynlist expantion on search with an attribute set

by Emmanuel Dreyfus

Hello I have an object class that triggers slapo-dynlist expantion. It works very well if I request the whole object: $ ldapsearch uid=foo <here I get the object with dynlist expanded> But if I request an attribut set that contains the attribute to be expanded (here mail), it does not work: $ ldapsearch uid=foo mail <dynlist not expanded> Adding memberURL does not help: $ ldapsearch uid=foo memberURL <dynlist not expanded> Is it on purpose? Is there a work around? It is troublesome since the client application does ask for a set of attribute... -- Emmanuel Dreyfus manu(a)netbsd.org

15 years, 2 months

2
7
0 / 0

LDAP 2.3.43 Mater to Slave replication

by Proskurin Kirill

Hello! Im trying to set a Ldap replication on FreeBSD 6.3 system. First im try to use sluprd but run in many strange thing and then read what it is near to deprecation. Then im try to use sysrepl. Im read docs and add this to slapd.conf: Master: database bdb suffix "dc=domain,dc=org" rootdn "cn=root,dc=domain,dc=org" overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Salve: database bdb suffix "dc=domain,dc=org" rootdn "cn=root,dc=domain,dc=org" syncrepl rid=123 provider=ldap://172.16.1.2:389 type=refreshOnly interval=0:01:00:00 searchbase="dc=domain,dc=org" filter="(objectClass=*)" scope=sub attrs="*,+" schemachecking=off bindmethod=simple binddn=""cn=replicator,ou=sys,dc=domain,dc=org" updatedn=""cn=replicator,ou=sys,dc=domain,dc=org" credentials=123 But slave ldap dont start with this error: slapd[43092]: /usr/local/etc/openldap/slapd.conf: line 65: Error: Malformed "syncrepl" line in slapd config file, missing provider searchbase. slapd[43092]: failed to add syncinfo slapd[43092]: slapd stopped. slapd[43092]: connections_destroy: nothing to destroy. line 65 = syncrepl rid=123 Im do something wrong? What im need to fix? -- Best regards, Proskurin Kriill

15 years, 2 months

4
7
0 / 0

Extending Schema

by Peter Clark

Hello, I am using openldap 2.4.11 and I am trying to add an attribute for "Date of Birth" for each user. In doing some googling I found 2 old emails showing 2 ways to extend a schema for this attribute. Adam Tauno Williams wrote: attributetype ( 1.3.6.1.4.1.8506.1.2.11 NAME ( 'birthDate' 'dob' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) and Michael Stroder wrote: # # Date of birth: # a numeric string restricted to syntax YYYYMMDD # attributetype ( 1.3.6.1.4.1.5427.1.389.4.2 NAME ( 'dateOfBirth' ) DESC 'Date of birth (format YYYYMMDD, only numeric chars)' EQUALITY numericStringMatch SUBSTR numericStringSubstringsMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{8} ) While looking at these two and the Schema Specification in the handbook I have gotten rather confused. Could I just drop one of these into file named local.schema (for example) add that path to the schema section of the slapd.conf and use it or is there more to it? Thank you, Peter

15 years, 2 months

2
1
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software September 2008