Incoherent user "enabled" status across admin interfaces

[dawagner]

Prerequisites

• I have searched the existing Closed AND Open Issues AND Discussions
• I have searched and read the documentation

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

[stefan0xC]

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.

[dawagner]

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

[stefan0xC]

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:

vaultwarden/src/api/admin.rs

Lines 414 to 420 in 7c7f4f5

	#[post("/users/<user_id>/delete", format = "application/json")]
	async fn delete_user(user_id: UserId, token: AdminToken, conn: DbConn) -> EmptyResult {
	let user = get_user_or_404(&user_id, &conn).await?;
	// Get the membership records before deleting the actual user
	let memberships = Membership::find_any_state_by_user(&user_id, &conn).await;
	let res = user.delete(&conn).await;

[BlackDex]

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.

[dawagner]

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?