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?
- RFC 2891 server side sorting
- RFC 3671 collective attributes
There's demo code for collective attributes in the source tree. Nobody has needed it enough to warrant polishing it up as a production module, but it works as-is.
- RFC 3928 LCUP mainly for updating cached addressbooks, etc - not
replication between servers
RFC4533 obviates this as well.
- RFC 3384 looks like just reqs for replication, not an actual
replication protocol - RFC 4533 is used instead
Unknown:
- RFC 3672 (subentries)
Incomplete.
- RFC 3698 and 3727 (additional matching rules)
I've used most but not all of these. RFC3727 X.500 component matching is part of the test suite.
- RFC 3909 LDAP Cancel operation
- RFC 5020 entryDN operational attribute
Yes both of those are implemented.
(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)
Depends on the replica config. In MM, yes.
- 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?)
Other replied have already covered this.
- Tracking of last login (i.e. last successful ldap authentication)
Nothing yet. Can be trivially added via the overlay mechanism, someone just needs to provide a spec/schema.
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?
I suppose we need to update our published roadmap. I don't consider SSS or VLV to be particularly important or well-designed features. In fact OpenLDAP has an RFC-compliant implementation of SSS which is a pure no-op; this is perfectly compliant because the SSS spec is so utterly useless in real directories. Since VLV requires SSS, it is IMO equally useless or at least seriously flawed, and I have a strong aversion to implementing flawed designs. (Never mind all the other flawed designs we're forced to live with already...)