Feature request: LDAP Backend #2349

Closed
opened 2025-10-09 18:00:56 +03:00 by OVERLORD · 9 comments
Owner

Originally created by @ImNtReal on GitHub.

It would be awesome if I could integrate this with my existing LDAP server, so my account to get my master password would be the same that I use to login to the rest of the services I'm hosting on the same server.

Originally created by @ImNtReal on GitHub. It would be awesome if I could integrate this with my existing LDAP server, so my account to get my master password would be the same that I use to login to the rest of the services I'm hosting on the same server.
OVERLORD added the help wantedenhancementlow priority labels 2025-10-09 18:00:56 +03:00
Author
Owner

@MrSnoozles commented on GitHub:

In which way would LDAP get implemented? The official server is using the directory connector to synchronize accounts. The connector is getting user and group data from the domain and sends them to /api/organizations/<id>/import

The data getting sent looks as follows:

image

So I guess the import-endpoint should get implemented to stay compatible with the official server, right? Or would this be solved differently, e.g. with LDAP authentication directly integrated into the server?

@MrSnoozles commented on GitHub: In which way would LDAP get implemented? The official server is using the [directory connector ](https://github.com/bitwarden/directory-connector) to synchronize accounts. The connector is getting user and group data from the domain and sends them to `/api/organizations/<id>/import` The data getting sent looks as follows: ![image](https://user-images.githubusercontent.com/17496592/49956030-83bdb480-ff04-11e8-965f-e5e1fac056c6.png) So I guess the `import`-endpoint should get implemented to stay compatible with the official server, right? Or would this be solved differently, e.g. with LDAP authentication directly integrated into the server?
Author
Owner

@dani-garcia commented on GitHub:

Huh, I didn't know that the directory connector existed, I though that was integrated in the server. I would prefer to keep compatible with the official server yes.

In this case, the connector probably makes LDAP easier to implement, but how does it work exactly? Does that create the users or do they need to exist already? Is the functionality just adding and removing users from the org or is there more?

Groups at the moment are not implemented, only collections, so that's something to have in mind, but we could have a version that only handles users.

I imagine an implementation of this would be similar to the methods send_invite, confirm_invite and delete_user that we already have to handle adding and removing users from organizations. This is in src/api/core/organizations.rs.

@dani-garcia commented on GitHub: Huh, I didn't know that the directory connector existed, I though that was integrated in the server. I would prefer to keep compatible with the official server yes. In this case, the connector probably makes LDAP easier to implement, but how does it work exactly? Does that create the users or do they need to exist already? Is the functionality just adding and removing users from the org or is there more? Groups at the moment are not implemented, only collections, so that's something to have in mind, but we could have a version that only handles users. I imagine an implementation of this would be similar to the methods `send_invite`, `confirm_invite` and `delete_user` that we already have to handle adding and removing users from organizations. This is in `src/api/core/organizations.rs`.
Author
Owner

@dani-garcia commented on GitHub:

I think this is in the same position as #94, if someone can PR an implementation that isn't overly complex, I'll be happy to merge it, but I don't plan on doing this myself.

@dani-garcia commented on GitHub: I think this is in the same position as #94, if someone can PR an implementation that isn't overly complex, I'll be happy to merge it, but I don't plan on doing this myself.
Author
Owner

@dani-garcia commented on GitHub:

To keep the issue tracker more focused, I'm closing this issue in favor of the meta issue at #246.

@dani-garcia commented on GitHub: To keep the issue tracker more focused, I'm closing this issue in favor of the meta issue at #246.
Author
Owner

@MrSnoozles commented on GitHub:

I think it should create and delete the users too, as one of the points of LDAP/ Active Directory is, that you set up users only once for all your applications. I'm going to try it with the official server and let you know.

@MrSnoozles commented on GitHub: I think it *should* create and delete the users too, as one of the points of LDAP/ Active Directory is, that you set up users only once for all your applications. I'm going to try it with the official server and let you know.
Author
Owner

@MrSnoozles commented on GitHub:

I just checked the official implementation. It's just adding and removing people to/from the organization depending on the email address. They have to exist in the system before and are not getting created.

@MrSnoozles commented on GitHub: I just checked the official implementation. It's just adding and removing people to/from the organization depending on the email address. They have to exist in the system before and are not getting created.
Author
Owner

@ViViDboarder commented on GitHub:

FYI: A form of LDAP syncing has been added to the wiki.

@ViViDboarder commented on GitHub: FYI: A form of LDAP syncing has been [added to the wiki](https://github.com/dani-garcia/bitwarden_rs/wiki/Syncing-users-from-LDAP).
Author
Owner

@mprasil commented on GitHub:

I assume they appear as accepted and you still need to confirm them in the org interface?

@mprasil commented on GitHub: I assume they appear as accepted and you still need to confirm them in the org interface?
Author
Owner

@dani-garcia commented on GitHub:

That would make sense, but the data sent doesn't contain a passwordhash or anything and we need that to create the account, so if it works like that then the login step has to be different.

@dani-garcia commented on GitHub: That would make sense, but the data sent doesn't contain a passwordhash or anything and we need that to create the account, so if it works like that then the login step has to be different.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/vaultwarden#2349