LDAP C API issues

[Kirill Kovalenko]

Hello,

While using MS LDAP API [1], we came across a few problem issues
described below. Most of those issues are set forth together with the
related C++ code portions grouped into the WLDAP32TEST [2] solution in
order to highlight a problem better.

1. Getting / Setting Options

The ldap_get_optionW() function with the LDAP_API_INFO flag passed
returns the LDAP_PROTOCOL_ERROR error code.

On Windows NT 4.0 and Windows 2000 [3] the ldap_get_option() function
returns an error when called for some connection-independent flags
(e.g. LDAP_API_INFO) with NULL instead of a connection handle. At the
same time Windows XP version and Netscape\OpenLDAP version allow
passing NULL.

2. Empty Attribute Value

When a set of attribute values contains an empty (zero-length) value
and it is the last value in the set, then it is not returned by the
ldap_get_values_len() function.

Assume an entry E has an attribute A (whose syntax allows for empty
values to be present), which consists of the following set of values:
{ "val1", "val2", [EMPTY] }. If one calls the ldap_get_values_len()
function on an LDAP message representing this entry, it'll return a
set of berval structures with just two values {"val1", "val2"} with no
berval structure for the last value being empty.

3. UTF-8 and API draft

The LDAP C API draft [4] says that all DNs and string attribute values
passing/returning to/from LDAP C API should be UTF8 encoded strings.
MS implementation violates those instructions. ANSI versions converts
then using thread/system(?) code page. This approach may cause
problems. Imagine a user working with German umlauts under a Cyrillic
system.

4. Extended Request ANS.1 format

For extended operations that require empty value parameter (e.g. START
TLS) extended request sent via MS LDAP API contains trailing empty
tag. Some servers (OpenLDAP for instance) treat them as malformed
requests. We are not sure that this a problem at your side, however we
think this is a serious interoperability issue. So please be aware.
Also we've opened an OpenLDAP issue [5].

5. SASL bind API

MS LDAP API provides a modified ldap_bind_s() function to perform SASL
bind operations synchronously using the authentication mechanism from
a predefined set. However, if someone wants to do this asynchronously,
or to use an alternative/custom authentication mechanism, he/she will
face problems. Here is a list of problems we spotted in relation to
this approach.

- The ldap_parse_sasl_bind_result() function is missing.

- Server credentials returned by the calling the ldap_sasl_bind_s()
function are always empty, even if a server responds with the
LDAP_SASL_BIND_IN_PROGRESS result and a valid server credentials
string.

- Calling the ldap_result() function using a valid message ID properly
returned by calling the ldap_sasl_bind() function results in the
LDAP_PARAM_ERROR error code.

We think it would be better to have a way to control whether to work
over SSPI or allow client to handle SASL challenge\response process by
itself.

[1] WLDAP32.DLL v 5.1.2600.1106 unless otherwise instructed.
[2] http://download.softerra.com/files/WLDAP32TEST.ZIP
[3] WLDAP32.DLL v 5.0.2195.6666
[4] draft-ietf-ldapext-ldap-c-api-xx.txt
[5] http://www.openldap.org/its/index.cgi/Incoming?id=3037

Sincerely yours,

Kirill Kovalenko
Softerra LLC
http://www.ldapadministrator.com
mailto:kir...@softerra.com

[Matthew Rimer [MSFT]]

Thank you for your detailed comments. Let me address them in order:

(1) Yes, in Windows XP and later releases, ldap_get_option was changed to
allow passing in NULL when using LDAP_OPT_API_INFO. This change was made to
bring it into better conformance with the then-current LDAP C API IETF
Draft.

(2) I've passed this issue on to the relevent people here for investigation.

(3) The Windows LDAP Client, wldap32.dll, is designed to conform to the
standard Windows conventions for APIs which take strings. It exposes both
Unicode (UCS-16) and ANSI (based on the current codepage) APIs. For
example, there is a ldap_search_ext_sW API, which takes the strings as
WCHARs, and a ldap_search_ext_sA API, which takes in ANSI strings. The
header file winldap.h takes care of making ldap_search_ext_s map to either
ldap_search_ext_sW or ldap_search_ext_sA, depending on whether UNICODE is
#define'd when your application is compiled. The potential problems you
cite when using the ANSI APIs are precisely why we provide and encourage the
use of the Unicode APIs.

By the way, as far as I know, the IETF drafts for the LDAP C API have
expired, without becoming RFCs, and there are currently no active IETF
Drafts for this.

(4) Yes, we've just recently become aware of this issue. I don't think it's
actually a problem in wldap32, since it would seem to be a valid BER
encoding of the extended request. However, we're currently investigating
this issue.

