[GH-ISSUE #4855] Account recovery administration not enforcing Single orginization policy to be enabled. #2003

New issue

Closed

opened 2026-03-03 02:14:13 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 02:14:13 +03:00

Owner

Originally created by @ghost on GitHub (Aug 14, 2024).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4855

Originally assigned to: @BlackDex on GitHub.

Subject of the issue

Account recovery administration is not enforcing "Single orginization" policy to be enabled. You are able to enable the "Account recovery administration" organization policy without the "Single organization" policy being enabled.

Deployment environment

vaultwarden version: 1.32.0

Install method: Docker through tag: vaultwarden/server:1.32.0
Clients used:
Reverse proxy and version: nginx
MySQL/MariaDB or PostgreSQL version:
Other relevant details:

Steps to reproduce

Enable the Account recovery administration without the Single Organizaton policy being enabled.

Expected behaviour

Not being able to enable it.

Actual behaviour

You can enable it

Troubleshooting data

Originally created by @ghost on GitHub (Aug 14, 2024). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4855 Originally assigned to: @BlackDex on GitHub.   ### Subject of the issue  Account recovery administration is not enforcing "Single orginization" policy to be enabled. You are able to enable the "Account recovery administration" organization policy without the "Single organization" policy being enabled. ### Deployment environment     * vaultwarden version: 1.32.0  * Install method: Docker through tag: vaultwarden/server:1.32.0 * Clients used:  * Reverse proxy and version:  nginx * MySQL/MariaDB or PostgreSQL version:  * Other relevant details: ### Steps to reproduce  Enable the Account recovery administration without the Single Organizaton policy being enabled. ### Expected behaviour  Not being able to enable it. ### Actual behaviour  You can enable it ### Troubleshooting data  ![image](https://github.com/user-attachments/assets/bad9fd3c-d704-45b9-8b0f-7f7f4468913d)

kerem

2026-03-03 02:14:13 +03:00

closed this issue
added the
enhancement

low priority
labels

kerem commented

2026-03-03 02:14:14 +03:00

Author

Owner

@louisfgr commented on GitHub (Aug 16, 2024):

I mentioned this some time ago in #4113. I'm afraid that this requirement could cause some problems for users who need access to multiple organizations if those organizations don't want to give up the account recovery option.

Even though I think this requirement makes sense for Bitwarden's use case, I find it impractical for Vaultwarden.
Especially since it was recommended to use organisations before group support was introduced (#1623).

Regardless of this, the warning in the policy settings should of course be in line with reality, whether this means adjusting the functionality or the warning.

@louisfgr commented on GitHub (Aug 16, 2024): I mentioned this some time ago in #4113. I'm afraid that this requirement could cause some problems for users who need access to multiple organizations if those organizations don't want to give up the account recovery option. Even though I think this requirement makes sense for Bitwarden's use case, I find it impractical for Vaultwarden. Especially since it was recommended to use organisations before group support was introduced (#1623). Regardless of this, the warning in the policy settings should of course be in line with reality, whether this means adjusting the functionality or the warning.

kerem commented

2026-03-03 02:14:14 +03:00

Author

Owner

@ghost commented on GitHub (Aug 16, 2024):

Not sure how I missed your earlier post about this. I apologize for this.

One concern about this setting not being enforced is if you reset User A's password, you can gain access to other organizations which that User A is also a part of. I suspect that this might be the reason for the inital setting of enforcing one organization per user with this policy.
My (possible wrongfull) impression is that organiazitons are suppose to be kind of indepentent from each other. This not being enforced kinda negates that.

@ghost commented on GitHub (Aug 16, 2024): Not sure how I missed your earlier post about this. I apologize for this. One concern about this setting not being enforced is if you reset User A's password, you can gain access to other organizations which that User A is also a part of. I suspect that this might be the reason for the inital setting of enforcing one organization per user with this policy. My (possible wrongfull) impression is that organiazitons are suppose to be kind of indepentent from each other. This not being enforced kinda negates that.

kerem commented

2026-03-03 02:14:14 +03:00

Author

Owner

@BlackDex commented on GitHub (Aug 19, 2024):

The only way i can see to fix this issue is to add another config option which will enforce this option if wanted/needed.
Which we could make a default in a later release for example.

@BlackDex commented on GitHub (Aug 19, 2024): The only way i can see to fix this issue is to add another config option which will enforce this option if wanted/needed. Which we could make a default in a later release for example.