vividboarder/vaultwarden_ldap

Automate LDAP invites to Vaultwarden

vaultwarden_ldap

LDAP user invites for vaultwarden

After configuring, run vaultwarden_ldap and it will invite any users it finds in LDAP to your vaultwarden instance. This is NOT a sync tool like the Bitwarden Directory Connector.

Deploying

This is easiest done using Docker. See the docker-compose.yml file in this repo for an example. If you would like to use Docker Hub rather than building, change build: . to image: vividboarder/vaultwarden_ldap.

Make sure to populate and mount your config.toml!

Configuration

Configuration is read from a TOML file. The default location is config.toml, but this can be configured by setting the CONFIG_PATH env variable to whatever path you would like.

Configuration values are as follows:

Name	Type	Optional	Description
vaultwarden_url	String		The root URL for accessing vaultwarden. Eg: https://vw.example.com
vaultwarden_admin_token	String		The value passed as ADMIN_TOKEN to vaultwarden
vaultwarden_root_cert_file	String	Optional	Path to an additional der-encoded root certificate to trust. Eg. root.cert. If using Docker see docker-compose.yml for how to expose it. Defaults to empty
ldap_host	String		The hostname or IP address for your ldap server
ldap_scheme	String	Optional	The that should be used to connect. ldap or ldaps. This is set by default based on SSL settings
ldap_ssl	Boolean	Optional	Indicates if SSL should be used and if we should connect with ldaps. Defaults to false
ldap_starttls	Boolean	Optional	Indicates if the connection should be done using StartTLS
ldap_no_tls_verify	Boolean	Optional	Indicates if certificate should be verified when using SSL. Defaults to true
ldap_port	Integer	Optional	Port used to connect to the LDAP server. This will default to 389 or 636, depending on your SSL settings
ldap_bind_dn	String		The dn for the bind user that will connect to LDAP. Eg. cn=admin,dc=example,dc=org
ldap_bind_password	String		The password for the provided bind user.
ldap_search_base_dn	String		Base dn that will be used when searching LDAP for users. Eg. dc=example,dc=org
ldap_search_filter	String		Filter used when searching LDAP for users. Eg. (&(objectClass=*)(uid=*))
ldap_mail_field	String	Optional	Field for each user record that contains the email address to use. Defaults to mail
ldap_sync_interval_seconds	Integer	Optional	Number of seconds to wait between each LDAP request. Defaults to 60
ldap_sync_loop	Boolean	Optional	Indicates whether or not syncing should be polled in a loop or done once. Defaults to true

Alternatively, instead of using config.toml, all values can be provided using enviroment variables prefixed with APP_. For example: APP_VAULTWARDEN_URL=https://vault.example.com

Development

This repo has a predefined set of pre-commit rules. You can install pre-commit via any means you'd like. Once your system has pre-commit installed, you can run make install-hooks to ensure the hooks will run with every commit. You can also force running all hooks with make check.

For those less familiar with cargo, you can use the make targets that have been included for common tasks like running a debug version. make run-debug or building a release version make release.

Testing

There are no unit tests, but there are integration tests that require manual verification.

Integration tests

Running make itest will spin up an ldap server with a test user, a Vaultwarden server, and then run the sync. If successful the log should show an invitation sent to the test user. If you run make itest again, it should show no invites sent because the user already has been invited. If you'd like to reset the testing, make clean-itest will clear out the Vaultwarden database and start fresh.

It's also possible to test passing configs via enviornment variables by running make itest-env. The validation steps are the same.

Steps for manual testing

The first step is to set up Bitwarden and the LDAP server.

docker-compose up -d vaultwarden ldap ldap_admin

1. After that, open the admin portal on http://localhost:8001 and log in using the default account info:

   Username: cn=admin,dc=example,dc=org Password: admin

From there you can set up your test group and users.

2. Expand the dc=example,dc=org nav tree and select "Create new entry here"

3. Select "Generic: Posix Group"

4. Give it a name, eg. "Users" and then save and commit

5. Select "Create child object"

6. Select "Generic: User Account"

7. Give the user a name and select a group ID number and save and commit

8. Select "Add new attribute" and select "Email" and then add a test email address

9. Run the ldap sync

docker-compose up ldap_sync

Alternately, you can bootstrap some of this by running:

docker-compose -f docker-compose.yml -f itest/docker-compose.itest.yml up --build

vaultwarden_ldap's Issues

LDAP Password syncing?

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?

thread 'main' panicked at 'Connection timed out

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

LDAP Sync Problem

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?

ldap admin

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

HIGH Vulnerability found in os package type (dpkg) - linux-libc-dev

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)

SSL certificate error when launching LDAP container

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:

Request a feature

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

LDAP login authentication failure

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?

SSL Self Signed error & Error LDAP

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

Group / organization support?

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?

Change name to vaultwarden_ldap?

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.

Failed to parse config file at config.toml

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

Sync via Groups / add to Organisation (and Collection) based on Group

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

vaultwarden_ldap does not invite new users from active directory

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?

LDAP Sync failing with 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9

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.

Do not use "restart = unless stopped" (docker-compose) and "ldap_sync_loop = false" (config.toml) !

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...

Alpine images for v0.3.0 not available

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?

panicked at 'broken pipe'

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

Will this allow users to login with their LDAP password?

Will this allow users to login with their LDAP password, or is it only gping to invite users?

Allow more than one ldap server

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.

Config.toml cannot be parsed

close

vaultwarden_ldap without Docker/Docker-compose possible?

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

Unable to read config.toml

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

bitwarden_rs_ldap_sync_1 exited with code 101

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

Proper communication with LDAP

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:

1. It seems to me that I managed to set up a connection.

2. 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?

Disable users that vanished from LDAP

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.

support for startTLS ?

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.

Cannot open admin portal on http://localhost:8001

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.

vividboarder/vaultwarden_ldap:alpine image not updated

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?

ldap_sync_1 | thread 'main' panicked at 'Failed to open config file at /config.toml', src/config.rs:25:9

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

Make SSL validation optional

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:

• SSL-validation of the HTTPS Certificate presented by the Bitwarden webfrontend
• SSL-validation of the LDAP Host Certificate

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.

Add posibility to configure via environment variables

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

Problems with case matching and user organizations

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!

Error: 'Warning: Email field, "Mail", not found on user'

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

Can support ldap group members

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).

thread 'main' panicked at 'broken pipe', src/main.rs:21:9

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?

Build from alpine and docker image broken

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.

Support TLS 1.3

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?

Add support for LDAP custom CA

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.

thread 'main' panic 'no entry found for key' when there are any users without `mail` field in ldap search result

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

thread 'main' panicked at 'Failed to open config file at config.toml', src/config.rs:25:9

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!

Failed to parse config file at /data/config.toml

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 ?

Support for reg-exp or prefix/suffix for LDAP "mail" field data

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.

Help translating ldapsearch query into working config

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.

Invite to organization

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 !

ldap_search_filter options

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!

"Warning: Email field, "mail", not found on user"

I am getting this error in the logs, but nothing else. Is there a "debug" mode, where i can see what is going on?

thread 'main' panicked...`RUST_BACKTRACE=1` environment variable to display a backtrace

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.

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

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 -

Anonymous bind enabled?

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?