Xu, Qiang (FXSGSC) wrote:
-----Original Message-----
From: Howard Chu [mailto:hyc@xxxxxxxxxxxxxxx]
Sent: Friday, April 03, 2009 1:07 PM
To: Xu, Qiang (FXSGSC)
Cc: Henry B. Hotz; cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
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
16:39:02.518)<p27931,t3079396256,aba_ldap_interface.c,6666>
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
request)?
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/
