I don't know if it's a bug or i am doing something wrong, but whenever i try to use ldaps or starttls it fails when i unbind.

I seem to bind and even search just fine, but unbind will throw an error: ResultRecv { source: RecvError(()) } It seems to somtimes suceed once or twice for some reason but it's rare.

Is someone able to test this?

I'm using this crate in a project that should be 100% up (a Windows service).

Connections are established periodically to perform some actions.

The way the project is architectured, a new (sync) connection is established every time an ldap operation is required, something like the following:

let ldap_conn = self.bind(self.connect()?, parameters)?;
ldap_conn.search(
        &query,
        ldap3::Scope::SubTree,
        &filter,
        attributes,
    )?;

Then ldap_conn is going out of scope (and should thus be dropped).

Using macOS's Instruments and cargo-instrumentsI ran a memory leak (with cargo instruments --limit 60000 --template Leaks --open).

I've placed generation markers at the period of ldap connections creation and isolated the following backtrace:

   0 libsystem_pthread.dylib _pthread_create
   1 project std::sys::unix::thread::Thread::new::h592cab8fcd31da40 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys/unix/thread.rs:68
   2 project std::thread::Builder::spawn_unchecked::h134d2da1c8074b18 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:492
   3 project std::thread::Builder::spawn::h48a9f7495ba6efa0 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:386
   4 project tokio_reactor::background::Background::new::haf2838ed3d299015 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-reactor-0.1.12/src/background.rs:75
   5 project tokio_reactor::Reactor::background::had1d3836f2167508 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-reactor-0.1.12/src/lib.rs:364
   6 project tokio::runtime::threadpool::Runtime::reactor::hda8d03c31b7688f0 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-0.1.22/src/runtime/threadpool/mod.rs:177
   7 project tokio_core::reactor::Core::remote::h9f1aae8ac9d65989 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.17/src/reactor/mod.rs:186
   8 project tokio_core::reactor::Core::handle::h615c39a2723d4480 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-core-0.1.17/src/reactor/mod.rs:167
   9 project ldap3::conn::LdapConn::with_settings::h7f914ba203306389 /Users/nbigaouette/.cargo/registry/src/github.com-1ecc6299db9ec823/ldap3-0.6.1/src/conn.rs:210
  10 project project::LdapClient::connect::hd7f7be3a60f42fbd /Users/nbigaouette/project/src/main.rs:163
  11 project _$LT$project..LdapClient$u20$as$u20$project..LdapAccess$GT$::execute::h7196beeb29a23d8d /Users/nbigaouette/project/src/main.rs:96
  18 project std::sys_common::backtrace::__rust_begin_short_backtrace::h0bc3e9aae8c075fa /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys_common/backtrace.rs:129
  19 project std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::h844632ca31721a5d /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:475
  20 project _$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h46dde68d861876bc /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:318
  21 project std::panicking::try::do_call::hfcc6c29e84830a4d /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:305
  22 project __rust_maybe_catch_panic /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libpanic_unwind/lib.rs:86
  23 project std::panicking::try::h016f17f065cf77aa /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panicking.rs:281
  24 project std::panic::catch_unwind::hc7943b0fdacd3bc1 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/panic.rs:394
  25 project std::thread::Builder::spawn_unchecked::_$u7b$$u7b$closure$u7d$$u7d$::h5291ad7674923a6d /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/thread/mod.rs:474
  26 project core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hc532a0fb892ac35e /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/ops/function.rs:232
  27 project _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h606f2dced48ff3c4 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  28 project _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h0ece8cce658c93ae /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/liballoc/boxed.rs:1015
  29 project std::sys_common::thread::start_thread::h30bbd9f3fb79e88c /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys_common/thread.rs:13
  30 project std::sys::unix::thread::Thread::new::thread_start::h7199626a1bd56873 /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/sys/unix/thread.rs:80
  31 libsystem_pthread.dylib _pthread_start
  32 libsystem_pthread.dylib thread_start

(Note that I have redacted some lines).

Using macOS's Activity Monitor I can see the file descriptiors number increase with each connection.

I'm not sure where to dig further. Is there something I am not doing properly when establishing my connections? Should I disconnect() something? Should tokio be shutdown manually?

Some version information:

• ldap3: 0.6.1
• tokio-core 0.1.17
• tokio 0.1.22

I haven't tried 0.7.0-alpha.7 yet as the API is not compatible.

Hi, I'm trying to make synchronization work using the sync request control of RFC4533 (1.3.6.1.4.1.4203.1.9.1.1).

So far I have managed to create the custom control and pass it to streaming_search(). As expected, initial results are returned and search does not end because SearchResultDone message is not sent, but I'm missing a way to receive the intermediate Sync Info Message that should be sent at this point, and I don't receive any changed entries upon changes in LDAP data. No error is returned. The stream seems to be stuck.

Am I missing something?

