SASL2 plugin problem

[Howard Chu]

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

> In the network trace captured
between the client printer and the server, I found the following interesting
packets:
> ========================================
> 32	3.141158	13.198.98.107	13.198.98.35	DNS	Standard query A sesswin2003:389 .sesswin2003.com
> 33	3.141400	13.198.98.35	13.198.98.107	DNS	Standard query response, No such name
> 34	3.141981	13.198.98.107	13.198.98.35	DNS	Standard query AAAA sesswin2003:389 .sesswin2003.com
> 35	3.142071	13.198.98.35	13.198.98.107	DNS	Standard query response, No such name
> 36	3.142287	13.198.98.107	13.198.98.35	DNS	Standard query A sesswin2003:389 .sesswin2003.com
> 37	3.142373	13.198.98.35	13.198.98.107	DNS	Standard query response, No such name
> 38	3.158268	13.198.98.107	13.198.98.35	DNS	Standard query A sesswin2003.sesswin2003.com
> 39	3.158482	13.198.98.35	13.198.98.107	DNS	Standard query response A 13.198.98.35
> ...... /* simple binding/search follows */
> ========================================
> The server is "13.198.98.35", while the client is "13.198.98.107". 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 "sesswin2003.com". 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 "sesswin2003.com". 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 
OpenLDAP.

> Xu Qiang

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/