SASL2 plugin problem
hyc at highlandsun.com
Fri Apr 3 13:20:28 EDT 2009
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Howard Chu [mailto:hyc at highlandsun.com]
>> Sent: Friday, April 03, 2009 1:07 PM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Henry B. Hotz; cyrus-sasl at lists.andrew.cmu.edu
>> Subject: Re: SASL2 plugin problem
>> Don't use MozLDAP, it's obsolete. At this point it's total
>> abandonware, it's not even present in any current Mozilla
>> builds. (And yes, I build a full Mozilla source tree on a
>> pretty frequent basis. I've also submitted a patch to build
>> Mozilla with OpenLDAP's libldap, since Mozilla has abandoned
>> the MozLDAP code.)
> For SASL LDAP binding, I see that OpenLDAP + SASL is the most used
combination. Yet, from my googling, there are some successful examples of use
MozLDAP with SASL.
Sure, and even a broken clock is right once or twice a day. The fact remains
that the original authors of MozLDAP have abandoned it, no one has maintained
it in several years, and the code is full of bugs.
>> Given that both MozLDAP and OpenLDAP use the same SASL
>> library, and OpenLDAP works, how can you deduce that the
>> problem is in the SASL library?
> Hmmm, you are right about this. But I also have my reasons. See below.
>>> The caller seems innocent:
>>> <apManager> (Tue Mar 31 2009
>>> INFO>> Value of hostname sesswin2003:389
>> Fix that. MozLDAP isn't parsing it correctly; just use the hostname.
>> The C API spec says that this is allowed to be in host:port
>> form, and the LDAP library is supposed to recognize that and
>> parse it appropriately when this form is passed in. MozLDAP
>> doesn't parse it though, it uses it verbatim. When it hands
>> this host:port form to SASL, which expects hostname and
>> portnumber as two separate parameters, things fail.
>> The Mozilla LDAP codebase deviates from (or simply fails to
>> implement) the LDAP specs in lots of ways. I guess here's a
>> case where it failed to follow the SASL API as well.
> But how to explain in case of simple LDAP binding, the format "host:port"
can be handled (the format "host:port" can be recognized and separated for DNS
If you look at the source code, it's obvious. There are separate APIs
involved; the libldap API creates the connection - that part does the parsing
as intended. Look at your packet traces again, you'll see that in both cases
(OpenLDAP and MozLDAP) the client connects to the correct server. The problem
comes when MozLDAP passes its unparsed host:port (which MozLDAP's connect
function will happily use) to the SASL library; the SASL library does the DNS
lookups for service name canonicalization. That part fails, which is why
GSSAPI gives you a Local Error.
> In both simple binding and sasl binding, they are using the same
function, with the same paremeter passed in. Thus, I can't help thinking
something is not quite right with SASL libraries. But what you said is also
reasonable, SASL works well with OpenLDAP, so it can hardly be faulted.
The SASL library (in this case) works exactly as documented. As I already
said, the MozLDAP code fails to use SASL according to its specification.
>> If you want code that actually works and adheres to
>> standards, stick with OpenLDAP.
> But our printers are using MozLDAP SDK, not OpenLDAP. Alas!
Whoever made that design choice probably should revisit this decision.
Building a product on top of poor, unsupported code is never a good idea...
And of course, switching to the OpenLDAP library is pretty easy, and OpenLDAP
is actively supported by a large community of people who care about and know
what they're doing...
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
More information about the Cyrus-sasl