SASL2 plugin problem

Howard Chu hyc at
Fri Apr 3 01:06:38 EDT 2009

Xu, Qiang (FXSGSC) wrote:
> Hi, all:
> Now I am able to use ldapsearch (the OpenLDAP utility) to do SASL binding after a successful kinit operation. To let it work, the following two conditions are necessary:
> 1. SASL binding should use LDAP server's hostname, instead of IP address.
> 2. DNS servers should be correctly set up to resolve the hostname to its IP address.

>> From the result, we can see the LDAP server's FQDN can be resolved
correctly by SASL library using DNS routines. If DNS can't resolve the
hostname to IP address, then an error 82 (ldap_sasl_interactive_bind_s: Local
error) will appear.
> Now I turn back to use MozLDAP library to code SASL support, but it
> doesn't
work. The error is still this "82 Local error".

"Doctor, it hurts when I do this."

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 

> In the network trace captured
between the client printer and the server, I found the following interesting
> ========================================
> 32	3.141158	DNS	Standard query A sesswin2003:389
> 33	3.141400	DNS	Standard query response, No such name
> 34	3.141981	DNS	Standard query AAAA sesswin2003:389
> 35	3.142071	DNS	Standard query response, No such name
> 36	3.142287	DNS	Standard query A sesswin2003:389
> 37	3.142373	DNS	Standard query response, No such name
> 38	3.158268	DNS	Standard query A
> 39	3.158482	DNS	Standard query response A
> ...... /* simple binding/search follows */
> ========================================
> The server is "", while the client is "". Packet 32~37 are all related to SASL binding, while packet 38~39 onwards are for simple binding and search (and they are successful, coz the IP address is correctly resolved out). The code is arranged in such a manner that if SASL binding fails, it will turn to simple binding.
> In the enrionment setup, the server is an AD in Windows 2003 Server Enterprise Edition. It's hostname is "sesswin2003". The server is also a primary domain controller, with the domain name "". In the printer's LDAP setup WebUI page, the server's hostname is set to "sesswin2003". And the printer is placed in the domain of "". This domain is set in the printer's TCP/IP WebUI page.
> In simple binding, we can see the DNS request from the client is in the correct format, i.e. with LDAP server's hostname suffixed with the domain name. And the server can resolve correctly, and sends the IP address back to the client.
> But, in SASL binding, the DNS request from the printer seems incorrect. It inserted the port number 389 and a space character between the hostname and the domain name. Thus, it is not a correct FQDN, and the server can't resolve it.
> Is the insersion a defect of MozLDAP library, or SASL library? I suspect
> it
is a problem of SASL, coz in simple binding, the same parameter is passed to
MozLDAP, and it can correctly resolve it to the server's IP address. If it an
SASL problem, is there any method to debug?

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?

> 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.

> Looking forward to help,

If you want code that actually works and adheres to standards, stick with 

> Xu Qiang

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

More information about the Cyrus-sasl mailing list