Incoherent user "enabled" status across admin interfaces #2426

Open
opened 2026-02-20 08:17:42 -05:00 by deekerman · 5 comments
Owner

Originally created by @dawagner on GitHub (Oct 30, 2025).

Prerequisites

Vaultwarden Support String

Your environment (Generated via diagnostics page)

  • Vaultwarden version: v1.34.3
  • Web-vault version: v2025.7.0
  • OS/Arch: linux/x86_64
  • Running within a container: true (Base: Debian)
  • Database type: PostgreSQL
  • Database version: PostgreSQL 15.14 (Debian 15.14-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit
  • Uses config.json: false
  • Uses a reverse proxy: true
  • IP Header check: true (X-Forwarded-For)
  • Internet access: true
  • Internet access via a proxy: false
  • DNS Check: true
  • Browser/Server Time Check: true
  • Server/NTP Time Check: true
  • Domain Configuration Check: false
  • HTTPS Check: true
  • Websocket Check: true
  • HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Config:

{
  "_duo_akey": null,
  "_enable_duo": true,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_conn_init": "",
  "database_max_conns": 10,
  "database_timeout": 30,
  "database_url": "**********://*******************************************************",
  "db_connection_retries": 60,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://***************************",
  "domain_origin": "*****://***************************",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": false,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 504,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Forwarded-For",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": 1073741824,
  "org_creation_users": "****",
  "org_events_enabled": true,
  "org_groups_enabled": true,
  "password_hints_allowed": true,
  "password_iterations": 600000,
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": true,
  "sends_folder": "data/sends",
  "show_password_hint": false,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "*****************************",
  "smtp_from_name": "Vaultwarden",
  "smtp_host": "**********************",
  "smtp_password": "***",
  "smtp_port": 465,
  "smtp_security": "force_tls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "*********************",
  "templates_folder": "data/templates",
  "tmp_folder": "data/tmp",
  "trash_auto_delete_days": 1095,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": 1073741824,
  "user_send_limit": 1073741824,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Vaultwarden Build Version

1.34.3

Deployment method

Official Container Image

Custom deployment method

No response

Reverse Proxy

haproxy

Host/Server Operating System

Linux

Operating System Version

No response

Clients

Web Vault

Client Version

2025.7.0

Steps To Reproduce

I found this out while struggling to invite a user. Said user was formerly invited/enabled and subsequently revoked ; I don't remember exactly what I did in between but I ended up removing the user entirely and create it again via an LDAP synchronization.

The user was unable to sign in. They got a "user has been disabled" error message even though they appeared as enabled in the admin console.

I was going to report this issue but the ticket creation steps require going to /admin/diagnostics and this led me to discover this second admin interface. In that interface's, the user did appear as disabled. I was able to re-enable them there and solve my issue but I thought you might like to hear about this discrepancy.

Expected Result

N/A

Actual Result

N/A

Logs


Screenshots or Videos

No response

Additional Context

No response

Originally created by @dawagner on GitHub (Oct 30, 2025). ### Prerequisites - [x] I have searched the existing **Closed _AND_ Open** [Issues](https://github.com/dani-garcia/vaultwarden/issues?q=is%3Aissue%20) **_AND_** [Discussions](https://github.com/dani-garcia/vaultwarden/discussions?discussions_q=) - [x] I have searched and read the [documentation](https://github.com/dani-garcia/vaultwarden/wiki/) ### Vaultwarden Support String ### Your environment (Generated via diagnostics page) * Vaultwarden version: v1.34.3 * Web-vault version: v2025.7.0 * OS/Arch: linux/x86_64 * Running within a container: true (Base: Debian) * Database type: PostgreSQL * Database version: PostgreSQL 15.14 (Debian 15.14-0+deb12u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-bit * Uses config.json: false * Uses a reverse proxy: true * IP Header check: true (X-Forwarded-For) * Internet access: true * Internet access via a proxy: false * DNS Check: true * Browser/Server Time Check: true * Server/NTP Time Check: true * Domain Configuration Check: false * HTTPS Check: true * Websocket Check: true * HTTP Response Checks: true ### Config & Details (Generated via diagnostics page) <details><summary>Show Config & Details</summary> **Config:** ```json { "_duo_akey": null, "_enable_duo": true, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_icon_service_csp": "", "_icon_service_url": "", "_ip_header_enabled": true, "_max_note_size": 10000, "_smtp_img_src": "***:", "admin_ratelimit_max_burst": 3, "admin_ratelimit_seconds": 300, "admin_session_lifetime": 20, "admin_token": "***", "allowed_connect_src": "", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "auth_request_purge_schedule": "30 * * * * *", "authenticator_disable_time_drift": false, "data_folder": "data", "database_conn_init": "", "database_max_conns": 10, "database_timeout": 30, "database_url": "**********://*******************************************************", "db_connection_retries": 60, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://***************************", "domain_origin": "*****://***************************", "domain_path": "", "domain_set": true, "duo_context_purge_schedule": "30 * * * * *", "duo_host": null, "duo_ikey": null, "duo_skey": null, "duo_use_iframe": false, "email_2fa_auto_fallback": false, "email_2fa_enforce_on_verified_invite": false, "email_attempts_limit": 3, "email_change_allowed": false, "email_expiration_time": 600, "email_token_size": 6, "emergency_access_allowed": true, "emergency_notification_reminder_schedule": "0 3 * * * *", "emergency_request_timeout_schedule": "0 7 * * * *", "enable_db_wal": true, "enable_websocket": true, "enforce_single_org_with_reset_pw_policy": false, "event_cleanup_schedule": "0 10 0 * * *", "events_days_retain": null, "experimental_client_feature_flags": "", "extended_logging": true, "helo_name": null, "hibp_api_key": null, "http_request_block_non_global_ips": true, "http_request_block_regex": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "icon_redirect_code": 302, "icon_service": "internal", "incomplete_2fa_schedule": "30 * * * * *", "incomplete_2fa_time_limit": 3, "increase_note_size_limit": false, "invitation_expiration_hours": 504, "invitation_org_name": "Vaultwarden", "invitations_allowed": true, "ip_header": "X-Forwarded-For", "job_poll_interval_ms": 30000, "log_file": null, "log_level": "info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "login_ratelimit_max_burst": 10, "login_ratelimit_seconds": 60, "org_attachment_limit": 1073741824, "org_creation_users": "****", "org_events_enabled": true, "org_groups_enabled": true, "password_hints_allowed": true, "password_iterations": 600000, "push_enabled": false, "push_identity_uri": "https://identity.bitwarden.com", "push_installation_id": "***", "push_installation_key": "***", "push_relay_uri": "https://push.bitwarden.com", "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "send_purge_schedule": "0 5 * * * *", "sendmail_command": null, "sends_allowed": true, "sends_folder": "data/sends", "show_password_hint": false, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_embed_images": true, "smtp_explicit_tls": null, "smtp_from": "*****************************", "smtp_from_name": "Vaultwarden", "smtp_host": "**********************", "smtp_password": "***", "smtp_port": 465, "smtp_security": "force_tls", "smtp_ssl": null, "smtp_timeout": 15, "smtp_username": "*********************", "templates_folder": "data/templates", "tmp_folder": "data/tmp", "trash_auto_delete_days": 1095, "trash_purge_schedule": "0 5 0 * * *", "use_sendmail": false, "use_syslog": false, "user_attachment_limit": 1073741824, "user_send_limit": 1073741824, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ``` </details> ### Vaultwarden Build Version 1.34.3 ### Deployment method Official Container Image ### Custom deployment method _No response_ ### Reverse Proxy haproxy ### Host/Server Operating System Linux ### Operating System Version _No response_ ### Clients Web Vault ### Client Version 2025.7.0 ### Steps To Reproduce I found this out while struggling to invite a user. Said user was formerly invited/enabled and subsequently revoked ; I don't remember exactly what I did in between but I ended up removing the user entirely and create it again via an LDAP synchronization. The user was unable to sign in. They got a "user has been disabled" error message **even though they appeared as enabled** in the admin console. I was going to report this issue but the ticket creation steps require going to `/admin/diagnostics` and this led me to discover this second admin interface. In *that* interface's, the user **did appear as disabled**. I was able to re-enable them there and solve my issue but I thought you might like to hear about this discrepancy. ### Expected Result N/A ### Actual Result N/A ### Logs ```text ``` ### Screenshots or Videos _No response_ ### Additional Context _No response_
Author
Owner

@stefan0xC commented on GitHub (Nov 24, 2025):

How did you remove the user? As far as I know a user can only be disabled via the /admin interface. Removing a user from an Organization via the Admin Console should not disable the user account and removing them via the /admin interface should delete everything associated with that record.

@stefan0xC commented on GitHub (Nov 24, 2025): How did you remove the user? As far as I know a user can only be disabled via the `/admin` interface. Removing a user from an Organization via the Admin Console should not disable the user account and removing them via the `/admin` interface should delete everything associated with that record.
Author
Owner

@dawagner commented on GitHub (Nov 24, 2025):

How did you remove the user?

In two steps, calling two different APIs:

  1. api/organizations/{orga_id}/users/{user_id}/revoke
  2. admin/users/{user_id_in_admin_api}/disable

I'm not sure I can say why it's done like this: I inherited this procedure.

Best regards

@dawagner commented on GitHub (Nov 24, 2025): > How did you remove the user? In two steps, calling two different APIs: 1. `api/organizations/{orga_id}/users/{user_id}/revoke` 2. `admin/users/{user_id_in_admin_api}/disable` I'm not sure I can say why it's done like this: I inherited this procedure. Best regards
Author
Owner

@stefan0xC commented on GitHub (Nov 24, 2025):

Well, that's at least an explanation for why the user account was disabled.

Because there's a different endpoint (/admin/users/<user_id>/delete) to delete a user:
github.com/dani-garcia/vaultwarden@7c7f4f5d4f/src/api/admin.rs (L414-L420)

@stefan0xC commented on GitHub (Nov 24, 2025): Well, that's at least an explanation for why the user account was disabled. Because there's a different endpoint (`/admin/users/<user_id>/delete`) to delete a user: https://github.com/dani-garcia/vaultwarden/blob/7c7f4f5d4fab0d2b6b3c241bfcd787934f971f98/src/api/admin.rs#L414-L420
Author
Owner

@BlackDex commented on GitHub (Nov 24, 2025):

I also think we can't really adjust this, as Bitwarden doesn't provide a feature to disable a user in general, in the sense to prevent the login.

I also think that removing a user from all ORG's when disabled might also cause confusion of course.
And, there is no way for us to somehow add a notice that the user is disabled in a normal way.

@BlackDex commented on GitHub (Nov 24, 2025): I also think we can't really adjust this, as Bitwarden doesn't provide a feature to disable a user in general, in the sense to prevent the login. I also think that removing a user from all ORG's when disabled might also cause confusion of course. And, there is no way for us to somehow add a notice that the user is disabled in a normal way.
Author
Owner

@dawagner commented on GitHub (Nov 25, 2025):

Thanks for your insights!

Our procedure allows for the possibility that the disabled/revoked/whatever user might be allowed back within a few months (if not, we eventually delete them completely from vaultwarden). If I understand correctly, we should just call the admin/users/{user_id_in_admin_api}/disable endpoint and not the other one?

@dawagner commented on GitHub (Nov 25, 2025): Thanks for your insights! Our procedure allows for the possibility that the disabled/revoked/whatever user might be allowed back within a few months (if not, we eventually delete them completely from vaultwarden). If I understand correctly, we should just call the `admin/users/{user_id_in_admin_api}/disable` endpoint and not the other one?
Sign in to join this conversation.
No milestone
No project
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#2426
No description provided.