Hello I'm sorry that if I opened a new issue for this reason, it's not entirely clear to me that I could sync from the LDAP server to Bitwarden, for example, immediately? What are the requirements for this? Thanks in advance!

Thanks for your help!

Hello,

It looks like Alpine images for latest release are not available here: https://hub.docker.com/r/vividboarder/bitwarden_rs_ldap/tags?page=1&ordering=last_updated Can you please publish them?

The container runs and fetches the users from the ldap server. Once it pulls the last known user it stops and produces this error then restarts the process again. I run this in a kubernetes pod by the way.

Error: Could not bind to ldap server thread 'main' panicked at 'Connection timed out (os error 110)', src/main.rs:22:9 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Hi, would you know the default user and password for the ldap admin web page?

I am getting this error when trying to spin up the docker container. I am using the image and not building it locally. Can you assist with this backtrace?

I checked my config.toml and it conforms with the example you provided here.

ldap_sync_1 | thread 'main' panicked at 'expected value at line 2 column 13', src/main.rs:22:9 ldap_sync_1 | stack backtrace: ldap_sync_1 | Error: Failed to get existing users from Bitwarden ldap_sync_1 | 0: 0x55e28b692825 - backtrace::backtrace::libunwind::trace::h14d338b30b3ea0a7 ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 ldap_sync_1 | 1: 0x55e28b692825 - backtrace::backtrace::trace_unsynchronized::h73ea91d74a3fd67f ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 ldap_sync_1 | 2: 0x55e28b692825 - std::sys_common::backtrace::_print_fmt::hd42948c952866e12 ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:78 ldap_sync_1 | 3: 0x55e28b692825 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha8f928866ff7571e ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:59 ldap_sync_1 | 4: 0x55e28b6b8a3c - core::fmt::write::he0c1e5f7426d2718 ldap_sync_1 | at src/libcore/fmt/mod.rs:1076 ldap_sync_1 | 5: 0x55e28b68c8c2 - std::io::Write::write_fmt::hf3afc6cfd57d0033 ldap_sync_1 | at src/libstd/io/mod.rs:1537 ldap_sync_1 | 6: 0x55e28b694eb0 - std::sys_common::backtrace::_print::hfc0110703f3696fd ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:62 ldap_sync_1 | 7: 0x55e28b694eb0 - std::sys_common::backtrace::print::h3f77c6990ddfaa22 ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:49 ldap_sync_1 | 8: 0x55e28b694eb0 - std::panicking::default_hook::{{closure}}::heae49580a8d62d75 ldap_sync_1 | at src/libstd/panicking.rs:198 ldap_sync_1 | 9: 0x55e28b694bfc - std::panicking::default_hook::hecc34e3f729e213c ldap_sync_1 | at src/libstd/panicking.rs:217 ldap_sync_1 | 10: 0x55e28b6954f3 - std::panicking::rust_panic_with_hook::he82f5d0644692441 ldap_sync_1 | at src/libstd/panicking.rs:526 ldap_sync_1 | 11: 0x55e28b6950eb - rust_begin_unwind ldap_sync_1 | at src/libstd/panicking.rs:437 ldap_sync_1 | 12: 0x55e28b69505b - std::panicking::begin_panic_fmt::h905a6d44880d49ef ldap_sync_1 | at src/libstd/panicking.rs:391 ldap_sync_1 | 13: 0x55e28b3f2616 - bitwarden_rs_ldap::main::hd6fdf337e527aac4 ldap_sync_1 | 14: 0x55e28b3fd923 - std::rt::lang_start::{{closure}}::h539854eed956cf91 ldap_sync_1 | 15: 0x55e28b695993 - std::rt::lang_start_internal::{{closure}}::h5d3ea623498f5f43 ldap_sync_1 | at src/libstd/rt.rs:52 ldap_sync_1 | 16: 0x55e28b695993 - std::panicking::try::do_call::hac65e71be769a440 ldap_sync_1 | at src/libstd/panicking.rs:348 ldap_sync_1 | 17: 0x55e28b695993 - std::panicking::try::hd4706e264bcf6712 ldap_sync_1 | at src/libstd/panicking.rs:325 ldap_sync_1 | 18: 0x55e28b695993 - std::panic::catch_unwind::h948a0fb4a8b3ee82 ldap_sync_1 | at src/libstd/panic.rs:394 ldap_sync_1 | 19: 0x55e28b695993 - std::rt::lang_start_internal::h72cc068ed2d0ac53 ldap_sync_1 | at src/libstd/rt.rs:51 ldap_sync_1 | 20: 0x55e28b3f45d2 - main ldap_sync_1 | 21: 0x7f4de5e0709b - __libc_start_main ldap_sync_1 | 22: 0x55e28b3eb19a - _start ldap_sync_1 | 23: 0x0 - <unknown>

Fixed. The ldap client was not connecting to the ldap server.

I am getting this error when trying to spin up the docker container. I am using the image and not building it locally. Can you assist with this backtrace?

I checked my config.toml and it conforms with the example you provided here.

