vividboarder / vaultwarden_ldap Goto Github PK
View Code? Open in Web Editor NEWAutomate LDAP invites to Vaultwarden
License: GNU General Public License v3.0
Automate LDAP invites to Vaultwarden
License: GNU General Public License v3.0
Hey there!
Currently setting up an instance with your LDAP syncer, which worked wonderfully and fast. First of all: Thanks for your effort and this nice piece of software! :)
Ok, so my LDAP (in fact AD) users are being synced and invited.
Is it possible to also sync their LDAP passwords as the master password for Bitwarden?
If not, is this a limitation of Bitwarden itself?
Because as the result the container restarts again and again...
For me it wasn't clear that the container is shutting down after one execution (and is then restartet by docker).
Maybe you can mention this in the readme.md for others. Or change the behaviour...
Hello,
we want to add ldap to our vaultwarden, but there is a sync error:
0: Could not get list of existing users from server
1: vaultwarden error Could not read authentication cookie
do you know where is the problem? Can you help me?
Hello,
is there a way to run this without docker / docker-compose if running docker/docker-compose is not possible or allowed?
Is there an alternative way for LDAP sync?
Thank you
Pedi
Hi guys,
Just trying to get the ldap synch to run and I am getting the following error hread 'main' panicked at 'Error parsing config from env: missing value for field vaultwarden_url', src/config.rs:29:29
full trace below.
My config is set as:
services: ldap_sync: image: vividboarder/vaultwarden_ldap volumes: - './config.toml:/config.toml:ro' # ./root.cert:/usr/src/vaultwarden_ldap/root.cert:ro environment: CONFIG_PATH: /config.toml RUST_BACKTRACE: 1 depends_on: - vaultwarden restart: unless-stopped
and please see full error below
ldap_sync_1 | Failed to parse config file at /config.toml vaultwarden_1 | [2021-09-20 23:04:36.890][start][INFO] Rocket has launched from http://0.0.0.0:80 ldap_sync_1 | thread 'main' panicked at 'Error parsing config from env: missing value for field vaultwarden_url', src/config.rs:29:29 ldap_sync_1 | stack backtrace: ldap_sync_1 | 0: backtrace::backtrace::libunwind::trace ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86 ldap_sync_1 | 1: backtrace::backtrace::trace_unsynchronized ldap_sync_1 | at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66 ldap_sync_1 | 2: std::sys_common::backtrace::_print_fmt ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:78 ldap_sync_1 | 3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:59 ldap_sync_1 | 4: core::fmt::write ldap_sync_1 | at src/libcore/fmt/mod.rs:1076 ldap_sync_1 | 5: std::io::Write::write_fmt ldap_sync_1 | at src/libstd/io/mod.rs:1537 ldap_sync_1 | 6: std::sys_common::backtrace::_print ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:62 ldap_sync_1 | 7: std::sys_common::backtrace::print ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:49 ldap_sync_1 | 8: std::panicking::default_hook::{{closure}} ldap_sync_1 | at src/libstd/panicking.rs:198 ldap_sync_1 | 9: std::panicking::default_hook ldap_sync_1 | at src/libstd/panicking.rs:217 ldap_sync_1 | 10: std::panicking::rust_panic_with_hook ldap_sync_1 | at src/libstd/panicking.rs:526 ldap_sync_1 | 11: rust_begin_unwind ldap_sync_1 | at src/libstd/panicking.rs:437 ldap_sync_1 | 12: std::panicking::begin_panic_fmt ldap_sync_1 | at src/libstd/panicking.rs:391 ldap_sync_1 | 13: vaultwarden_ldap::main ldap_sync_1 | 14: std::rt::lang_start::{{closure}} ldap_sync_1 | 15: std::rt::lang_start_internal::{{closure}} ldap_sync_1 | at src/libstd/rt.rs:52 ldap_sync_1 | 16: std::panicking::try::do_call ldap_sync_1 | at src/libstd/panicking.rs:348 ldap_sync_1 | 17: std::panicking::try ldap_sync_1 | at src/libstd/panicking.rs:325 ldap_sync_1 | 18: std::panic::catch_unwind ldap_sync_1 | at src/libstd/panic.rs:394 ldap_sync_1 | 19: std::rt::lang_start_internal ldap_sync_1 | at src/libstd/rt.rs:51 ldap_sync_1 | 20: main ldap_sync_1 | 21: __libc_start_main ldap_sync_1 | 22: _start ldap_sync_1 | note: Some details are omitted, run with
RUST_BACKTRACE=full for a verbose backtrace. vaultwarden_ldap_sync_1 exited with code 101
Not sure of what am I missing out here, thanks ahead of time for any pointers
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?
Hello @ViViDboarder,
First thanks for this tool.
I have set up the container and the config.toml but now a problem with the ldap_mail_field value.
The ldap_mail_field has the value "mail" and i get the error:
Warning: Email field, "mail", not found on user
If i use the value 'uid' or 'userPrincipalName' everything is fine and this tool create the user in bitwarden. The LDAP-schema contain mail and the structure is [email protected]. If i connect with Softerra LDAP Browser to the ldap-proxy i can see the attribut mail.
The docker container "bitwarden_rs_ldap" is connect with a ldap-proxy. The ldap-proxy send the requests to my active directroy server.
Thanks for your help
Hi,
i have a batch of user to invite from my Active Directory service, it works great but i would like to be able to invite all my user in an Organization.
Is there a way to do this ? If not it could be a great enhancement !
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 -
Greeting,
I wanted to know if there is any possible way to sync users from "active directory" with their passwords.
I mean is that possible that I add my users from AD with their authentication credential and they don't have to sign up and set the master password by themselves?
Best regards,
Mohammad Mostofianbeh
It would be helpful for a bitwarden_root_cert_file
-like config option for a custom LDAP certificate authority. My LDAP server uses a certificate from an internal CA and while ldap_no_tls_verify
is a workaround, it's not ideal.
I'm getting the following error, simple setup authenticating against Windows AD
thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5
note: Run with RUST_BACKTRACE=1
environment variable to display a backtrace.
Hi,
searching through the source code I think that anonymous bind is not possible, is it?
is it something that could be implemented? or it's not wished by @ViViDboarder?
Ok, I didn't manage to work around my other issue yet so I'm trying using a slightly easier setup LDAP-wise and give this container another shot. However the infrastructure I'm trying to use Bitwarden in, is a fully Windows-managed domain, meaning there's an own CA issuing certificates for service.domain.tld with an already existing AD Domain Controller. bitwarden_rs_ldap is crashing for some reason, and I guess it may be due to SSL issues. Because Microsoft is making SSL mandatory on all Domain Controllers (at least all my LDAP environments are 100% Windows; only one?) in the future too, it would be good to have a switch that could either disable validation or add the expected certificate to the Container for:
I have tried adding the certificate to the local trusted CA store, but that didn't affect the outcome.
root@nff-prog27# docker pull vividboarder/bitwarden_rs_ldap
Using default tag: latest
latest: Pulling from vividboarder/bitwarden_rs_ldap
e79bb959ec00: Pull complete
d4b7902036fe: Pull complete
1b2a72d4e030: Pull complete
d54db43011fd: Pull complete
69d473365bb3: Pull complete
be25df7a010a: Pull complete
39c2d8e1ac2c: Pull complete
d3c3d407f6d0: Pull complete
2513aa5a9124: Pull complete
1a702249037b: Pull complete
c9782773dbc5: Pull complete
381bfafce598: Pull complete
12daaaf43302: Pull complete
c5e439578caa: Pull complete
Digest: sha256:b5a94ac7566015dc92e6e0d6fb49facf248ff0c7e36674affbf430b8dd5a7045
Status: Downloaded newer image for vividboarder/bitwarden_rs_ldap:latest
docker.io/vividboarder/bitwarden_rs_ldap:latest
root@nff-prog27# docker run -d --name bitwarden_ldap \
-v /bw-data/ldap/config.toml:/usr/src/bitwarden_rs_ldap/config.toml:ro \
vividboarder/bitwarden_rs_ldap:latest
root@nff-prog27# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
8d9189ee5318 vividboarder/bitwarden_rs_ldap:latest "bitwarden_rs_ldap" 6 seconds ago Exited (101) 4 seconds ago bitwarden_ldap
ae25c59da8ea bitwardenrs/server:latest "/bitwarden_rs" 35 minutes ago Up 35 minutes (healthy) 3012/tcp, 0.0.0.0:443->80/tcp bitwarden
root@nff-prog27# docker logs 8d9189ee5318
thread 'main' panicked at 'Could not authenticate with https://bitwarden.domain.tld. Error { kind: Hyper(Error { kind: Connect, cause: Custom { kind: Other, error: Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 337047686, library: "SSL routines", function: "tls_process_server_certificate", reason: "certificate verify failed", file: "../ssl/statem/statem_clnt.c", line: 1245 }]))) }, X509VerifyResult { code: 18, error: "self signed certificate" }) } }), url: Some("https://bitwarden.domain.tld/") }', src/bw_admin.rs:62:17
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
It appears that the vividboarder/vaultwarden_ldap:alpine
image on Docker Hub has not been updated for ~8 months despite there being at least 3 releases since then. Is the alpine
tag deprecated?
Hello,
I just installed the solution from git repo and I encountered some difficulties.
I tried to with
image: vividboarder/vaultwarden_ldap
and
build:
context: .
dockerfile: Dockerfile.alpine
and both result in the same error about parsing config.toml (error already reported), I checked and rechecked compose file and toml and i'm pretty sure of them.
Then I built from Dockerfile
and it works...
I didn't check differences between the two, don't have time today but maybe later.
I hope this feedback can help you, I'll let you know if find something.
I have followed the instructions regarding configuration on the LDAP login page the authentication fails and looking into logs
6266716e conn=1009 fd=12 ACCEPT from IP=192.168.144.1:46050 (IP=0.0.0.0:389)
6266716e conn=1009 op=0 BIND dn="cn=readonly,dc=mydomain,dc=com" method=128
6266716e conn=1009 op=0 RESULT tag=97 err=49 text=
6266716e conn=1009 op=1 UNBIND
6266716e conn=1009 fd=12 closed
where does IP=0.0.0.0:389 comes from ? is it because of this authentication is failing?
I've installed vaultwarden_ldap using docker and traefik.
Is ist possible to open then admin portal from another host over network or is it restricted to localhost?
I get the error message "Bad Gateway" in my browser if i try to connect to the container by the url
ldapsync.domain.tld (this is not the real url!).
The host ist present in DNS and in Traefik.
HIGH Vulnerability found in os package type (dpkg) - linux-libc-dev (CVE-2019-1999 - https://security-tracker.debian.org/tracker/CVE-2019-1999)
HIGH Vulnerability found in os package type (dpkg) - linux-libc-dev (CVE-2019-12456 - https://security-tracker.debian.org/tracker/CVE-2019-12456)
HIGH Vulnerability found in os package type (dpkg) - linux-libc-dev (CVE-2019-1999 - https://security-tracker.debian.org/tracker/CVE-2019-1999)
The current rust:1.33 image used has OpenSSL 1.1.0 which does not support TLS 1.3.
rust:1.46 has OpenSSL 1.1.1d which supports it.
I have a bitwarden install which is TLS 1.3 only. Can you upgrade the image?
So I'm running into the error above.
From what I can see, I've mapped the config.toml file correctly
Screenshot showing contents of config.toml and location
Screenshot showing docker container variables from portainer
From the error message, I think this is gonna be a simple one so apologies in advanced!
Can support ldap group members ? Only members of specified groups are allowed to invite , not ALL(uid=*)
I use freeipa server ,my config.toml ldap_search_filter expression :
ldap_search_filter = "(&(objectClass=*)(memberof=cn=vaultwarden,cn=groups,cn=accounts,dc=xxx,dc=cn))
but not found user,log output:
ldap_sync | Sent invites to 0 user(s).
ldap_sync | Sent invites to 0 user(s).
ldap_sync | Sent invites to 0 user(s).
ldap_sync | Sent invites to 0 user(s).
ldap_sync | Sent invites to 0 user(s).
Hello,
Thanks for taking the time to look at my issue. It is most likely a noob question! lol
I'm running bitwarden_rs and Bitwarden_rs_ldap with docker on ubuntu, and I'm trying to connect the ldap to my synology nas that is acting like an ldap server. I'm not the most familiar with ldap, and I keep running into issues. Here is what I get when I run "docker-compose up ldap_sync"
Error: Failed to get existing users from Bitwarden
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 | 0: 0x560429a3de75 - 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: 0x560429a3de75 - 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: 0x560429a3de75 - std::sys_common::backtrace::_print_fmt::hd42948c952866e12
ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:78
ldap_sync_1 | 3: 0x560429a3de75 - <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: 0x560429a6408c - core::fmt::write::he0c1e5f7426d2718
ldap_sync_1 | at src/libcore/fmt/mod.rs:1076
ldap_sync_1 | 5: 0x560429a37f72 - std::io::Write::write_fmt::hf3afc6cfd57d0033
ldap_sync_1 | at src/libstd/io/mod.rs:1537
ldap_sync_1 | 6: 0x560429a40500 - std::sys_common::backtrace::_print::hfc0110703f3696fd
ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:62
ldap_sync_1 | 7: 0x560429a40500 - std::sys_common::backtrace::print::h3f77c6990ddfaa22
ldap_sync_1 | at src/libstd/sys_common/backtrace.rs:49
ldap_sync_1 | 8: 0x560429a40500 - std::panicking::default_hook::{{closure}}::heae49580a8d62d75
ldap_sync_1 | at src/libstd/panicking.rs:198
ldap_sync_1 | 9: 0x560429a4024c - std::panicking::default_hook::hecc34e3f729e213c
ldap_sync_1 | at src/libstd/panicking.rs:217
ldap_sync_1 | 10: 0x560429a40b43 - std::panicking::rust_panic_with_hook::he82f5d0644692441
ldap_sync_1 | at src/libstd/panicking.rs:526
ldap_sync_1 | 11: 0x560429a4073b - rust_begin_unwind
ldap_sync_1 | at src/libstd/panicking.rs:437
ldap_sync_1 | 12: 0x560429a406ab - std::panicking::begin_panic_fmt::h905a6d44880d49ef
ldap_sync_1 | at src/libstd/panicking.rs:391
ldap_sync_1 | 13: 0x56042979be88 - bitwarden_rs_ldap::main::haa4280f31d5ef4bc
ldap_sync_1 | 14: 0x5604297a7793 - std::rt::lang_start::{{closure}}::hf197e98854a288a6
ldap_sync_1 | 15: 0x560429a40fe3 - std::rt::lang_start_internal::{{closure}}::h5d3ea623498f5f43
ldap_sync_1 | at src/libstd/rt.rs:52
ldap_sync_1 | 16: 0x560429a40fe3 - std::panicking::try::do_call::hac65e71be769a440
ldap_sync_1 | at src/libstd/panicking.rs:348
ldap_sync_1 | 17: 0x560429a40fe3 - std::panicking::try::hd4706e264bcf6712
ldap_sync_1 | at src/libstd/panicking.rs:325
ldap_sync_1 | 18: 0x560429a40fe3 - std::panic::catch_unwind::h948a0fb4a8b3ee82
ldap_sync_1 | at src/libstd/panic.rs:394
ldap_sync_1 | 19: 0x560429a40fe3 - std::rt::lang_start_internal::h72cc068ed2d0ac53
ldap_sync_1 | at src/libstd/rt.rs:51
ldap_sync_1 | 20: 0x56042979e742 - main
ldap_sync_1 | 21: 0x7f5c8ed3209b - __libc_start_main
ldap_sync_1 | 22: 0x56042979519a - _start
ldap_sync_1 | 23: 0x0 -
bitwarden_rs_ldap_sync_1 exited with code 101
I'm guessing one of two things. Either I don't have something correct in my toml file to help me to sync to the synology ldap server, or I don't have something correct for the ldap sync to connect to bitwarden. Here is my toml file
bitwarden_url = "https://bitwarden.example.com"
bitwarden_admin_token = "password-to-bitwarden-admin"
ldap_host = "192.168.52.134"
ldap_bind_dn = "uid=root,cn=users,dc=ldap,dc=example,dc=com"
ldap_bind_password = "password-to-synology-ldap"
ldap_search_base_dn = "dc=ldap,dc=example,dc=com"
ldap_search_filter = "(&(objectClass=)(uid=))"
ldap_sync_interval_seconds = 10
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?
Hello!
I started vaultwarden and vaultwarden_ldap using docker compose, filled in config.toml, but always see message:
Sent invites to 0 user(s).
Sent invites to 0 user(s).
Sent invites to 0 user(s).
Sent invites to 0 user(s).
I can not understand what is the reason (((
Can you help solve my problem?
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!
In case you weren't aware, bitwarden_rs officially changed its name to vaultwarden to avoid any trademark/copyright issues. To avoid similar issues and to maintain logical linkage to the vaultwarden project, you unfortunately may want to consider renaming your project as well.
I am getting this error in the logs, but nothing else. Is there a "debug" mode, where i can see what is going on?
Hey @ViViDboarder,
I just succeeded to import some users into our bitwarden instance. Now I'm a bit stuck about gooing any further. Is there any way (planned) for importing People into the proper organisation or collection? I've read in another issue that adding to an org is not yet possible. However I saw that you can configure an external ID in the collections. It would be no Problem do have a dedicated group (or two for the managers and normal users) on the AD that would be used inside bitwarden. Is that possible?
Greetings
David
Is it possible to set more than one ldap server IPs (or hostnames)? In our case, we have 2 AD servers in sync, for HA. Would be nice to be able to have this redundancy.
It would be very handy to manipulate the data in the mail-field which is requested from the LDAP backend.
In order to mainstream my setup, I do not want to use the actual "mail" field (which can be anything - even empty) but a "mail-address" which is derived from the users common name (CN): "CN=klaus" becomes a mail like "[email protected]".
Switching "ldap_mail_field" to CN already does half the job. But since this is now only the CN and not a valid mail address, an invited user cannot register at the vault.
A solution would be, to simply append some string like "@domain.tld" to the value of the CN field after querying it from LDAP and before pushing this to the vaultwarden backend. E.g. with a simple prefix/suffix solution or a full-blown reg-exp magic.
Hence the request.
Hello,
when starting the Docker container I'm getting the error thread 'main' panicked at 'broken pipe', src/main.rs:21:9
. I think it is because I'm connecting over SSL using a self signed certificate.
Is there a way to accept self signed certificates?
Hello,
I wish to connect this image to an OpenLDAP which is only supporting startTLS connections (on port 389).
I did not see any option for that use case.
Tried to play with those options
ldap_scheme = ldap/ldaps
ldap_ssl = true/false
ldap_port = 389
But it always fails and my openldap logs TLS confidentiality required
.
Will this allow users to login with their LDAP password, or is it only gping to invite users?
thread 'main' panicked at 'Failed to parse config file at config.toml', src/config.rs:28:9
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:385
6: std::panicking::begin_panic_fmt
at src/libstd/panicking.rs:340
7: bitwarden_rs_ldap::config::Config::from_file
8: bitwarden_rs_ldap::main
9: std::rt::lang_start::{{closure}}
10: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:297
11: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
12: std::rt::lang_start_internal
at src/libstd/panicking.rs:276
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
13: main
14: __libc_start_main
15: _start
config.toml:
bitwarden_url = "http://bitwarden.company.com"
bitwarden_admin_token = "long_random_key"
ldap_host = "10.1.1.2"
ldap_bind_dn = "CN=bitwarden.ad.access,OU=Bitwarden,OU=Domain_Services,DC=company,DC=local"
dap_bind_password = "Pa$$word"
ldap_search_base_dn = "dc=company,dc=local"
ldap_search_filter = "(&(objectClass=*)(uid=*))"
ldap_sync_interval_seconds = 10
Hi,
Just unsure about the nature of this error.
our website has a valid certificate, and we have forced "ldap_no_tls_verify = false" from the default true value (also failed in that case as well)
ldap_sync_1 | Error inviting users from ldap. Count 0: Failed to get existing users from server
ldap_sync_1 |
ldap_sync_1 | Caused by:
ldap_sync_1 | 0: Could not get list of existing users from server
ldap_sync_1 | 1: http error making request Error(Hyper(Error(Connect, Custom { kind: Other, error: Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 337047686, library: "SSL routines", function: "tls_process_server_certificate", reason: "certificate verify failed", file: "../ssl/statem/statem_clnt.c", line: 1915 }]))) }, X509VerifyResult { code: 20, error: "unable to get local issuer certificate" }) })), "https://vaultwarden.mydomain.net/admin/")
ldap_sync_1 | 2: https://vaultwarden.mydomain.net/admin/: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (unable to get local issuer certificate)
ldap_sync_1 | 3: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (unable to get local issuer certificate)
ldap_sync_1 | 4: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915:
Hi,
I have an installation that is pretty typical using docker-compose to provide bitwarden_rs behind caddy proxy. However each time the ldap search runs it restarts the container with a panic regarding a broken pipe. I seem to be unable to find out whats actually going wrong......
thread 'main' panicked at 'broken pipe', src/main.rs:22:9
....my docker-compose is as follows.....
# docker-compose.yml
version: '3'
services:
bitwarden:
image: bitwardenrs/server
restart: always
volumes:
- ./bw-data:/data
- ./bw-log:/logs
environment:
WEBSOCKET_ENABLED: 'true' # Required to use websockets
SIGNUPS_ALLOWED: 'false' # set to false to disable signups
ADMIN_TOKEN: '{REDACTED}' # sets the admin token
LOG_FILE: /logs/bitwarden.log
LOG_LEVEL: warn
ldap:
image: vividboarder/bitwarden_rs_ldap:latest
restart: always
depends_on:
- bitwarden
volumes:
- ./bw-ldap:/data:ro
environment:
CONFIG_PATH: /data/config.toml
# RUST_BACKTRACE: full
caddy:
image: abiosoft/caddy
restart: always
volumes:
- ./Caddyfile:/etc/Caddyfile:ro
- caddycerts:/root/.caddy
ports:
- 80:80 # needed for Let's Encrypt
- 443:443
environment:
ACME_AGREE: 'true' # agree to Let's Encrypt Subscriber Agreement
DOMAIN: '{REDACTED}' # CHANGE THIS! Used for Auto Let's Encrypt SSL
EMAIL: '{REDACTED}' # CHANGE THIS! Optional, provided to Let's Encrypt
volumes:
caddycerts:
The config.toml is....
bitwarden_url = "http://bitwarden"
bitwarden_admin_token = "{REDACTED}"
ldap_host = "{REDACTED}"
ldap_scheme = "ldaps"
ldap_ssl = true
ldap_no_tls_verify = false
ldap_bind_dn = "{REDACTED}"
ldap_bind_password = "{REDACTED}"
ldap_search_base_dn = "{REDACTED}"
ldap_search_filter = "(&(objectClass=person)({REDACTED}))"
ldap_sync_interval_seconds = 10
ldap_sync_loop = false
Running 'ldapsearch' using the same parameters confirms that the LDAP is connecting and returning the values.
Changing the adminkey to something that is invalid confirms that the admin key is correct (errors when incorrect) the same with the bitwarden url.
If you could help me understand where the issue is I would be vary grateful.
Thanks
close
Hi @ViViDboarder, thanks for the taking the time to develop this tool. I managed to get it up and running, but I'm having some odd errors I'm hoping you can help me with. I have the LDAP filters such that only a single user should match for testing purposes, and that is working.
The first time it ran, I got the following log output (redacted for identities):
Existing user or invite found with email: [email protected],
Existing user or invite found with email: [email protected],
Existing user or invite found with email: [email protected],
Try to invite user: [email protected],
Sent invites to 1 user(s).,
Which is working great so far. The user received their invitation, and I see the user in bitwarden_rs's admin panel. However, the user is not associated with any current organizations in our setup, so my first question is: is there a way to specify which organizations new users should be associated with?
Then, on the next cycle I saw:
Existing user or invite found with email: [email protected],
Existing user or invite found with email: [email protected],
Existing user or invite found with email: [email protected],
Existing user or invite found with email: [email protected],
Try to invite user: [email protected],
Sent invites to 1 user(s).,
I note that it's trying to reinvite the same user. I wonder if it isn't because our AD server returns the email address with capital letters in it, and that the matching is being done on a case sensitive level? I note the following in bitwarden_rs's logs seem to reflect the error in attempting to duplicate an existing user:
[2020-03-05 15:15:28][request][INFO] GET /admin/users
[2020-03-05 15:15:28][response][INFO] GET /admin/users (get_users) => 200 OK,
[2020-03-05 15:15:28][request][INFO] POST /admin/invite,
[2020-03-05 15:15:28][error][ERROR] User already exists,
[2020-03-05 15:15:28][response][INFO] POST /admin/invite (invite_user) => 400 Bad Request,
So my second question is: is there a way to fix the case sensitivity of the matching?
Thanks!
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
Hi,
Have a test server but is in SSL Self Signed for test now.
How to bypass this ?
/bitwarden_rs_ldap
thread 'main' panicked at 'Could not authenticate with https://keepass.myhost.com:443. Error { kind: Hyper(Error { kind: Connect, cause: Custom { kind: Other, error: Ssl(Error { code: ErrorCode(1), cause: Some(Ssl(ErrorStack([Error { code: 337047686, library: "SSL routines", function: "tls_process_server_certificate", reason: "certificate verify failed", file: "ssl/statem/statem_clnt.c", line: 1913 }]))) }, X509VerifyResult { code: 19, error: "self signed certificate in certificate chain" }) } }), url: Some("https://keepass.myhost.com/admin/") }', src/bw_admin.rs:62:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Best Regards
Thank you for this project, it fits a perfect use case for me. I, however, have only a very superficial knowledge of ldap. I can query my lldap server and get users, but can't seem to translate this into the correct config settings.
I have a simple (limited) lldap podman installation.
The only required fields are:
uid,mail,cn
If I query my ldap container with:
ldapsearch -L -H ldap://localhost:389 -D uid=admin,ou=people,dc=domain,dc=com -w admin_password -x -bdc=domain,dc=com uid=valid_uid
I get:
version: 1
#
# LDAPv3
# base <dc=domain,dc=com> with scope subtree
# filter: uid=valid_uid
# requesting: ALL
#
# valid_uid, people, domain.com
dn: uid=valid_uid,ou=people,dc=domain,dc=com
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: mailAccount
objectclass: person
dn: uid=valid_uid,ou=people,dc=domain,dc=com
uid: valid_uid
mail: [email protected]
givenname: name
sn: sname
cn: cname
createtimestamp: 2022-05-26T10:04:48+00:00
# search result
Server is unwilling to perform (53)
Additional information: Unsupported group filter: Unsupported group attribute: "user_id"
# numResponses: 2
# numEntries: 1
If I search for cn=valid_cn
instead of uid=valid_uid
then I get the same result but without:
Server is unwilling to perform (53) Additional information: Unsupported group filter: Unsupported group attribute: "user_id"
I was searching on uid because they are unique, whereas cn will not be (although cn combined with mail will be)
If my ldap configs look like:
ldap_bind_dn = "uid=admin,ou=people,dc=domain,dc=com"
ldap_bind_password = "admin_password"
ldap_search_base_dn = "-bdc=domain,dc=com"
ldap_search_filter = "uid=*"
Runs in the container with no errors, but does not return any found users (it should, there are some!).
I've tried various combinations of things but not hit on the magic juju. Any guidance or suggestions would be appreciated.
This is a similar issue to issue #51.
Vaultwarden_ldap should be able to detect users that have been removed or disabled in LDAP and then disable the account on vaultwarden.
There should be a settings to enable this or not.
Trying to get LDAP to work with Bitwarden, causing the error described below. I'm trying to get all users synced from an existing ADDS. We have previously used Bitwarden without bitwarden_rs_ldap.
On a sidenote: I'm not quite sure if the ldap_admin etc is actually required for my usecase or if I just need the sync submodule after following the docker hub instructions - a clarification would be much appreciated.
Console Log
cgos@cgos-bitwarden:~$ cd bitwarden_rs_ldap/
cgos@cgos-bitwarden:~/bitwarden_rs_ldap$ docker-compose up -d bitwarden ldap ldap_admin
Pulling ldap_admin (osixia/phpldapadmin:)...
latest: Pulling from osixia/phpldapadmin
1ab2bdfe9778: Pull complete
0abcaf321aa9: Pull complete
6d688c3d4e02: Pull complete
454331b99b9a: Pull complete
5cada7c8cb4e: Pull complete
b0f406024ee7: Pull complete
b04a43f9c3ac: Pull complete
92a3a5c2b5a5: Pull complete
e4955dcfbe65: Pull complete
Digest: sha256:8b567ec1e044455aedca2004849e8d6f222b3ce6a986f30406d5bbb8adeb3388
Status: Downloaded newer image for osixia/phpldapadmin:latest
Pulling ldap (osixia/openldap:)...
latest: Pulling from osixia/openldap
1ab2bdfe9778: Already exists
0abcaf321aa9: Already exists
6d688c3d4e02: Already exists
3377ea9972cf: Pull complete
8597976b0b32: Pull complete
b19b05c140f1: Pull complete
5744a9328048: Pull complete
26e0f6b2f940: Pull complete
ba7157fb7dce: Pull complete
Digest: sha256:9cf1631238e606cf8b58e4654b26e6eba7182eadafefffa662cd9784ea811eda
Status: Downloaded newer image for osixia/openldap:latest
Creating bitwarden_rs_ldap_bitwarden_1 ... error
Creating bitwarden_rs_ldap_ldap_admin_1 ...
Creating bitwarden_rs_ldap_ldap_1 ...
Creating bitwarden_rs_ldap_ldap_admin_1 ... done
Creating bitwarden_rs_ldap_ldap_1 ... done
ERROR: for bitwarden Cannot start service bitwarden: driver failed programming external connectivity on endpoint bitwarden_rs_ldap_bitwarden_1 (377d270f91ffff023f366460405daf7e4b19a902c28a112dba9d5707fbfd825c): Bind for 0.0.0.0:443 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.
cgos@cgos-bitwarden:~/bitwarden_rs_ldap$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
22840fb4ae88 osixia/openldap "/container/tool/run" 25 seconds ago Up 21 seconds 0.0.0.0:389->389/tcp, 0.0.0.0:636->636/tcp bitwarden_rs_ldap_ldap_1
99761cd30036 osixia/phpldapadmin "/container/tool/run" 25 seconds ago Up 21 seconds 443/tcp, 0.0.0.0:8001->80/tcp bitwarden_rs_ldap_ldap_admin_1
edb4493d45c9 bitwardenx "./bitwarden_rs" 2 months ago Up 2 months 3012/tcp, 0.0.0.0:443->80/tcp bitwarden
cgos@cgos-bitwarden:~/bitwarden_rs_ldap$ nano example.config.toml
cgos@cgos-bitwarden:~/bitwarden_rs_ldap$ echo "RUST_BACKTRACE=1" >> .env
cgos@cgos-bitwarden:~/bitwarden_rs_ldap$ docker-compose up ldap_sync
bitwarden_rs_ldap_ldap_sync_1 is up-to-date
Attaching to bitwarden_rs_ldap_ldap_sync_1
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | Existing user or invite found with email: [email protected]
ldap_sync_1 | thread 'main' panicked at 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9
ldap_sync_1 | note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
bitwarden_rs_ldap_ldap_sync_1 exited with code 101
example.config.toml
bitwarden_url = "https://bitwarden.cgos.biz"
bitwarden_admin_token = "adminpwd"
ldap_host = "ldap://ldapproxy.cgos.biz:636"
ldap_bind_dn = "cn=adquery,ou=serviceaccounts,dc=cgos,dc=loc"
ldap_bind_password = "adquerypwd"
ldap_search_base_dn = "dc=cgos,dc=loc"
ldap_search_filter = "(&(objectClass=user)(sAMAccountName=*)(memberOf:1.2.840.113556.1.4.1941:=cn=Bitwarden,ou=APPs,ou=CGos-Groups,dc=cgos,dc=loc))"
ldap_sync_interval_seconds = 120
bitwarden_rs Docker run
docker run -d --name bitwarden \
-e DOMAIN=https://bitwarden.cgos.biz \
-e INVITATIONS_ALLOWED=true \
-e SHOW_PASSWORD_HINT=false \
-e SIGNUPS_ALLOWED=false \
-e ADMIN_TOKEN=adminpwd \
-e SMTP_HOST=192.168.100.4 \
-e [email protected] \
-e SMTP_PORT=25 \
-e SMTP_SSL=false \
-e LOG_LEVEL=debug \
-e EXTENDED_LOGGING=true \
-e LOG_FILE=/data/bitwarden.log \
-e ROCKET_TLS='{certs="/ssl/stern.cgos.biz-chain.crt",key="/ssl/stern.cgos.biz.key"}' -v /etc/ssl/:/ssl/ \
-e ROCKET_WORKERS=15 \
-v /bw-data/:/data/ -p 443:80 bitwardenx
edit: also tried simplifying the search filter to ou=Users,dc=cgos,dc=loc
but results in the same error.
thread 'main' panicked at 'Error parsing config from env: missing value for field vaultwarden_url', src/config.rs:29:29
Started the container with image on https://hub.docker.com/r/vividboarder/vaultwarden_ldap
and a mapping on /data/ giving the container the enviroment variable CONFIG_PATH of /data/config.toml
config.toml passes the validation on https://www.toml-lint.com/ however ldap connector won't start with this error.
Any idea why this won't work ?
If LDAP returns any entries that don't have mail field app crashes with uninformative error:
thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
1: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:70
2: std::panicking::default_hook::{{closure}}
at src/libstd/sys_common/backtrace.rs:58
at src/libstd/panicking.rs:200
3: std::panicking::default_hook
at src/libstd/panicking.rs:215
4: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:478
5: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:385
6: rust_begin_unwind
at src/libstd/panicking.rs:312
7: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
8: core::option::expect_failed
at src/libcore/option.rs:1038
9: bitwarden_rs_ldap::invite_from_ldap
10: bitwarden_rs_ldap::main
11: std::rt::lang_start::{{closure}}
12: std::panicking::try::do_call
at src/libstd/rt.rs:49
at src/libstd/panicking.rs:297
13: __rust_maybe_catch_panic
at src/libpanic_unwind/lib.rs:92
14: std::rt::lang_start_internal
at src/libstd/panicking.rs:276
at src/libstd/panic.rs:388
at src/libstd/rt.rs:48
15: main
16: __libc_start_main
17: _start
Hi guys!
I decided to try setting up vaultwarden with my ldap server, which I already had before and works successfully with a number of my applications.
At the moment I am facing the following:
It seems to me that I managed to set up a connection.
Valutwarden, or rather a container with a microservice, connects to ldap and sees users, as evidenced by these log entries:
Sent invites to 0 user(s).
Existing user or invite found with email: [email protected]
Existing user or invite found with email: [email protected]
Existing user or invite found with email: [email protected]
User with email already exists: [email protected]
User with email already exists: [email protected]
User with email already exists: [email protected]
Here is my toml:
vaultwarden_url = "https://domain.com"
vaultwarden_admin_token = "toKen"
ldap_host = "ldap://ldap"
ldap_bind_dn = "cn=admin,dc=home,dc=lan"
ldap_bind_password = "PaSSworD"
ldap_search_base_dn = "dc=home,dc=lan"
ldap_search_filter = "(&(objectClass=*)(uid=*))"
Before this setup I have two users in my LDAP, after several login attempts with my creds, I create a new user [email protected]
, and faced with incorrect password also.
Could someone explane me, where I'm make a mistake, maybe I'm not correctly undestood the steps for vaultwarden need to works with ldap, or I'm not reading something from instructions yet? Why I can't login in fresh vaultwarden with my creds from ldap server?
I'm toying with the idea of launching a self-hosted Vaultwarden for our company needs - essentially we want to be able to keep track of who has access to what external resources based on LDAP assignments (ex. account is member of a specific group -> has access to certain collections; if account gets disabled / removed from group that collection access should be revoked).
I've already noticed from this question that LDAP sync for Vaultwarden can't really do the same thing as the Bitwarden Directory Connector when it comes to disabling users, and it seems to be more aimed towards adding LDAP users to Vaultwarden in general than to sync users up with organizations.
Are there any plans to get this sort of functionality into valutwarden_ldap?
When I try to run docker-compose up, this error pops up.
It is probably due to my inexperience with docker, so it should be a quick fix.
here is my docker-compose.yml:
version: "3"
services:
vault:
restart: always
image: bitwardenrs/server:latest
volumes:
- data:/bw-data
environment:
- ADMIN_TOKEN=${ADMIN_TOKEN}
ports:
- 9999:80
ldap_sync:
image: vividboarder/bitwarden_rs_ldap
volumes:
- ldap_sync_config:/opt/docker/bitwardenrs/config
environment:
CONFIG_PATH: /config.toml
RUST_BACKTRACE: 1
restart: always
volumes:
data:
ldap_sync_config:
my config lies in /opt/docker/bitwardenrs/config/config.toml
apart from the config and the docker-compose.yml there is nothing in this directly. Ist that correct ?
/opt/docker/bitwardenrs$ ls
config docker-compose.yml
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.