From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Are you interested in non-RFC features in OpenLDAP that Sun does not have? First you say yes, then no.
Also, are you interested in clients? The library? Otherwise don't say just "OpenLDAP", since that's both server, libraries and clients. (I don't know which of those, if any, "Sun DS" refers to.)
Sorry - I'm focusing on the server (slapd). I'm also interested, eventually, in all the server features, but if I listed all the OpenLDAP features, this email would be longer than it already is :). I figure I can look through all the admin guides, man pages, etc for new (to us) features openldap has, and until I do that and have more specific questions, I'd just be wasting bandwidth by doing so.
At this stage, I'm looking for what RFCs it supports, since that's an easy checklist and allows for easy matching against other choices.
I'm also looking to feature match the Sun directory server (since that's what it would be replacing). I need to know that it either supports a given feature Sun supports, or that it doesn't and we have to determine how important lack of said function is to us.
The following additional RFC's are supported in OpenLDAP:
- RFC 2247 and RFC 3088
- RFC 4524 COSINE schema
Note that if you find some LDAP implementation which doesn't already provide them, supporting these is trivial - just load the schemas defined in the RFCs. Unless the server defines some conflicting schema elements of its own.
Yeah - I only listed them because they were listed in the OpenLDAP faq-o-matic list of supported RFCs. There are a bunch of other schema related RFC's that I didn't include because all the ldap servers support schema extensions.
(There are some other, often obscure, LDAP related RFC's that I
didn't
include, but this seems to be the major/useful ones)
You may need to compare RFC 4513 features (Authentication Methods and Security Mechanisms) in more detail. E.g. SASL is *defined* as just a framework. Access controls are important, but the details are left to the implementation. So are the details for how to store, hash and protect passwords and certificates, how to map between SASL identities and LDAP identities (DNs), and various security policies.
Agreed. Our current usage is mostly simple binds, so from a feature matching perspective, I'm not too worried. Once we whittle down our server software choices to a handful, we can start looking at some of the "new" benefits we can make use of in a given server, and at that point we may start looking at actually using additional mechanisms. (i.e. We have to support current usage, and new functionality comes second)
Documentation, support and user community are other "features" you
might
have a look at. If you are in trouble, is the doc good enough to get you out of it? Do you get help? If you opt for paid support, what do you get for your money? (For OpenLDAP, the doc has been lagging
behind
the software but has steadily improved. It got a major boost for OpenLDAP 2.4. Paid support - see home page.)
Again, agreed, but that's for another stage of the eval :). Right now, my main concern is matching up our choices to what we currently have to cover current usage (and knowing if a potential choice will not support something we rely on, so we can determine if it rules out that choice or to see if we can work around it). As for documentation, community, etc... I've been using the Sun DS - 'nuff said there.
- Jeff