(I'm willing to help with this, and possibly with making more controls/ASN.1 stuff)

Hi,

I am using an async connection. I got a panic "message id" returned in protocol.rs.

I printed the tags right before and I had :

[StructureTag { class: Universal, id: 2, payload: P([0]) }, StructureTag { class: Application, id: 24, payload: C([StructureTag { class: Universal, id: 10, payload: P([52]) }, StructureTag { class: Universal, id: 4, payload: P([]) }, StructureTag { class: Universal, id: 4, payload: P([48, 48, 48, 48, 48, 48, 48, 51, 58, 32, 76, 100, 97, 112, 69, 114, 114, 58, 32, 68, 83, 73, 68, 45, 48, 67, 48, 54, 48, 54, 49, 65, 44, 32, 99, 111, 109, 109, 101, 110, 116, 58, 32, 69, 114, 114, 111, 114, 32, 100, 101, 99, 114, 121, 112, 116, 105, 110, 103, 32, 108, 100, 97, 112, 32, 109, 101, 115, 115, 97, 103, 101, 44, 32, 100, 97, 116, 97, 32, 48, 44, 32, 118, 52, 53, 54, 51, 0]) }]) }]

Any idea ? I'm still trying to figure it out, but if you have an idea, let me know.

Thank for your help

I'm trying to synchronise users from an LDAP server with my application. To do that, I added something like this

let user_sync_task = Interval::new_interval(config.ldap.sync_interval).for_each(move |_| {
            info!("Starting user synchronization...");

            ...SYNCHRONIZATION_CODE...
            Ok(())
        }).into_future().map_err(|e| {
            error!("Error creating user synchronization task {:?}", e);
        });

        task_executor.spawn(user_sync_task);

Of course, during the synchronisation, I open an LDAP connection. (LdapConn::new(&self.url)?;) But I get this error :

thread 'tokio-runtime-worker-0' panicked at 'cannot recursively call into Core', src/libcore/option.rs:1036:5

From what I understand, I can't open an LDAP connection in a future running in a TaskExecutor. Am I right ? How can I fix that on my side, knowing that ldap connection will create a new tokio Core and run it ?

Thank you for the help

I'm able to simple bind and search using LDAP but LDAPS fails. I tried both nativetls and rustls which fail. I don't have the errors in front of me currently but can get those if needed. But from what I recall I was seeing an error referencing protocol. I also tested by using the openldap crate and LDAPS works as expected using that. The openldap crate examples show passing options for the protocol version so I'm wondering if there's a way to pass the protocol version using this LDAP3 crate?

When I replace the certificate with a wrong one, I'd expect to get a "TLS authentication error" or something similar. Instead, I get just "broken pipe", and not on the attempt to connect to the LDAP server, but on the first attempt to communicate with it.

I'm doing something like this:

    let cert = Certificate::from_der(LDAP_CERT)?;
    
    let mut tls_connector = TlsConnector::builder()?;
    tls_connector.add_root_certificate(cert)?;
    let tls_connector = tls_connector.build()?;

    let conn = LdapConnBuilder::<LdapConn>::new()
        .with_tls_connector(tls_connector)
        .connect(&*LDAP_URL)?;

    let res = conn.simple_bind(&bind_dm, &login_info.password)?;

It doesn't explicitly fail when connecting, but on the simple_bind. The error looks like this, debug-printed:

Error { repr: Custom(Custom { kind: BrokenPipe, error: StringError("broken pipe") }) }

I just spent hours of trying to pinpoint where this bug originates from, but without much success – there's layers upon layers of Tokio abstractions :(

Hi,

A user of my app using ldap3 just send me logs containing:

LDAP connection error: I/O error: Either the application has not called
WSAStartup, or WSAStartup failed. (os error 10093)

What does it mean?

Hi, I moved to the alpha version to use async/await. I kept my code almost the same except that now, I use LdapConnAsync and all async call.

I use streaming_search() in my code below and it panics with this : panicked at 'entry', /opt/wayk/dev/ldap3/src/search.rs:148:13

The line who panic is SearchEntry::construct(entry). Any idea ?

Here is my code. The connection is already opened, I receive it in parameter.

async fn get_groups_internal(&self, ldap_conn: &mut Ldap) -> Result<Vec<AccountGroup>, AdAccountError> {
        let mut groups = Vec::new();

        let filter = "(&(objectCategory=group)(objectClass=group))";

        let mut entry_stream = ldap_conn
            .streaming_search(&self.base_dn, Scope::Subtree, &filter, AD_GROUP_ATTRIBUTES.to_vec())
            .await?;

        while let Some(entry) = entry_stream.next().await? {
            match self.build_group(&SearchEntry::construct(entry)) {
                Ok(group) => groups.push(group),
                Err(e) => error!("Build_group failed: {:?}", e),
            }
        }
        entry_stream.finish();

        Ok(groups)
    }

Thank you in advance

Hey there!

We are currently evaluating ldap3 because we are interested in using it in Proxmox Backup Server to enable LDAP login for our users. So far, we are pretty happy with it. As we try to keep the number of duplicated/outdated dependencies to a minimum, we were wondering: Are there currently any plans to update to a more recent version of nom?

Best Regards, Lukas

Hi there,

We are in the need of Matched Values Control and it's not available in ldap3.

RFC https://tools.ietf.org/html/rfc3876.html

Would you mind if we add it?

Regards,

This pull request adds support for the GSS-SPNEGO bind type with NTLM. There is no support for integrated Windows authentication or Kerberos at this point. This has been tested against Windows Active Directory, compared against sample Wireshark captures.

I am currently trying to add support for the GSS-SPNEGO bind type, which would be very useful to connect to Active Directory. I have sample wireshark captures of NTLM and Kerberos traffic, and I also have a working NTLM implementation that I can integrate.

However, I am facing a blocker: even if I can send the first GSS-SPNEGO bind request and get a proper response from the server (saslBindInProgress with the NTLM "Challenge" message in the response payload), I struggle to find a way to extract the NTLM message from the bind response.

The current code only has support for single request/response bind types, none of the implemented bind types are multilegged (meaning they require more than one request/response to complete). As far as I can see, bind success is currently only based on the LdapResult response code being zero.

I figured out how to interpret the result code differently such that code 14 (saslBindInProgress) is not considered an error, but I cannot figure out how to properly modify the LdapResponse type and parsing code to allow me to fetch something other than a vector of controls. A bind response isn't a search result, so it's not a vector of controls :/

Any guidance or hints on this problem?