[Date Prev][Date Next]
RE: OpenLDAP behavior with regards to MessageID and the RFC
On Fri, 2004-05-07 at 01:05, Howard Chu wrote:
> First the obvious question - what is so special about your proxy server that
> cannot be accomplished using OpenLDAP's existing proxy mechanisms? (e.g.,
> back-ldap and/or back-meta)
At the time, I had heard of back-perl which wasn't what I needed, but I
had not heard of back-ldap or back-meta. I believe that indeed these
proxying mechanisms may be the way to go, and I'll examine them further
for the next version of my project. Documentation and examples of their
use are pretty scarce at the moment, according to google. Where can I
go to learn more about them? (I'll check the OpenLDAP source code in
the mean time.)
Right now my proxy server is very light weight, so doing it my own way
was appropriate. Any LDAP messages not of interest to it are passed
straight through (with the MessageID altered if need be). Some are
modified, and sometimes LDAP requests are inserted into the current
session (which is why I sometimes need to alter the MessageID of the
pass-thru requests). Being mostly pass-thru means I don't have to worry
a lot about authentication or authorization. Sometime this summer I'll
be posting a detailed description of what I am doing, because I believe
that many OpenLDAP, eDirectory, and ActivedDirectory users will be
interested in it.
> OpenLDAP 2.0 has been unsupported for quite a while, so none of my email
> addresses it.
> There is nothing in the code that requires the MessageID to follow any
> particular sequence. In fact the MessageID is not validated in any way at
> all. You could use a constant MessageID for all of your requests and slapd
> would blithely answer. As long as you only have one request outstanding at a
> time, you'd never have any problem doing this, either. (But relying on this
> fact would be a mistake. The current slapd behavior should be considered a
> bug. At the very least, slapd should make sure the MessageIDs of all
> operations currently queued on a given connection are unique.)
Ok. If I make sure I'm RFC compliant, then, I'll be fine. It won't
matter to me whether OpenLDAP doesn't enforce some of the RFC MessageID
rules, since my LDAP requests will be compliant.
> You cannot assume that a client will wait for a response to each request
> before sending the next. The protocol allows multiple requests to be
> outstanding at once, and many common programs (e.g. sendmail) take full
> advantage of that fact. (Yes, slapd handles this.) Nor should your server
> require the MessageID to follow such a rigid pattern, as any LDAP client can
> choose some other arbitrary MessageID sequence.
The architecture of my server makes it relatively trivial to make sure
that concurrent requests can be handled and passed thru appropriately.
Currently it is not my intention that general LDAP clients (such as pam,
sendmail, or most other programs) connect to it. Since I can't trust
that fact, I'll finish bringing my server into full RFC compliance.
Probably what I'll do is maintain an internal per-session MessageID
variable that is incremented in a simple fashion for each message passed
on to the real server, and then apply a simple mapping between the
original message's MessageID and this variable.
Thank you very much for your response. It was very timely and very
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
Michael L Torrie <email@example.com>