LDAP Sync failing with 'rc=32 (noSuchObject), dn: "", text: ""', src/main.rs:21:9 #5
Comments
|
Thanks for moving this!
I'm not seeing the backtrace. Could you try setting |
|
Sure. Sorry, not too familiar with docker yet & thought the .env file would be global to all projects. |
|
No worries! I'm new to Rust so I was hoping that would be useful but it seems that pretty much the entire stack trace is in the std libs. 🤦♂ I think it's because I pass the error up the stack and then panic on it in the main function. I kinda expected the error to contain more information. I do see a comment I wrote though, it doesn't seem too helpful Anyway, the error appears to be when searching. I searched for the error text in the LDAP library I'm using and it appears to actually be an error returned from the LDAP server itself. Can you verify your bind and search info using another tool? Like |
|
The everlasting struggle of testing locally and debugging in the wild... I can relate. Generally, what object-type is bitwarden_rs_ldap expecting? I just expected it to consume user objects which this my query is currently receiving exclusively. edit: Thinking about the question which object you're expecting – a feature request could be having the ability to define the corresponding LDAP attribute of the login (section 4) to provide a unified login experience across all platform (sAMAccountName everywhere, instead of a sAMAccountName x Email as username mix). |
|
To be honest, I only have a basic understanding of LDAP queries, so it's quite likely that I overlooked something that should be configurable. The only things being passed to the LDAP client library are the base dn you provide, a Scope of Subtree, the search filter, and then a set of fields. Fields included are I can try to reproduce based on that assumption. Edit: Well, so much for that. Just tried by referencing an invalid field for the mail field and got: So the search query actually worked just fine and I was able to get an object back and then just fail gracefully when trying to read the field. I'll keep looking. |
|
Ok. I was able to reproduce by simply updating my But from your comments, it looks like the dn is correct... |
|
When I change my Otherwise I'll try setting this up as a separateclean install tomorrow and see if the results differ. |
|
I fixed my issue – multiple things were wrong in my configuration, the typo you mentioned for I realized however that this project merely serves as an automation to fill in the invitation field in the admin for users found in LDAP and does not actually in fact sync passwords from sources like Active Directory, which is the main reason I've been implementing LDAP into applications. I don't know if this is actually somehow possible for Bitwarden, or if this is not viable due to security limitations / concerns, but it would certainly be the thing I would love to see. |
|
Ah. Yea, not exactly possible to do that while maintaining the client side encryption. There was some discussion of it on this thread somewhat recently: dani-garcia/vaultwarden#677 It might be possible if we fork the clients as well, but that seems like more effort than anyone seems interested in picking up right now. |
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
example.config.toml
bitwarden_rs Docker run
edit: also tried simplifying the search filter to
ou=Users,dc=cgos,dc=locbut results in the same error.The text was updated successfully, but these errors were encountered: