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 - 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
Unknown: - 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
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?) - 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 functionality?
Thanks, - Jeff
--On November 15, 2007 3:02:29 PM -0500 "Clowser, Jeff (Contractor)" jeff_clowser@fanniemae.com wrote:
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?)
man slapd.conf, see the "limits" command
The ones that are really problematic are the lack of:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
The ones that are really problematic are the lack of:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
Well, You're probably right ;) Anyway -
1. Isn't good tradition to support as much as possible and allow administrators to decide, whether they like waste their CPU or not, instead of hardcoding decision in the code?
2. While it probably is a waste of server CPU, analog example with relational database has opposite meaning, as much as I can I'd rather let SQL server do all computations, sorting etc., because I presume, that whatever kind of implementation of e.g. sorting server has, it is better implemented on server code than in my code, because people who created the server are better programmers than I am - I guess. So, I'd bet server developers implemented sorting in better way than I did in my application (ldap client).
Anyway - that's to Jeff especially - worth to note, that openldap client library supports sorting, so in this case "better programmers than me" rule of thumb does not work - client application should use "native" ldap-client sorting (actually implemented on the client side).
?
If you have (for example), a PHP extension, and this extension does not make usage of client-side sorting implemented in ldap-client library it's based on, so you have to sort result on high level, in final script code using some PHP sort function - blame extension authors, and not database server authors.
Finally, as an administrator I'd appreciate server-side sorting in openldap anyway. In my applications I write in C I use openldap's libldap-client sorting and I'm fine with it, anyway, sometimes I'd prefer waste some ldap server CPU, instead of wasting web server CPU (php/perl/other as ldap client). I'd also prefer to waste some ldap server CPU, instead of time spent rewriting something like php ldap extension, or perl ldap binding, or java jndi etc. (AFAIK Java jndi does not support "native" libldap-client sorting too). CPU time, although precious and worthy, is cheaper than programmer's and project manager's time.
Don't take above too seriously, just to discuss :) - anyway I think that's enough reasons to consider implementation server-side sorting. Sometimes I recommend openldap to people searching for corporate catalog solution, beneath Netscape/SUN, IBM's Lotus Directory Server, and (in)famous ActiveDirectory, and others. I use openldap (currently 2.3.39) for many hundreds of users and tens thousands of entries, and I can frankly recommend it. But I don't know what to say, when they say: "But commercial server A supports feature X,Y,Z, and openldap doesn't", and one of features they usually mention first is server-side sorting.
FYI - another feature they mention is ability to return just number of entries found instead of or with entries themselves, as a "part of result", and it's hard to explain, that number of entries is out of ldap server's interest.. :)
Regards, DT
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?)
man slapd.conf, see the "limits" command
Doh (smacks head). That was too obvious, so of course I missed it... :)
OK, Sun allows you to set the following per user limit: - Time limit (how much time an operation can take) - Size limit (max # of entries a search can return) - Lookthru limit (max number of entries that will be looked at in a search, even if max # entries have not been found) - Idle timeout (max time a connection bound as this user can be idle before closing)
Looks like OpenLDAP can do the time limit, size limit (size.soft/size.hard) and the lookthru limit (size.unchecked), but can't do idle timeout (which of course is the one I use... :-/ )
The ones that are really problematic are the lack of:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of
server
CPU that's better served by the client doing sorting how it wants.
--Quanah
Because of existing usage. Unfortunately, we have applications that use and depend on it (and I think the VLV mechanism depends on it as well - it requires that the result set be sorted, in any case). Breaking all those apps would be a hard sell.
Also, if you are doing simple paged results (which OpenLDAP does support), the point is that the client may not have the resources to handle all matching results at one time, so getting them back in (some form of) sorted order is useful.
- Jeff
On Thu, Nov 15, 2007 at 12:30:09PM -0800, Quanah Gibson-Mount wrote:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
well ... i think this feature could be very usefull in certain cases.
Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
regards.
mc
On Fri, 16 Nov 2007, Marc Chantreux wrote:
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
well ... i think this feature could be very usefull in certain cases.
What if a hundred clients all asked for a server sort at the same time?
Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
So you ask for "maxUidNumber" instead...
Marc Chantreux wrote:
On Thu, Nov 15, 2007 at 12:30:09PM -0800, Quanah Gibson-Mount wrote:
- RFC 2891 (server side sorting)
Why is this problematic? Server side sorting is a horrible waste of server CPU that's better served by the client doing sorting how it wants.
well ... i think this feature could be very usefull in certain cases.
Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
The server side sorting feature is an extremely indirect (and inefficient) route to answering this particular question; you get the answer you're looking for as a side-effect of a non-standard query. That seems pretty silly, when you can just get the answer as a direct result of a standard LDAP query.
On Thu, 15 Nov 2007, Howard Chu wrote:
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
Why would that return the highest? Or are you counting upon the current LIFO behaviour and if so, is this now guaranteed?
Dave Horsfall wrote:
On Thu, 15 Nov 2007, Howard Chu wrote:
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
Why would that return the highest? Or are you counting upon the current LIFO behaviour and if so, is this now guaranteed?
Forget I said that. Not guaranteed.
Hello,
Howard Chu wrote:
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
Sounds like an intriguing way to find the highest uidNumber, but
1. it doesn't seem to work:
ldapsearch -x -W -z1 "(uidnumber<=65534)" uidnumber
# extended LDIF # # LDAPv3 # base <dc=tu-clausthal, dc=de> (default) with scope subtree # filter: (uidnumber<=65534) # requesting: uidnumber #
# search result search: 2 result: 0 Success text: inappropriate matching request
# numResponses: 1
(Yes, I have an equality index on uidnumber, and my bdb Database contains that index, and I used 2.4.5 for that query)
2. who guarantees that due to indexing the highest uidnumber will be returned? Could it be that it is just because OpenLDAP is currently coded to do it that way? Is there a RFC requiring OpenLDAP to do so?
bye Christian
Hello again,
Christian Marg wrote:
Howard Chu wrote:
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
Sounds like an intriguing way to find the highest uidNumber, but
- it doesn't seem to work:
... because "uidNumber"-Schema doesn't have an "ORDERING" rule.
bye Christian
Christian Marg wrote:
Hello,
Howard Chu wrote:
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
Sounds like an intriguing way to find the highest uidNumber, but
Sorry I misspoke, I was thinking of something else. We talked about ordered indexing for integers but only actually implemented it for generalizedTime and CSNs.
- it doesn't seem to work:
ldapsearch -x -W -z1 "(uidnumber<=65534)" uidnumber
# extended LDIF # # LDAPv3 # base <dc=tu-clausthal, dc=de> (default) with scope subtree # filter: (uidnumber<=65534) # requesting: uidnumber #
# search result search: 2 result: 0 Success text: inappropriate matching request
# numResponses: 1
(Yes, I have an equality index on uidnumber, and my bdb Database contains that index, and I used 2.4.5 for that query)
- who guarantees that due to indexing the highest uidnumber will be
returned? Could it be that it is just because OpenLDAP is currently coded to do it that way? Is there a RFC requiring OpenLDAP to do so?
Nope, there's no spec for it, and portable applications cannot rely on it. Sorry for the confusion.
bye Christian
Howard Chu writes:
Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
In OpenLDAP you would set an equality index on uidNumber and do a query for, e.g., (uidNumber<=2147483647) with sizelimit=1.
What? That only finds the max uidNumber when you already know an almost-max value, so you can fill it into the filter. Without that you'd need to guess an upper limit and do a binary search. (Though you could use a sizelimit > 1 for that.)
[Combining several replies]
Howard Chu wrote:
Marc Chantreux wrote:
On Thu, Nov 15, 2007 at 12:30:09PM -0800, Quanah Gibson-Mount wrote: Imagine I just want to know what's the max uidNumber used in my directory. actually, i ask the server to give all the uidNumbers and my client sort them. isn't it an horrible waste of bandwidth ?
(...) The server side sorting feature is an extremely indirect (and inefficient) route to answering this particular question; you get the answer you're looking for as a side-effect of a non-standard query.
Or you *don't* get the answer you are looking for, if the server first picks <sizelimit> entries to return and then sorts them.
In fact, section Security Considerations of RFC 2891 (the server-side sorting RFC) points out that it is a security problem if this works when also more entries match than the administrative (server-side) limit.
Does it work with some existing implementations - (a) when there are fewer matcing entries than the server-side limit and (b) when there are more matching entries than that?
Matt Smith wrote:
I see one valuable use for SSS - guaranteed search return order.
Yes, that could be useful. To get that from SSS you need: - an attribute to which you can apply some ordering rule (or several attributes, in case sorting by one isn't enough), - each entry must contain a *unique* value of the attribute (entryUUID would be OK for _some_ OpenLDAP backends), - no access controls protecting the attribute(s), - not to run into size/time limits.
Howard Chu wrote:
(...) 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.
I don't think that's a fair argument, it's like using the null backend to demonstrate why the spec of the LDAP search operation is useless.
A related point: The LDAP spec leaves large parts of LDAP unspecified or optional, and vendors disobey mandatory parts of it too. I said Jeff might need to examine RFC 4513 features in greater detail, but might just as well have said it about the entire LDAP spec. E.g. does the server support attribute inheritance (can you search for 'name' and find 'cn')? Object class extensibleObject? Does case-insensitive match handle lowercase vs. uppercase non-ASCII letters? Does the server normalize Unicode strings before comparing? Howard mentioned other examples, regarding the X.500 model.
That can be a problem if the implementation you move _from_ lacks features too. If you move your data to a server which does stricter error checking (e.g. it requires exactly one structural class per entry), you may need to rewrite your schema and/or LDAP data so the new server will accept it.
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...)
Howard Chu hyc@symas.com writes:
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...)
It might be worth noting that, depending on your application and the provenance of the data, the valsort overlay may actually be what you want rather than server-side sorting.
Howard Chu hyc@symas.com writes:
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...)
It might be worth noting that, depending on your application and the provenance of the data, the valsort overlay may actually be what you
want
rather than server-side sorting.
-- Russ Allbery (rra@stanford.edu)
As I read the man page, valsort sorts *values* of an attribute within an entry. SSS sorts the order *entries* are returned, based on the (presumably single) value in some attribute(s).
While I agree with what people are saying about the negatives of SSS and poor design (such as how do you sort using a multivalued attribute as a key [which val do you use?] - it generally expects attributes to have a single value or only uses the "first" value [which in and of itself is undefined for most (all?) attribute types], and the rfc doesn't even touch on this), the problems I face are:
1. Most other LDAP server choices implement it (I think Sun/Red Hat, Microsoft, Novell, Oracle, etc all support this control, so OpenLDAP stands out by not having it).
2. Since it's so commonly implemented, developers tend to expect it to be there, and write code that uses/depends on it.
So... I'm kinda stuck with it as a requirement, and justifying why people have to rewrite apps (or in the case of COTS apps, possibly breaking them with no option to fix/rewrite) becomes a pretty hard sell. (And yes, any app that actually *breaks* because it didn't check that an optional control isn't there is itself broken, but the world is what it is, and I don't make all the buying decisions...)
In any case, whatever the reason, OpenLDAP doesn't implement it - it is what it is, and I don't fault it - I just have to identify it as not meeting one of many requirements. How important that requirement is in the overall picture is yet to be seen. If there were any solutions that met everyones requirements, we wouldn't have to do evaluations :)
- Jeff
Clowser, Jeff (Contractor) wrote:
While I agree with what people are saying about the negatives of SSS and poor design (such as how do you sort using a multivalued attribute as a key [which val do you use?] - it generally expects attributes to have a single value or only uses the "first" value [which in and of itself is undefined for most (all?) attribute types], and the rfc doesn't even touch on this), the problems I face are:
- Most other LDAP server choices implement it (I think Sun/Red Hat,
Microsoft, Novell, Oracle, etc all support this control, so OpenLDAP stands out by not having it).
OpenLDAP stands out in a lot of ways - it actually implements the X.500 data model as mandated by the LDAP spec, it actually performs well, it actually stores your data and returns the same values you stored without corrupting or losing them. These are traits that none of those other vendors offer, nor can these features easily be added to those other offerings.
On the flip side, we can easily add an overlay to OpenLDAP to provide SSS/VLV. It would satisfy a checklist, but it probably still wouldn't prevent client apps from misbehaving, since the actual specs are so full of holes and there are so many undefined behaviors to deal with.
- Since it's so commonly implemented, developers tend to expect it to
be there, and write code that uses/depends on it.
Since the specs fall down in so many cases, you still need to write code to compensate for those failures. All this does is make more work for the developers. I guess if those folks are being paid by lines-of-code it makes sense for them...
So... I'm kinda stuck with it as a requirement, and justifying why people have to rewrite apps (or in the case of COTS apps, possibly breaking them with no option to fix/rewrite) becomes a pretty hard sell. (And yes, any app that actually *breaks* because it didn't check that an optional control isn't there is itself broken, but the world is what it is, and I don't make all the buying decisions...)
Any apps using SSS/VLV were already broken, before OpenLDAP entered the picture. Very likely they have already failed in the field, but nobody noticed the data inconsistencies caused by those failures. It's only a matter of time before they're going to be forced to be rewritten anyway. (E.g., an AD DIT has multiple partitions all glued together by referrals. SSS doesn't do anything special with referrals; the client has to figure out what to do anyway.)
In any case, whatever the reason, OpenLDAP doesn't implement it - it is what it is, and I don't fault it - I just have to identify it as not meeting one of many requirements. How important that requirement is in the overall picture is yet to be seen. If there were any solutions that met everyones requirements, we wouldn't have to do evaluations :)
Indeed.
Jeff,
Clowser, Jeff (Contractor) wrote:
While I agree with what people are saying about the negatives of SSS and poor design [..] the problems I face are:
- Most other LDAP server choices implement it (I think Sun/Red Hat,
Microsoft, Novell, Oracle, etc all support this control, so OpenLDAP stands out by not having it).
- Since it's so commonly implemented, developers tend to expect it to
be there, and write code that uses/depends on it.
So... I'm kinda stuck with it as a requirement, and justifying why people have to rewrite apps (or in the case of COTS apps, possibly breaking them with no option to fix/rewrite) becomes a pretty hard sell.
You're doing an evaluation for your customer. Being in this position I'd recommend to...
1. ask the customer which client application he's deploying and whether SSS is a MUST requirement for the applications. Discussing this can be sometimes hard if the customer does not have a clue about what he really wants. But you're doing consulting, yes? So it's your job explaining it. ;-)
2. watch out how it is actually implemented in the other server products and which problems arise in real-world deployments (refer to discussion boards of the other vendors for that). This can be somewhat enlightening. ;-)
I just have to identify it as not meeting one of many requirements. How important that requirement is in the overall picture is yet to be seen.
During evaluation you have to weigh each and every requirement. Ask your customer for the weight of this particular requirement. For my customers this feature was most times not important after all. Though everybody asks for it.
Ciao, Michael.
On Thu, 2007-11-15 at 14:59 -0800, Howard Chu wrote: ...
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...)
I see one valuable use for SSS - guaranteed search return order. Regardless of the sort algorithm, knowing that searches will always return entries in the same order allows for easy comparison, merge sorts, or differentials with another list - as in necessary during the reconciliation or join phases of provisioning.
Or is this a bad application of SSS?
-Matt
Smith, Matt wrote:
On Thu, 2007-11-15 at 14:59 -0800, Howard Chu wrote: ...
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...)
I see one valuable use for SSS - guaranteed search return order. Regardless of the sort algorithm, knowing that searches will always return entries in the same order allows for easy comparison, merge sorts, or differentials with another list - as in necessary during the reconciliation or join phases of provisioning.
Or is this a bad application of SSS?
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.
I see one valuable use for SSS - guaranteed search return order. Regardless of the sort algorithm, knowing that searches will always return entries in the same order allows for easy comparison, merge sorts, or differentials with another list - as in necessary during
the
reconciliation or join phases of provisioning.
Or is this a bad application of SSS?
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.
-- -- Howard Chu
But not all LDAP client libraries have this feature, and not everyone uses OpenLDAP's client libraries...
- Jeff
Clowser, Jeff (Contractor) wrote:
Unknown:
I guess "unknown" means you couldn't determine the status of support in slapd.
- RFC 3672 (subentries)
Searching for subentries is supported in slapd. Not sure about whether subentries are used at all.
- RFC 3909 LDAP Cancel operation
Is supported by slapd. But not by many client applications I guess. ;-)
Python 2.5.1 (r251:54863, Aug 3 2007, 00:52:06) [..]
import ldap l=ldap.initialize('ldap://localhost:1390') m=l.search('dc=stroeder,dc=de',ldap.SCOPE_SUBTREE,'(objectClass=*)') l.cancel_s(m)
syslog: Nov 16 12:35:42 nb2 slapd[3313]: conn=6 op=1 CANCEL msg=1 Nov 16 12:35:42 nb2 slapd[3313]: conn=6 op=1 RESULT oid= err=0 text=
- RFC 5020 entryDN operational attribute
Yes.
Ciao, Michael.
Clowser, Jeff (Contractor) wrote:
Unknown:
I guess "unknown" means you couldn't determine the status of support in slapd.
Correct - means _I_ couldn't find it in the faq, admin guide, or man pages (doesn't mean it wasn't there, just that I couldn't find it :) ).
Thanks for the rest of the answers.
- Jeff
Clowser, Jeff (Contractor) wrote:
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. (...) have just focused on those associated with 1) RFC compliance (...) and 2) features to match the Sun DS (which it would be replacing).
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.)
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 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.
(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.
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.)
Other supported features:
- dyngroup/dynlist/memberof overlay (A much more useful feature than
Sun's groupOfURLs "dynamic" group and "roles" mechanism)
Also some OpenLDAP fields can be LDAP URLs to for DNs, even without overlays: dynamic groups in access statements (unless the doc is missing a reference to the overlay). authz-policy and authz-regexp for Proxy and SASL Auth.
- live acl changes via LDAP
More generally, live config changes.
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
Clowser, Jeff (Contractor) wrote:
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.
That's a fair statement. I'll note that many companies are doing this exact same evaluation, it's a well-trodden path. The first several overlays released in OpenLDAP 2.3 were commissioned by Hewlett-Packard to provide the features they needed to allow their own migration off Sun servers to OpenLDAP. Ultimately when someone is sufficiently motivated, whatever is desired will get implemented. (HP transitioned their entire internal global IT off of SunDS to OpenLDAP a year or so ago. In their case, they specified exactly what server/features they wanted, and that's what they got.)
--On Friday, November 16, 2007 1:13 PM -0800 Howard Chu hyc@symas.com wrote:
That's a fair statement. I'll note that many companies are doing this exact same evaluation, it's a well-trodden path. The first several overlays released in OpenLDAP 2.3 were commissioned by Hewlett-Packard to provide the features they needed to allow their own migration off Sun servers to OpenLDAP. Ultimately when someone is sufficiently motivated, whatever is desired will get implemented. (HP transitioned their entire internal global IT off of SunDS to OpenLDAP a year or so ago. In their case, they specified exactly what server/features they wanted, and that's what they got.)
Stanford University did something similar when transitioning from NetscapeDS (a close relative to SunOne) back when OpenLDAP 2.1 was first coming out, and also commissioned a bit of work from Symas to help with that transition as well.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Clowser, Jeff (Contractor) wrote:
I'm also looking to feature match the Sun directory server (since that's what it would be replacing).
So you have good chance examining what the client applications really need because you can look at existing data traffic.
Ciao, Michael.
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...
openldap-software@openldap.org
-
Christian Marg -
Clowser, Jeff (Contractor) -
Dave Horsfall -
Hallvard B Furuseth -
Howard Chu -
Marc Chantreux -
Michael Ströder -
Piotr Wadas -
Quanah Gibson-Mount -
Russ Allbery -
Smith, Matt