ando@sys-net.it wrote:
mhardin@symas.com wrote:
Sorry for the out-of-sequence reply. I'll test and let you know what I find.
No problem. Note that if this is the cause of this issue, and, in any case, if you have some "range" attributes in your response, you still have an issue with those values. It seems that, in the spirit of OpenLDAP software, we could be relatively liberal in accepting those values provided we are able to consolidate them in a single entry with no ranges. Apparently, what the proxies could do is:
- whenever a range is obtained in a response
- iteratively query the server again for the same entry,
- requesting only that attribute for the next block of vals
- incrementally build the set of values
- return the consolidated entry
This MUST be configurable, and documented as a nasty, expensive and unnecessary hack.
Even the thought of writing such an ugly hack is ... ugh...
As an alternative, I suggest modifying slapd/ad.c to treat "=" the same as "-" in an option definition. Then simply adding attributeoption range= to slapd.conf will allow the values to be recognized. (With the constraint that '=' must be the final character in the option definition...)
Let the client decide if they want to go thru the trouble of retrieving all the values or not. Certainly, for slapd to do it implicitly will overburden the (pathetically broken) AD server (otherwise they wouldn't need to break the value up into ranges in the first place). Indeed, doing this implicitly would amount to a DOS attack on the AD server.