On Wed, Nov 26, 2014 at 5:30 PM, Michael Ströder <[email protected]> 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.
