Revisiting an ancient thread...
Clowser, Jeff (Contractor) wrote:
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?
Apparently so.
- RFC 2891 server side sorting
Available now in CVS, will probably be in 2.4.18.
- RFC 3671 collective attributes
The OpenLDAP implementation of collective attributes doesn't use subentries but otherwise provides all the features.
- RFC 3928 LCUP mainly for updating cached addressbooks, etc - not
replication between servers
LCUP is dead.
- RFC 3384 looks like just reqs for replication, not an actual
replication protocol - RFC 4533 is used instead
Unknown:
- RFC 3672 (subentries)
Limited support.
- RFC 3698 and 3727 (additional matching rules)
Yes.
- RFC 3909 LDAP Cancel operation
Yes.
- RFC 5020 entryDN operational attribute
Yes.
(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.
Now in CVS.
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)
Replication was not directly supported before, but is now.
- 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?)
per-user limits for size and time, yes. global idletimeout.
- Tracking of last login (i.e. last successful ldap authentication)
No, but I've proposed this as an addition to the ppolicy spec.
I think someone else already replied that the client library already handles sorting of results. There's nothing that depends on the server handling this in the application you're talking about.
But not all LDAP client libraries have this feature, and not everyone uses OpenLDAP's client libraries...
The number who don't is small and getting smaller over time...