Group support and directory connector within multiple organisations

Hello everyone,

I’m not sure if this is a real problem or if I’ve misunderstood how the system works - so I thought I’d post it here.

  • Vaultwarden 1.30.5 in debian environment, Database mysql
  • Directory source: Microsoft AD (server 2022)
  • Bitwarden Directory Connector version 2024.3.2
    Remove disabled users during sync
    Overwrite existing organization users based on current sync settings
    Sync users
    Sync groups

Starting point was an organization with group support enabled and a directory connector task (users&groups) against an active directory.
This worked very well so far.
After we created another organization and wanted to synchronize the same users and groups with another directory connector job, things got spooky:

  • Groups that had already been matched to organization A were not created in organization B.
  • If a new group was created in the active directory and the job for organization B was started first, the group appeared in organization B. But not in organization A after its job was started.
  • Group membership assignments in the first organization were deleted while the sync job for the second organization was running.

As I understand it, every organization has a

  • individual “user mapping”
  • individual organization groups with reference to the group members

If I interpret the code around

correctly (unfortunately I’m not familiar with the programming language), when matching via the externalid it is checked whether the group already exists regardless of the organization and in this case no new group is created.

Since the ExternalId is formed from the ObjectId of the active directory and is identical in the import of the two organizations, the behaviour described above probably occurs.

Is it an error or am I using the system outside its specification?

Greetings

Nice catch. That’s probably an error in our implementation as bitwarden/server loads all groups for the given organization only

I think this PR should prevent the problem from occurring: