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
- 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
- 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
- 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
----- "Aaron Richton" <richton(a)nbcs.rutgers.edu> wrote:
> On Fri, 25 Jul 2008, Guillaume Rousse wrote:
> > First, using a distinct database doesn't allow to provide a virtual
> > from a branch in my original database to another branch in the same
> > database. Meaning, I can't have ou=telephony,dc=myprefix a virtual
> > of ou=users,dc=myprefix, I need to use a distinct prefix.
> Have you tried declaring the ou=telephony,dc=myprefix back-relay
> subordinate to dc=myprefix back-$END?
I was about to reply the same, but you anticipated me :)
I've tried the above, and it works as expected as soon as the "relay" statement is omitted. In fact, it requires the superior database to already exist. Probably, that test should either be relaxed or moved to db_open().
With respect to Guillaume's second question, I see the issue. In principle, what he needs to do is something like
rwm-map attribute telephoneNumber homePhone
rwm-map attribute * telephoneNumber
so that real homePhone is mapped to virtual telephoneNumber, and real telephoneNumber is hidden. Unfortunately, this seems to result in a "double mapping" for telephoneNumber. I need to look at the logic of mapping, since what Guillaume wants to do seems to make sense, so it should be allowed. As per the reason of hiding everything not working, it's related to the fact that hiding everything does not allow "objectClass" to be returned, which causes the search filter to fail because the objectClass is not present. Unfortunately, the objectClass attribute cannot be mapped, so it cannot be explicitly preserved by adding
rwm-map attribute objectClass *
I recommend he files an ITS for each of those two issues.
> > Third, this solution doesn't work currently when trying to sync
> > the appliance users from ldap. From ldap log, it seems some
> > control is not supported with relay backend:
> I think you'd be better served by syncing the real data, and
> the back-relay/slapo-rwm identically across your slaves so as to give
> consistent results.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
I have a slave running syncrepl (just fine) which is getting hit with
update requests, which are, of course, failing. I'd like to have them
succeed. I could not find anything in the docs that would allow the
slave to issue a referral. That seems to be limited to slurpd, if I
So I tried to implement chained updates. I put the following into my
This does not seem to be sufficient, but I can't figure out from the
slapo manpage what else is required.
I get error 0x35, that the slave refuses to perform the operation. (I
tried whipping and otherwise punishing the slave, but it did not improve
it's attitude. :)
There does not seem to be a good howto for this.
Can somebody send me a pointer or an answer?
West Hollywood, CA
1. RTFM slapo-ppolicy: done, 3 times;
2. check openldap version: 2.4, newly installed on Gentoo Linux;
3. check ppolicy overlay successfully loaded and being used: must be,
because operational attribute like pwdFailureTime was maintained;
4. pwdAttribute setting: correct, value is "userPassword";
5. pwdCheckQuality: correct, value is 2 (server always check password
6. pwdMinLength: correct, value is 6, server do not accept password
short than 6 character;
7. ppolicy_default: correctly set, because change pwdMaxFailure on
default entry does have effect;
8. the entry being operated doesn't have pwdPolicySubentry, so
default should be applied: correct;
9. slapd server was restarted after all above check;
Test result: Still doesn't work:
$ldappasswd -vD uid=admin,st=jiangxi,o=LGOP -x -w secret -s 13456 ou=吉安市,st=jiangxi,o=LGOP
ldap_initialize( <DEFAULT> )
Result: Success (0)
(expected not successful here because new password was too short)
I am stuck here. Do I miss something on my checklist?
I have an interest in using openldap as an external authenticator for
our membership to connect to external services. Our main table has a
primary key of a varchar (10) and nothing unique in the table that is an
I would love to replace ldap_entries with a view, however, returning the
entries failed when I attempted it.
I did a bit of experimentation with the dc=example,dc=com on a search:
ldapsearch -x -b dc=example,dc=com sn=Puzdoy
The ldap_entries keyval was changed from int to varchar 10 and persons
table id was changed to varchar 10.
Below is a table on some experiments
ldap_entries.keyval and persons.id MySQL SQL SERVER 2000
2 Ok Ok
02 Ok Fail
ABC Fail Fail
abc Fail Fail
Jul 31 10:15:41 jpotkanski-lx slapd: Constructed query: SELECT
DISTINCT ldap_entries.id,persons.id,'inetOrgPerson' AS objectClass...
Jul 31 10:15:41 jpotkanski-lx slapd: id: '1'
Jul 31 10:15:41 jpotkanski-lx slapd: >>> dnPrettyNormal:
Jul 31 10:15:41 jpotkanski-lx slapd: <<< dnPrettyNormal:
<cn=Torvlobnor Puzdoy,dc=example,dc=com>, <cn=torvlobnor puzdoy,dc=examp
Jul 31 10:15:41 jpotkanski-lx slapd: backsql_oc_get_candidates():
added entry id=3, keyval=2 dn="cn=Torvlobnor Puzdoy,dc=example, ...
Jul 31 10:15:41 jpotkanski-lx slapd:
Jul 31 10:15:41 jpotkanski-lx slapd: backsql_search(): loading
data for entry id=0, oc_id=0, keyval=0
Jul 31 10:15:41 jpotkanski-lx slapd: backsql_search(): loading
data for entry id=5, oc_id=2, keyval=1
On a failed one, backsql_oc_get_candidates(): 0
openldap 2.3.39, 4.fc8 , unixodbc 2.2.12, freetds .84, mysql-odbc
Before opening anything in ITS, I wondered if this is a bug, feature
request or maybe solved in 2.4?
Information Technology Developer
430 N. Michigan Ave, Suite 800
Chicago, IL 60611-4092
I got the sources (2.2.8), compiled and installed OpenLDAP in RedHat
Enterprise Linux 5 ( 64-bit.) (I also got the sources and compiled
Now, I am trying to start the server. I don't get any error message in
In Ubuntu, the errors would show up in /var/log/syslog
Where could I find what is wrong when I invoke slapd? Where do the
errors get logged ?
*** Before acting on this email or opening any attachment you are advised to read the disclaimer at the end of this email ***
I've re-read my original message and it didn't make alot of sense. So
here's take two!
I'm using back-meta to attempt to amalgamate several ldap servers into
one single tree. This should cater for users that exist only in a local
BDB database, and also for users with accounts in one of the target ldap
servers. If I say 'local' or 'remote' user at any point, I'm referring
to users stored in the local bdb database or a remote ldap server
respectively. I shall refer to the local openldap server as the proxy
The meta database is subordinate to the local database. This allows me
to have a base record for the entire directory.
Everything works perfectly for targets that don't require a bind before
searching. For targets that do require a successful bind, I've been
trying to use the 'idassert-bind' feature with mixed results. The
following is a description of the behaviour I am trying to achieve:
If a local user binds to the proxy server, and performs a query with
one or more targets in scope, then the proxy server should use
predefined credentials to bind to and search only the targets in scope
on behalf of the local user.
If a remote user binds to the proxy server, and performs a query
affecting only the target where that user is stored, then the proxy
server should bind to that target using the credentials supplied by the
remote user. If there are any other targets in the scope of the query,
openldap should not attempt to use the predefined credentials to bind to
and search on that target.
To try to achieve this, I have placed all local users in their own
branch of the tree, and set the 'idassert-authzFrom' for each target to
match this branch only, thus preventing remote users from using the
idassert feauture and barring them from querying other targets than
Here is the first of two 'interesting' results. If I bind to the proxy
server as a remote user with multiple targets in scope, the bind is
proxied to the remote user's target correctly. The proxy then proceeds
to attempt to bind to the other targets in scope using seemingly random
names. Some examples (captured with wireshark) are '\270+1\b',
'\250\202/\b\005', '\220\241\322\267\220\241\322\267\020' and
'x\267.\b'. The name changes every time, but each time no password is
provided. The proxy will not attempt to search any of the targets after
binding, even the target to which the user belongs.
I'm not sure I understand the purpose of the 'non-prescriptive' flag,
but if I set it on each target (as Pierangelo suggested previously), the
unusual behaviour changes. When binding with a remote user, the proxy
will correctly bind to the target to which the remote user belongs using
the remote users credentials. If another target is in scope, the proxy
will attempt to bind to it without name or password. The proxy will
proceed to search the targets. This is fine for my situation, but I
would like to understand why this happens?
The second problem I'm having is with the local users. If the
'network-timeout' statement is used in the meta database definition,
whenever a local user binds to the proxy and queries one or more of the
target servers, the proxy will attempt to bind to the targets with the
predefined name but with no password. If network-timeout is not
specified, the proxy binds with both the predefined name and password to
every target in scope. Is this behaviour intended or a bug?
My current configuration is...
access to * by * write
suffixmassage "dc=target1,dc=meta,dc=example,dc=com" "dc=acme,dc=org"
index objectclass eq
index cn,sn eq,sub
The ldif file I use to populate the local database...
description: Container for metadirectory
dn: cn=Search user,dc=users,dc=example,dc=com
cn: search user
Thanks for your help!
Tel No: +44 (0) 1935 70 4421
*** Disclaimer ***
The information contained in this E-Mail and any subsequent correspondence may be subject to the Export Control Act (ECA) 2002. The content is private and is intended solely for the recipient(s).
For those other than the recipient any disclosure, copying, distribution, or action taken, or omitted to be taken, in reliance on such information is prohibited and may be unlawful.
If received in error please return to sender immediately.
Under the laws of England misuse of information that is subject to the ECA 2002, is a criminal offence.
Westland Helicopters Ltd
Yeovil BA20 2YB
Registered in England under No 604352
If anyone used slapd_db_hotbackup in the past, please kindly point me
at man pages or examples. It will be much appreciated. I did try
google, but only RPM packages came up and if I add -rpm to the search,
then only two irrelevant results came..
Thanks in advance,
Linux Systems Administrator
IRC: #openx on freenode.net
Does anyone know the specifics of the instability of BDB 4.3 (see
http://www.openldap.org/faq/data/cache/44.html)? I run OpenLDAP on a
RedHat platform that ships with BDB 4.3 and I need to convince other
applications on the system that an upgrade is important. At this point
they are asking for more specific details than 'OpenLDAP doesn't
recommend BDB 4.3'.