I'm currently working on an LDAP library, and I'm going to publish it as soon as it stabilizes a bit, which should happen in a week or two.
Some history:
As you can see on GH, it's a fork of a rather old project which was developed on and off for the past two years, but never went beyond basic simple bind/search operations. The latest rewrite, from the start of this year, was based on the tokio stack. There was a steady stream of updates, and then again a lull.
I contributed a PR to this version which enabled LDAP over TLS (ldaps://, not StartTLS), added support for attribute lists in searches, and fixed a bug in search result handling. However, on further inspection, I saw that updating the code to handle everything I needed would be so intrusive that I might as well fork it and develop it independently. I got in contact with the author and told him about my plan to fork the driver, which he accepted amicably (as was the intention).
What's the present situation?
The latest master has everything from my original PR, plus a completely rewritten filter parser, with full support for RFC 4515. However, it's not usable even for medium-size result sets because of the way it's using tokio-proto: it will blow up if there are more than 127 search result entries. Its handling of LDAP message ids is not according to spec (the OpenLDAP server, against which I'm testing the code, is fortunately tolerant of that; others might not be). Add/Modify/Delete are not supported. In summary: if you only need searches, and can live with small result sets, you may try to use it.
Development is happening on the msgid-plus branch, which has, so far, seen a total restructuring of the tokio-proto interface to support large result sets, addition of RFC-compliant message id handling, and the beginning of support for response controls and the full range of LDAP result values.
My priorities are:
- Finishing basic support for LDAP results/response controls.
- Returning search results in a usable form, while preparing the driver for custom deserialization via Serde.
- Adapting the existing synchronous code for result streaming.
- Publishing the first version of the crate.
I'll post updates here, if there's interest.
