starred/vaultwarden_ldap_sync
1
0
Fork 0
mirror of https://github.com/sirtoobii/vaultwarden_ldap_sync.git synced 2026-04-26 20:45:54 +03:00
Code Issues 5 Projects Releases 2 Packages Wiki Activity

[GH-ISSUE #15] User Not Deactivated or Reactivated When Removed/Added to LDAP Group #10

New issue
Closed
opened 2026-03-04 00:59:39 +03:00 by kerem · 4 comments
kerem commented 2026-03-04 00:59:39 +03:00
Owner
Copy link

Originally created by @Sh4dow998 on GitHub (May 19, 2025).
Original GitHub issue: https://github.com/sirtoobii/vaultwarden_ldap_sync/issues/15

Description

We’re using Vaultwarden LDAP Sync (latest commit of the official repo) to synchronize our LDAP users with Vaultwarden. We have a dedicated LDAP group (GRP_Vaultwarden) configured so that:

  • When a user is added to GRP_Vaultwarden, they receive an invitation email to create a Vaultwarden account.
  • When a user is removed from GRP_Vaultwarden, their Vaultwarden account is disabled.

This flow has worked flawlessly for all users—except one. This user was initially in GRP_Vaultwarden when the container was first launched. When we removed him from the group, no action occurred: no disablement, no logs, nothing in the Docker output. Re-adding him to the group also did nothing (no invitation email, no reactivation). Removing him again likewise produced no effect.

Environment

  • Vaultwarden LDAP Sync Tag/Commit: latest
  • Vaultwarden Version: Docker image vaultwarden/server:latest
  • LDAP Server: Active Directory
  • Docker Host OS: Debian 11
  • Sync Interval: 1 minute
  • Log Level: INFO

Additional Information

  • Other LDAP users in the same OU/from the same domain are correctly provisioned and deprovisioned.
  • The email attributed to the user is correctly populated and valid.
  • No recent configuration changes to LDAP Sync—config has remained the same.
  • LDAP connectivity and bind are functioning (other users sync normally).

Could you please advise why a single user would be ignored by the sync process, and what additional logging or diagnostics we can enable to determine the root cause? Any help is greatly appreciated!

Originally created by @Sh4dow998 on GitHub (May 19, 2025). Original GitHub issue: https://github.com/sirtoobii/vaultwarden_ldap_sync/issues/15 **Description** We’re using Vaultwarden LDAP Sync (latest commit of the official repo) to synchronize our LDAP users with Vaultwarden. We have a dedicated LDAP group (`GRP_Vaultwarden`) configured so that: - **When a user is added to `GRP_Vaultwarden`**, they receive an invitation email to create a Vaultwarden account. - **When a user is removed from `GRP_Vaultwarden`**, their Vaultwarden account is disabled. This flow has worked flawlessly for all users—except one. This user was initially in `GRP_Vaultwarden` when the container was first launched. When we removed him from the group, **no action occurred**: no disablement, no logs, nothing in the Docker output. Re-adding him to the group also did nothing (no invitation email, no reactivation). Removing him again likewise produced no effect. **Environment** - **Vaultwarden LDAP Sync Tag/Commit:** latest - **Vaultwarden Version:** Docker image `vaultwarden/server:latest` - **LDAP Server:** Active Directory - **Docker Host OS:** Debian 11 - **Sync Interval:** 1 minute - **Log Level:** INFO **Additional Information** - Other LDAP users in the same OU/from the same domain are correctly provisioned and deprovisioned. - The email attributed to the user is correctly populated and valid. - No recent configuration changes to LDAP Sync—config has remained the same. - LDAP connectivity and bind are functioning (other users sync normally). Could you please advise why a single user would be ignored by the sync process, and what additional logging or diagnostics we can enable to determine the root cause? Any help is greatly appreciated!
kerem 2026-03-04 00:59:39 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-03-04 00:59:40 +03:00
Author
Owner
Copy link

@sirtoobii commented on GitHub (May 19, 2025):

Hi, thank you for the detailed bug report. This sounds like a very interesting issue, would you mind sending me the debug logs LOGLEVEL=DEBUG along with the affected email address. tobias[dot]bossert[at]fastpath[dot]ch

<!-- gh-comment-id:2891290044 --> @sirtoobii commented on GitHub (May 19, 2025): Hi, thank you for the detailed bug report. This sounds like a very interesting issue, would you mind sending me the debug logs `LOGLEVEL=DEBUG` along with the affected email address. `tobias[dot]bossert[at]fastpath[dot]ch`
kerem commented 2026-03-04 00:59:41 +03:00
Author
Owner
Copy link

@Sh4dow998 commented on GitHub (May 21, 2025):

I’ve emailed the debug logs and screenshots to your mail address. Let me know if you need anything else!

<!-- gh-comment-id:2897026517 --> @Sh4dow998 commented on GitHub (May 21, 2025): I’ve emailed the debug logs and screenshots to your mail address. Let me know if you need anything else!
kerem commented 2026-03-04 00:59:41 +03:00
Author
Owner
Copy link

@sirtoobii commented on GitHub (May 25, 2025):

Hi @Sh4dow998

Yes, thank you for the email. I couldn’t reproduce the described behavior, and I honestly can't think of a (technical) reason why the script would ignore a specific email address. To help debug this, I’ve added an option to dump all emails read from LDAP to the DEBUG log facility.

Please try the version at fix/user_not_adopted with DUMP_EMAIL_SOURCE=1, and confirm whether the affected user appears in that list.

<!-- gh-comment-id:2907902016 --> @sirtoobii commented on GitHub (May 25, 2025): Hi @Sh4dow998 Yes, thank you for the email. I couldn’t reproduce the described behavior, and I honestly can't think of a (technical) reason why the script would ignore a specific email address. To help debug this, I’ve added an option to dump all emails read from LDAP to the DEBUG log facility. Please try the version at [fix/user_not_adopted](https://github.com/sirtoobii/vaultwarden_ldap_sync/tree/fix/user_not_adopted) with `DUMP_EMAIL_SOURCE=1`, and confirm whether the affected user appears in that list.
kerem commented 2026-03-04 00:59:41 +03:00
Author
Owner
Copy link

@Sh4dow998 commented on GitHub (Jun 16, 2025):

Hi @tobiasbossert,

Apologies for the late reply — I was on vacation for the past three weeks. I’ve tested the fix/user_not_adopted version with DUMP_EMAIL_SOURCE=1, and the issue has been resolved: the affected user now appears in the list and was correctly invited.

<!-- gh-comment-id:2975890419 --> @Sh4dow998 commented on GitHub (Jun 16, 2025): Hi @tobiasbossert, Apologies for the late reply — I was on vacation for the past three weeks. I’ve tested the `fix/user_not_adopted` version with `DUMP_EMAIL_SOURCE=1`, and the issue has been resolved: the affected user now appears in the list and was correctly invited.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
fix/cookie_store_location
fix/user_not_adopted
big-refactor
test/GeorgeIT
1.1.0
1.0.0
Labels
Clear labels   
bug

   
good first issue

   
help wanted

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
question

   
question
No labels
bug
good first issue
help wanted
pull-request
question
question
question
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/vaultwarden_ldap_sync#10
No description provided.