On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <michael@stroeder.com> wrote:
Qian Li wrote:
> Recently, I tried to write a ldap client to do ldap search asynchronously,
> but failed to perform search operation after a successful async sasl
> (digest-md5) bind.

What's your use-case for having async bind operation?

Note that the bind operation is somewhat special because it establishs a
security context/association.

The ldap client is a daemon which accepts arbitrary request from outside and periodically retrieves all users/groups from ldap server.
For sync bind, the client needs to wait for bind to complete, which could make outside request not be responded for a time .
It would be better to support async bind in the client.
> I compared the captured sync and async packets:
>
> In sync bind, the search packets were encrypted.
>
> In async bind, after sasl (digest-md5) binding to ldap server
> asynchronously (by calling ldap_sasl_interactive_bind() twice),
> ldap_search_ext() was called. But the search packet was in plain text. Then
> the ldap server reset the connection or just didn’t response (in the case
> of MSAD).

Note that SASL bind with DIGEST-MD5 does *not* give you any encryption of the
transport channel. Working with MS AD are you looking for SASL/GSSAPI?
 
Thanks for your explanation. 
From packet sniffer view, after sync SASL bind completed, the following search packets are all encoded in to SASL buffer.
Using SASL/DIGEST-MD5 is to protect the password of the bound user in contrast to simple bind.
In addition, the client needs to support both openldap and MS AD, so maybe SASL/DIGEST-MD5 is a better choice.