See lldap/lldap#846 (comment) :
Attribute options (e.g. "uuid;text" or "uuid;binary") are parsed as an extra attribute (so you'd get ["uuid", "text"] as attributes) in a search request.

Even if we don't represent the options, we at least should correctly ignore them.

Hey,

I got a user receiving a good old "ldapmsg invalid" when parsing a bind query with a "controlType: 1.3.6.1.4.1.42.2.27.8.5.1 (passwordPolicy)".

Obviously, I don't support the response for that control, but I'd like it if it didn't crash :)

In general, it would be great to be able to parse while receiving the unsupported/unparsed controls on the side.

We've run into an issue with a client sending extra controls with their request, that we don't care about but fail the query parsing: lldap/lldap#301
The error is Unsupported control oid | o: 2.16.840.1.113730.3.4.2, and then Failed to parse ldapcontrol

Would there be a way to either add support for the controls, or add a "parse with unsupported controls as an extra return" method?

Currently, LdapPartialAttributes require the values to be String, i.e. a valid UTF-8 attribute.

However, a fairly common LDAP attribute is JpegPhoto where the raw bytes of the JpegPhoto are sent. It's not representable as a String. It should instead be a OsString or Vec<u8>.

WDYT? If you want this (it would be a breaking change, I understand) I can try to work on a PR, but otherwise I'll just have my own fork.

Hi!

First of all, thanks a lot for your crate, it's been very useful to create my own tiny LDAP server for user management: https://github.com/nitnelave/lldap

However, something that's missing for transparent integration with e.g. Authelia is the ability to reset the user's password from the LDAP interface. That would require the LdapModify message from this crate.

I haven't tested it, but the README says that it's not supported. However, in the code I still see some implementation of LdapModify. Is it complete? Do you need help with it?

Cheers,

Let's say I want to create a LdapPartialAttribute with a numerical value.

LdapPartialAttribute {
  atype: "uid".to_owned(),
  vals: vec![123],
}

How do I represent that 123 as bytes? Is there a special encoding necessary? Or do I convert it to i64 then do a cast to 8 raw bytes?

ServerOps::try_from is defined to return () on error. This could be improved to reflect what went wrong in the conversion.

We are currently looking at this project as a potential starting point for a web-based Active Directory console, compiling Rust to WebAssembly, and building a Web UI on top. This crate is interesting because it doesn't have a dependency on tokio for the reusable parts, which is a common problem for in-browser WASM.

There are various improvements and changes we'd need to make, beginning with SPNEGO authentication (NTLM/Kerberos) using sspi-rs. As for other improvements, it would likely be to implement the Microsoft Active Directory LDAP variant and custom extensions.

For our use case, we only care about Active Directory, which may not be the goal of this project. Would you be interested in such contributions, even if they would be focused solely on Active Directory? We're unsure if we'd be better off trying to get all of our changes merged upstream, or if we should create something something solely meant for Active Directory using this project as a basis.

Either way, let us know your preference!

Hello kanidm, thank you very much for your repository, which helped me a lot, but I have a question, is there any plan to upgrade lber to version 0.4.0? Because I received a warning like this when compiling: warning: the following packages contain code that will be rejected by a future version of Rust: nom v2.2.1.

Should we support https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt

I recently encountered an issue while using ldap_client:
After storing two LdapClient instances, I automatically select which LdapClient to use for processing based on the content of the search request. However, I often encounter the error "An error occurred writing to the transport". This error seems to indicate that the TCP stream has been disconnected. I would like to know how to optimize this issue.

I see it is explicitly listed as not implemented in the readme but I'm curious as to what is the sentiment towards the compare ldap feature. Is is just not implemented because of a lack of time or has it been explicitly left out for some other reason?

I'm using LLDAP which is based on this library and any Django service apparently uses this LDAP call during sing-on, so a wide range of web applications supporting LDAP authentication are being left unsupported this way.

 let filter = parse_ldap_filter_str("(cn=*Info*)").unwrap();

this will throw an error, however, it is specified in rfc4515