(5) In general, we encourage people writing to wldap32 to use the
ldap_bind_s function rather than the ldap_sasl_bind functions. We haven't
received a lot of customer feedback about the ldap_sasl_bind APIs, and will
certainly take any feedback we receive into account when planning future
releases.

* ldap_parse_sasl_bind_result is under consideration for a future release

* The problem with ldap_sasl_bind_s not returning the server's returned
credentials has been fixed in the Windows Server 2003. I don't believe the
fix has been incorporated into any Service Packs for Windows 2000 or Windows
XP. However, if you are interested in obtaining the fix for either of these
earlier releases, please contact Microsoft Product Support Services.

* I've passed the problem with ldap_result() returning LDAP_PARAM_ERROR on
to the relevent developer here for further investigation.

Thanks,
Matthew Rimer [MSFT]
--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Kirill Kovalenko" <kir...@softerra.com> wrote in message
news:b3f80464.04033...@posting.google.com...

[Kirill Kovalenko]

Hello Matthew,

Sorry, for the reply delay. I've been out for a month...

>> The ldap_get_optionW() function with the LDAP_API_INFO flag passed
>> returns the LDAP_PROTOCOL_ERROR error code.

What about this issue?

> (2) I've passed this issue on to the relevent people here for investigation.

Any news from those people?

> (3) The Windows LDAP Client, wldap32.dll, is designed to conform to the
> standard Windows conventions for APIs which take strings. It exposes both
> Unicode (UCS-16) and ANSI (based on the current codepage) APIs. For
> example, there is a ldap_search_ext_sW API, which takes the strings as
> WCHARs, and a ldap_search_ext_sA API, which takes in ANSI strings. The
> header file winldap.h takes care of making ldap_search_ext_s map to either
> ldap_search_ext_sW or ldap_search_ext_sA, depending on whether UNICODE is
> #define'd when your application is compiled. The potential problems you
> cite when using the ANSI APIs are precisely why we provide and encourage the
> use of the Unicode APIs.

I really like an approach done by an MS engineer(s) for the DNS API.
All the functions here are available in 3 ways. E.g. api_function_A,
api_function_W and api_function_UTF8. I believe it would be great if
your team adopt this approach.

> By the way, as far as I know, the IETF drafts for the LDAP C API have
> expired, without becoming RFCs, and there are currently no active IETF
> Drafts for this.

Yes, it's true. They say there are too much fundamental legacy
problems.

> (4) Yes, we've just recently become aware of this issue. I don't think it's
> actually a problem in wldap32, since it would seem to be a valid BER
> encoding of the extended request. However, we're currently investigating
> this issue.

Any updates? OpenLDAP architect claims [1] it's not OpenLDAP problem
as well.

There is another wldap32.dll issues that is confirmed as a bug [2]. It
concerns SERVER_CERTIFICATE callback under Windows XP. Could you
please tell me will it be fixed in the SP2? Possibly I should have
checked it with latest SP2 beta...

[1] http://www.openldap.org/its/index.cgi/Incoming?id=3037#followup3
[2] http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&oe=UTF-8&threadm=O34OevuqDHA.2716%40TK2MSFTNGP09.phx.gbl&rnum=3&prev=/groups%3Fq%3DVERIFYSERVERCERT%26hl%3Duk%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DO34OevuqDHA.2716%2540TK2MSFTNGP09.phx.gbl%26rnum%3D3

Sincerely yours,

Kirill Kovalenko
Softerra LLC
http://www.softerra.com
http://www.ldapadministrator.com
mailto:kir...@softerra.com

[susan...@gmail.com]

Hello Matthew and team,

I am into the same issue, that you people were discussing about. As you have explained in last the "sasl_interactive_bind_s" has been fixed in win2k server. But still i am having same issue. I have installed active "ActivePython-2.7","python-ldap-2.4.10", "openssl-0.9.8o","setup-sasl-1.5.27." on win 2k server.
below is my code. m And the 2k server is in the same domain where my AD located.

import ldap
import ldap.sasl

conn=ldap.initialize('ldap://auto.test-auto.com',trace_level=2)

conn.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3)
conn.set_option(ldap.OPT_REFERRALS,0)
sasl = ldap.sasl.gssapi()
conn.sasl_interactive_bind_s('', sasl)

Traceback (most recent call last):
File "C:\susanta\test-sasl.py", line 10, in <module>
conn.sasl_interactive_bind_s('', sasl)
File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 229, in sasl_interactive_bind_s
return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags)
File "C:\Python27\lib\site-packages\ldap\ldapobject.py", line 99, in _ldap_call
result = func(*args,**kwargs)
LOCAL_ERROR: {'desc': 'Local error'}

Could some one help me out?

Thanks
Susanta