ldap_sync_1 | thread 'main' panicked at 'expected value at line 2 column 13', src/main.rs:22:9 ldap_sync_1 | stack backtrace: ldap_sync_1 | Error: Failed to get existing users from Bitwarden ldap_sync_1 | 0: 0x55e28b692825 - backtrace::backtrace::libunwind::trace::h14d338b30b3ea0a7 ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 ldap_sync_1 | 1: 0x55e28b692825 - backtrace::backtrace::trace_unsynchronized::h73ea91d74a3fd67f ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 ldap_sync_1 | 2: 0x55e28b692825 - std::sys_common::backtrace::_print_fmt::hd42948c952866e12 ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:78 ldap_sync_1 | 3: 0x55e28b692825 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::ha8f928866ff7571e ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:59 ldap_sync_1 | 4: 0x55e28b6b8a3c - core::fmt::write::he0c1e5f7426d2718 ldap_sync_1 | at src/libcore/fmt/mod.rs:1076 ldap_sync_1 | 5: 0x55e28b68c8c2 - std::io::Write::write_fmt::hf3afc6cfd57d0033 ldap_sync_1 | at src/libstd/io/mod.rs:1537 ldap_sync_1 | 6: 0x55e28b694eb0 - std::sys_common::backtrace::_print::hfc0110703f3696fd ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:62 ldap_sync_1 | 7: 0x55e28b694eb0 - std::sys_common::backtrace::print::h3f77c6990ddfaa22 ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:49 ldap_sync_1 | 8: 0x55e28b694eb0 - std::panicking::default_hook::{{closure}}::heae49580a8d62d75 ldap_sync_1 | at src/libstd/panicking.rs:198 ldap_sync_1 | 9: 0x55e28b694bfc - std::panicking::default_hook::hecc34e3f729e213c ldap_sync_1 | at src/libstd/panicking.rs:217 ldap_sync_1 | 10: 0x55e28b6954f3 - std::panicking::rust_panic_with_hook::he82f5d0644692441 ldap_sync_1 | at src/libstd/panicking.rs:526 ldap_sync_1 | 11: 0x55e28b6950eb - rust_begin_unwind ldap_sync_1 | at src/libstd/panicking.rs:437 ldap_sync_1 | 12: 0x55e28b69505b - std::panicking::begin_panic_fmt::h905a6d44880d49ef ldap_sync_1 | at src/libstd/panicking.rs:391 ldap_sync_1 | 13: 0x55e28b3f2616 - bitwarden_rs_ldap::main::hd6fdf337e527aac4 ldap_sync_1 | 14: 0x55e28b3fd923 - std::rt::lang_start::{{closure}}::h539854eed956cf91 ldap_sync_1 | 15: 0x55e28b695993 - std::rt::lang_start_internal::{{closure}}::h5d3ea623498f5f43 ldap_sync_1 | at src/libstd/rt.rs:52 ldap_sync_1 | 16: 0x55e28b695993 - std::panicking::try::do_call::hac65e71be769a440 ldap_sync_1 | at src/libstd/panicking.rs:348 ldap_sync_1 | 17: 0x55e28b695993 - std::panicking::try::hd4706e264bcf6712 ldap_sync_1 | at src/libstd/panicking.rs:325 ldap_sync_1 | 18: 0x55e28b695993 - std::panic::catch_unwind::h948a0fb4a8b3ee82 ldap_sync_1 | at src/libstd/panic.rs:394 ldap_sync_1 | 19: 0x55e28b695993 - std::rt::lang_start_internal::h72cc068ed2d0ac53 ldap_sync_1 | at src/libstd/rt.rs:51 ldap_sync_1 | 20: 0x55e28b3f45d2 - main ldap_sync_1 | 21: 0x7f4de5e0709b - __libc_start_main ldap_sync_1 | 22: 0x55e28b3eb19a - _start ldap_sync_1 | 23: 0x0 - <unknown>

close

For ease of configuration, I would propose adding the possibility to configure each parameter via environment variables. This would renduce the deployment to a single docker-compose.yml

I am trying to run this in a kubernetes cluster but I get the message that the config.toml cannot be parsed. I have supplied my pod.yaml file to help you hopefully help me debug it:

`apiVersion: v1 kind: Pod metadata: labels: run: bitwarden-ldap name: bitwarden-ldap namespace: bitwarden spec: containers:

• image: vividboarder/bitwarden_rs_ldap imagePullPolicy: Always env:
  • name: CONFIG_PATH value: "/etc/bitwarden/config.toml"
  • name: Backtrace value: "RUST_BACKTRACE: 1"
    name: bitwarden-ldap resources: {} terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts:
  • mountPath: /etc/bitwarden name: bitwarden-ldap readOnly: true dnsPolicy: ClusterFirst enableServiceLinks: true priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default terminationGracePeriodSeconds: 30 tolerations:
• effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300
• effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 volumes:
• name: bitwarden-ldap secret: defaultMode: 420 secretName: bitwarden-ldap`

The variable bitwarden-ldap is stored in a file called secret where the data is base64 encoded. I will share the construct without revealing the actual secrets itself:

apiVersion: v1 data: config.toml: Yml0d2FyZG2JpdHBhc3MuZGV2LmJpa2UyNC5uZXQ6N2324DQzIgpiaXR3YXJkZW5fYWwe232342RtaW5fdG9rZW4gPSAiUkRGTlR6Sk1WM0JO"MyBASE64Encodedfile"14VFdNNFVXeHBVVUpvUW14eiIKbGRhcF9ob3N0ID0gImNo9zZWFyY2hfZmlsdGVyID0gIigmKG9iamVjdENsYXNzPSopKHVpZ2323D0qKSkiCmxkYXBfc3luY19pbnRlcnZhbF9zZWNvbmRzID0gMTAK kind: Secret metadata: name: bitwarden-ldap namespace: bitwarden type: Opaque

The output of the file is like this:

bitwarden_url = "https://bitwarden.mydomain:443"
bitwarden_admin_token = "Mysupersecretadmintoken"
ldap_host = "ldap.host.net"
ldap_bind_dn = "cn=users,dc=cd,dc=domain,dc=net"
ldap_bind_password = "mypassword"
ldap_search_base_dn = "ou=domainuserr,dc=cd,dc=domain,dc=net"
ldap_search_filter = "(&(objectClass=*)(uid=*))"
ldap_sync_interval_seconds = 10