[Date Prev][Date Next]
Re: Supported RFC's and "features"
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
- 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
- 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
- RFC 3672 (subentries)
- 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
- 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
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...)
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/