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.
This is the workflow of ldapsearch + sasl:
========================================
qxu@durian(pts/1):/etc[19]$ kinit qxu@xxxxxxxxxxxxxxx Password for qxu@xxxxxxxxxxxxxxx:
qxu@durian(pts/1):/etc[20]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: qxu@xxxxxxxxxxxxxxx
Valid starting Expires Service principal
03/25/09 17:21:13 03/26/09 03:21:11 krbtgt/SESSWIN2003.COM@xxxxxxxxxxxxxxx
renew until 03/26/09 17:21:13
Kerberos 4 ticket cache: /tmp/tkt20153
klist: You have no tickets cached
qxu@durian(pts/1):/etc[21]$ ldapsearch -Y GSSAPI -H 'ldap://sesswin2003.sesswin2003.com' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=xuan' mail
SASL/GSSAPI authentication started
SASL username: qxu@xxxxxxxxxxxxxxx
SASL SSF: 56
SASL installing layers
dn: CN=xuan,CN=Users,DC=sesswin2003,DC=com
mail: Xuan.Shangguan@xxxxxxxxxxxxx
# refldap://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,D
C=com
# refldap://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,D
C=com
# refldap://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
========================================
>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". 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?
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
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6667>
INFO>> Value of loginName xuan@xxxxxxxxxxxxxxx
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6668>
INFO>> Value of loginPassword Fair123
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6669>
INFO>> Value of referalsEnabled 0
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6670>
INFO>> Value of ldapVersion3 1
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6671>
INFO>> Value of maxNames 25
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,6672>
INFO>> Value of timeOut 30
<apManager> (Tue Mar 31 2009 16:39:02.518) <p27931,t3079396256,aba_ldap_interface.c,1446>
INFO>> Calling ldap init
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1533>
INFO>> prldap_init succeeded
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1602>
INFO>> DISABLING REFERALS
<apManager> (Tue Mar 31 2009 16:39:02.519) <p27931,t3079396256,aba_ldap_interface.c,1620>
INFO>> SASL Login
<apManager> (Tue Mar 31 2009 16:39:02.538) <p27931,t3079396256,aba_ldap_interface.c,1634>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
<apManager> (Tue Mar 31 2009 16:39:02.538) <p27931,t3079396256,aba_ldap_interface.c,1641>
ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
......
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6666>
INFO>> Value of hostname sesswin2003:389
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6667>
INFO>> Value of loginName xuan@xxxxxxxxxxxxxxx
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6668>
INFO>> Value of loginPassword Fair123
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6669>
INFO>> Value of referalsEnabled 0
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6670>
INFO>> Value of ldapVersion3 1
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6671>
INFO>> Value of maxNames 25
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,6672>
INFO>> Value of timeOut 30
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,1981>
INFO>> Calling ldap init
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2080>
INFO>> prldap_init succeeded
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2149>
INFO>> DISABLING REFERALS
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2169>
INFO>> Value of the Login Password Fair123
<apManager> (Tue Mar 31 2009 16:39:02.544) <p27931,t3079396256,aba_ldap_interface.c,2190>
INFO>> Secure Login
<apManager> (Tue Mar 31 2009 16:39:02.761) <p27931,t3079396256,aba_ldap_interface.c,2196>
INFO>> LDAP BIND: Value of ldapStatus 0
========================================
The parameters passed to MozLDAP are all the same. But the binding results are different.
Looking forward to help,
Xu Qiang
