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.