mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2025-12-10 01:10:09 +03:00
Account recovery administration not enforcing Single orginization policy to be enabled. #409
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghost on GitHub.
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
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
@BlackDex commented on GitHub:
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.
@louisfgr commented on GitHub:
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.
@ghost commented on GitHub:
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.