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/
