Created a fresh Vaultwarden instance. (kept config.json from existing test instance)
Created a new User
Created a new Organisation
Logged into BWDC with new Organisation API Key
Configured BWDC to work with my AD
Synced Users and Groups with BWDC
-> Users are now listed as Invited in the Organisation and the Admin Panel
Cleared Sync Cache in BWDC
Synced Users and Groups with BWDC
-> Users are now listed as a full member (Invite accepted and confirmed by Admin) in the Organisation but still as invited in the Admin Panel.
If I now manually create one of those users and log in, I can not access the Organisation.
Expected behaviour
User gets an Invitation and is able to join the Organisation. The described setup works perfectly on my 1.29.2 live system.
Actual behaviour
In the Admin Panel the User is not shown as part of any Organisation.
The Organisation shows the user as a full member.
Originally created by @louisfgr on GitHub (Nov 28, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4114
### Subject of the issue
Users who are invited to an organisation via BWDC are in a strange state between added and invited.
### Your environment (Generated via diagnostics page)
* Vaultwarden version: v1.30.1
* Web-vault version: v2023.10.0
* OS/Arch: linux/x86_64
* Running within Docker: true (Base: Debian)
* Environment settings overridden: false
* Uses a reverse proxy: true
* IP Header check: true (X-Real-IP)
* 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: true
* HTTPS Check: true
* Database type: SQLite
* Database version: 3.44.0
* Clients used:
* Reverse proxy and version:
* Other relevant information:
### Config (Generated via diagnostics page)
<details><summary>Show Running Config</summary>
**Environment settings which are overridden:**
```json
{
"_duo_akey": null,
"_enable_duo": false,
"_enable_email_2fa": true,
"_enable_smtp": true,
"_enable_yubico": false,
"_icon_service_csp": "",
"_icon_service_url": "",
"_ip_header_enabled": true,
"_smtp_img_src": "cid:",
"admin_ratelimit_max_burst": 3,
"admin_ratelimit_seconds": 300,
"admin_session_lifetime": 20,
"admin_token": "***",
"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": 15,
"disable_2fa_remember": false,
"disable_admin_token": false,
"disable_icon_download": false,
"domain": "*****://**************************",
"domain_origin": "*****://**************************",
"domain_path": "",
"domain_set": true,
"duo_host": null,
"duo_ikey": null,
"duo_skey": null,
"email_attempts_limit": 3,
"email_change_allowed": true,
"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,
"event_cleanup_schedule": "0 10 0 * * *",
"events_days_retain": 60,
"extended_logging": true,
"helo_name": null,
"hibp_api_key": "***",
"icon_blacklist_non_global_ips": false,
"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,
"invitation_expiration_hours": 336,
"invitation_org_name": "BitwardenTest",
"invitations_allowed": true,
"ip_header": "X-Real-IP",
"job_poll_interval_ms": 30000,
"log_file": "./data/vaultwarden.log",
"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": null,
"org_creation_users": "******************",
"org_events_enabled": true,
"org_groups_enabled": true,
"password_hints_allowed": true,
"password_iterations": 100000,
"push_enabled": false,
"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": true,
"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": "BitwardenTest",
"smtp_host": "**************",
"smtp_password": null,
"smtp_port": 25,
"smtp_security": "off",
"smtp_ssl": null,
"smtp_timeout": 15,
"smtp_username": null,
"templates_folder": "data/templates",
"tmp_folder": "data/tmp",
"trash_auto_delete_days": 14,
"trash_purge_schedule": "0 5 0 * * *",
"use_sendmail": false,
"use_syslog": false,
"user_attachment_limit": null,
"web_vault_enabled": true,
"web_vault_folder": "web-vault/",
"websocket_address": "0.0.0.0",
"websocket_enabled": false,
"websocket_port": 3012,
"yubico_client_id": null,
"yubico_secret_key": null,
"yubico_server": null
}
```
</details>
### Steps to reproduce
1) Created a fresh Vaultwarden instance. (kept config.json from existing test instance)
2) Created a new User
3) Created a new Organisation
4) Logged into BWDC with new Organisation API Key
5) Configured BWDC to work with my AD
6) Synced Users and Groups with BWDC
-> Users are now listed as Invited in the Organisation and the Admin Panel
7) Cleared Sync Cache in BWDC
8) Synced Users and Groups with BWDC
-> Users are now listed as a full member (Invite accepted and confirmed by Admin) in the Organisation but still as invited in the Admin Panel.
If I now manually create one of those users and log in, I can not access the Organisation.
### Expected behaviour
User gets an Invitation and is able to join the Organisation. The described setup works perfectly on my 1.29.2 live system.
### Actual behaviour
In the Admin Panel the User is not shown as part of any Organisation.
The Organisation shows the user as a full member.
GiteaMirror
added the bug label 2026-04-23 06:18:57 -05:00
Can confirm this is an issue. I've noticed also that users show up as joined the organization, even though in reality they are still invited.
Incase it helps for tracking down the issue I've noticed the following:
You can revoke then re-enable the user, which seems to make the user show back up as the correct invited state.
In the database the users_organizations status is in a not normal value (If I recall correctly)
<!-- gh-comment-id:1835625890 -->
@gigaion commented on GitHub (Dec 1, 2023):
Can confirm this is an issue. I've noticed also that users show up as joined the organization, even though in reality they are still invited.
Incase it helps for tracking down the issue I've noticed the following:
- You can revoke then re-enable the user, which seems to make the user show back up as the correct invited state.
- In the database the users_organizations status is in a not normal value (If I recall correctly)
Can confirm BWDC is causing faulty issues here as well.
When inviting the user via BWDC, there will be a handful of people who will receive and invite. When they go to accept it, it shows as they've already accepted it although the Organization never shows up on their list.
Inside the vaultwarden Admin page it'll show they aren't part of the Organization. But on the vault itself in the Organization, they will show up as part of the Organization.
<!-- gh-comment-id:1839401048 -->
@jb2barrels commented on GitHub (Dec 4, 2023):
Can confirm BWDC is causing faulty issues here as well.
When inviting the user via BWDC, there will be a handful of people who will receive and invite. When they go to accept it, it shows as they've already accepted it although the Organization never shows up on their list.
Inside the vaultwarden Admin page it'll show they aren't part of the Organization. But on the vault itself in the Organization, they will show up as part of the Organization.
Which version of BWDC are you all using?
I'm for some reason not able to reproduce this at all.
I tried via the Desktop Tool, the CLI, clearing the sync-cache, removing all the users fully from the database, keeping the users there, accounts created or not, doesn't matter in any way.
I can create accounts, login, confirm access and see the org ciphers.
Groups are created, users are configured to the correct groups.
I also tested with SMTP/Mail disabled.
So, i'm a bit confused regarding where this is coming from.
Without a way to reproduce it's going to be hard for me to start trying to debug this.
Which type of Directory are you all using?
I'm using Active Directory / LDAP and unchecked This server uses Active Directory since I'm using LDAP.
<!-- gh-comment-id:1839600450 -->
@BlackDex commented on GitHub (Dec 4, 2023):
Which version of BWDC are you all using?
I'm for some reason not able to reproduce this at all.
I tried via the Desktop Tool, the CLI, clearing the sync-cache, removing all the users fully from the database, keeping the users there, accounts created or not, doesn't matter in any way.
I can create accounts, login, confirm access and see the org ciphers.
Groups are created, users are configured to the correct groups.
I also tested with SMTP/Mail disabled.
So, i'm a bit confused regarding where this is coming from.
Without a way to reproduce it's going to be hard for me to start trying to debug this.
Which type of Directory are you all using?
I'm using `Active Directory / LDAP` and unchecked `This server uses Active Directory` since I'm using LDAP.
So, i'm a bit confused regarding where this is coming from. Without a way to reproduce it's going to be hard for me to start trying to debug this.
I will attempt to reproduce the bug and provide steps here in near future.
Which type of Directory are you all using? I'm using Active Directory / LDAP and unchecked This server uses Active Directory since I'm using LDAP.
FreeIPA
<!-- gh-comment-id:1839729910 -->
@jb2barrels commented on GitHub (Dec 4, 2023):
> Which version of BWDC are you all using?
BWDC (CLI) version: 2023.10.0
> I can create accounts, login, confirm access and see the org ciphers. Groups are created, users are configured to the correct groups.
Here is a snippet from our BWDC config (some details censored):
> "directorySettings": {
> "directoryType": 0,
> "organizationId": "123-example-censored-id",
> "lastUserSync": "2023-12-04T23:32:53.252Z",
> "lastGroupSync": "2023-12-04T23:32:53.252Z",
> "lastSyncHash": "123-example-censored-hash",
> "syncingDir": null,
> "sync": {
> "users": true,
> "groups": true,
> "interval": 5,
> "removeDisabled": false,
> "overwriteExisting": true,
> "largeImport": false,
> "useEmailPrefixSuffix": false,
> "userFilter": "(&(uid=*)(memberOf=cn=vault_users_example,cn=groups,cn=accounts,dc=example,dc=lan))",
> "userPath": "cn=users,cn=accounts",
> "groupPath": "cn=groups,cn=accounts",
> "emailSuffix": "@example.com",
> "emailPrefixAttribute": "uid",
> "userObjectClass": "person",
> "userEmailAttribute": "mail",
> "memberAttribute": "member",
> "groupObjectClass": "groupOfNames",
> "groupNameAttribute": "name",
> "groupFilter": "(&(cn=vault_example_*))"
> },
> I also tested with SMTP/Mail disabled.
SMTP is enabled in our scenario.
> So, i'm a bit confused regarding where this is coming from. Without a way to reproduce it's going to be hard for me to start trying to debug this.
I will attempt to reproduce the bug and provide steps here in near future.
> Which type of Directory are you all using? I'm using `Active Directory / LDAP` and unchecked `This server uses Active Directory` since I'm using LDAP.
FreeIPA
<!-- gh-comment-id:1840277426 -->
@louisfgr commented on GitHub (Dec 5, 2023):
> Which version of BWDC are you all using?
Version 2022.11.0 Windows Desktop
> Which type of Directory are you all using?
`Active Directory / LDAP` with the `This server uses Active Directory` option checked, as we use AD
Snippet of my settings:
```
"directorySettings": {
"userDelta": null,
"groupDelta": null,
"lastGroupSync": "2023-11-28T09:38:13.185Z",
"lastUserSync": "2023-11-28T09:38:13.185Z",
"organizationId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"lastSyncHash": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"directoryType": 0,
"sync": {
"users": true,
"groups": true,
"interval": 5,
"removeDisabled": true,
"overwriteExisting": false,
"largeImport": false,
"useEmailPrefixSuffix": false,
"userFilter": "(&(objectCategory=Person)(sAMAccountName=*)(memberOf=CN=BitwardenTest_User-Sync,OU=BitwardenTest,OU=Bitwarden,OU=Groups,DC=sld,DC=tld))",
"userPath": "CN=Users",
"groupPath": "OU=BitwardenTest,OU=Bitwarden,OU=Groups",
"creationDateAttribute": "whenCreated",
"revisionDateAttribute": "whenChanged",
"emailPrefixAttribute": "sAMAccountName",
"memberAttribute": "member",
"userObjectClass": "person",
"groupObjectClass": "group",
"userEmailAttribute": "mail",
"groupNameAttribute": "name"
}
},
```
> I also tested with SMTP/Mail disabled.
SMTP is enabled in my case.
<!-- gh-comment-id:1840479389 -->
@BlackDex commented on GitHub (Dec 5, 2023):
@ louisfgr i would suggest to update to the 2023 version of the Directory Connector, both Desktop and CLI, See https://github.com/bitwarden/directory-connector/releases
@mightyBroccoli commented on GitHub (Dec 5, 2023):
I am able to reproduce the inconsistent user state event with the 2023.10 variant.
I checked with some affected users that their org invite was still working, which it was, but the user was not able to fully join the org. Removing the user's access to the org and re-inviting him manually worked though.
<!-- gh-comment-id:1840920596 -->
@mightyBroccoli commented on GitHub (Dec 5, 2023):
I am able to reproduce the inconsistent user state event with the 2023.10 variant.
I checked with some affected users that their org invite was still working, which it was, but the user was not able to fully join the org. Removing the user's access to the org and re-inviting him manually worked though.
I would need to good step-by-step way to reproduce this, else i'm not really able to tackle this at all.
<!-- gh-comment-id:1841023413 -->
@BlackDex commented on GitHub (Dec 5, 2023):
Invites expire after x amount of time.
I would need to good step-by-step way to reproduce this, else i'm not really able to tackle this at all.
@mightyBroccoli commented on GitHub (Dec 5, 2023):
At least in our deployment the problem presented itself with this string of actions:
create/ have org
setup BWDC
using Sync now to invite the list of users from ad
using Sync now again
now every user that was in the invited state ( not created an account, or "just" not accepted the org invite yet ) is removed from the invited tab and presented as a normal user.
<!-- gh-comment-id:1841358730 -->
@mightyBroccoli commented on GitHub (Dec 5, 2023):
At least in our deployment the problem presented itself with this string of actions:
- create/ have org
- setup BWDC
- using Sync now to invite the list of users from ad
- using Sync now again
- now every user that was in the invited state ( not created an account, or "just" not accepted the org invite yet ) is removed from the invited tab and presented as a normal user.
At least in our deployment the problem presented itself with this string of actions:
create/ have org
setup BWDC
using Sync now to invite the list of users from ad
using Sync now again
now every user that was in the invited state ( not created an account, or "just" not accepted the org invite yet ) is removed from the invited tab and presented as a normal user.
Can confirm this is similar steps to what we've determined on our end as well.
In addition if the user is marked incorrectly as normal, but you go to revoke the user they instantly get moved back to the invited tab. If you revoke them again from the invited tab, it'll move them to the revoked tab.
<!-- gh-comment-id:1841364175 -->
@jb2barrels commented on GitHub (Dec 5, 2023):
> At least in our deployment the problem presented itself with this string of actions:
>
> * create/ have org
> * setup BWDC
> * using Sync now to invite the list of users from ad
> * using Sync now again
> * now every user that was in the invited state ( not created an account, or "just" not accepted the org invite yet ) is removed from the invited tab and presented as a normal user.
Can confirm this is similar steps to what we've determined on our end as well.
In addition if the user is marked incorrectly as normal, but you go to revoke the user they instantly get moved back to the invited tab. If you revoke them again from the invited tab, it'll move them to the revoked tab.
I am seeing in the database table users_organizations that the users who are shown in the web vault as a full user (but actually still in the invited state) as having the status column with the integer value of 128.
If you do revoke using the web vault, it'll update their status to integer 0, and move them to the Invited tab in the web vault.
If you do another revoke, after the user was moved to the invited tab from the first revoke, status integer becomes -128
<!-- gh-comment-id:1843380139 -->
@jb2barrels commented on GitHub (Dec 6, 2023):
> Maybe someone else notices something.
I am seeing in the database table `users_organizations` that the users who are shown in the web vault as a full user (but actually still in the invited state) as having the `status` column with the integer value of 128.
If you do revoke using the web vault, it'll update their `status` to integer 0, and move them to the Invited tab in the web vault.
If you do another revoke, after the user was moved to the invited tab from the first revoke, `status` integer becomes -128
@louisfgr By chance is your Organization also force requiring 2step authentication?
Considering @BlackDex is unable to replicate the issue, I wonder if certain policies need to be enabled for it to replicate.
Here is our policies, incase that helps:
<!-- gh-comment-id:1843384531 -->
@jb2barrels commented on GitHub (Dec 6, 2023):
@louisfgr By chance is your Organization also force requiring 2step authentication?
Considering @BlackDex is unable to replicate the issue, I wonder if certain policies need to be enabled for it to replicate.
Here is our policies, incase that helps:
Thx for all the extra information. Hopefully i can reproduce this in some way. All other information is still welcome.
I have not yet checked running it multiple times, but from memory, those didn't caused issues before.
<!-- gh-comment-id:1843396431 -->
@BlackDex commented on GitHub (Dec 6, 2023):
Thx for all the extra information. Hopefully i can reproduce this in some way. All other information is still welcome.
I have not yet checked running it multiple times, but from memory, those didn't caused issues before.
Thx for all the extra information. Hopefully i can reproduce this in some way. All other information is still welcome.
I have not yet checked running it multiple times, but from memory, those didn't caused issues before.
Multiple times may potentially be required. I've noticed in some testing that the first round of invites all show up fine in the Web Vault. But upon another round of invites (usually after clearing BWDC cache) does it start to show issues.
<!-- gh-comment-id:1843402973 -->
@jb2barrels commented on GitHub (Dec 6, 2023):
> Thx for all the extra information. Hopefully i can reproduce this in some way. All other information is still welcome.
>
> I have not yet checked running it multiple times, but from memory, those didn't caused issues before.
Multiple times may potentially be required. I've noticed in some testing that the first round of invites all show up fine in the Web Vault. But upon another round of invites (usually after clearing BWDC cache) does it start to show issues.
I have been running into the same issue here using the Bitwarden Directory Connector. One of my sync settings was "Overwrite existing organization users based on current sync settings" - with this turned off, the issue doesn't appear to present.
ETA ... until a change is applied at next sync
<!-- gh-comment-id:1843411984 -->
@Kittin306 commented on GitHub (Dec 6, 2023):
I have been running into the same issue here using the Bitwarden Directory Connector. One of my sync settings was "Overwrite existing organization users based on current sync settings" - with this turned off, the issue doesn't appear to present.
ETA ... until a change is applied at next sync
I have been running into the same issue here using the Bitwarden Directory Connector. One of my sync settings was "Overwrite existing organization users based on current sync settings" - with this turned off, the issue doesn't appear to present.
Looking at the configs shared above, others also have that set to false.
<!-- gh-comment-id:1843417882 -->
@BlackDex commented on GitHub (Dec 6, 2023):
> I have been running into the same issue here using the Bitwarden Directory Connector. One of my sync settings was "Overwrite existing organization users based on current sync settings" - with this turned off, the issue doesn't appear to present.
Looking at the configs shared above, others also have that set to false.
Confirming that setting overwrite to off, overwriteExisting": false, still runs into the same issue.
The following was performed:
Ensured I had users already in the Invite status on Web Vault
Set overwriteExisting": false,
Performed sync, users still showing up as Invited in Web Vault.
Cleared cache
Ran sync again
Users now show up incorrectly as no longer Invited, and as already having joined the Organization per the Web Vault. (With status integer 128 in database).
I'm thinking signs are pointing to something to do with the cache clearing process.
<!-- gh-comment-id:1843520652 -->
@jb2barrels commented on GitHub (Dec 6, 2023):
Confirming that setting overwrite to off, `overwriteExisting": false,` still runs into the same issue.
The following was performed:
- Ensured I had users already in the Invite status on Web Vault
- Set `overwriteExisting": false,`
- Performed sync, users still showing up as Invited in Web Vault.
- Cleared cache
- Ran sync again
- Users now show up incorrectly as no longer Invited, and as already having joined the Organization per the Web Vault. (With status integer 128 in database).
I'm thinking signs are pointing to something to do with the cache clearing process.
I just had some time, and, clearing the cache, and run it again indeed triggers it for me to!
Thanks for you patients and extra reports!
Ill see what is going on here.
<!-- gh-comment-id:1843579509 -->
@BlackDex commented on GitHub (Dec 6, 2023):
I just had some time, and, clearing the cache, and run it again indeed triggers it for me to!
Thanks for you patients and extra reports!
Ill see what is going on here.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @louisfgr on GitHub (Nov 28, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/4114
Subject of the issue
Users who are invited to an organisation via BWDC are in a strange state between added and invited.
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden:
Steps to reproduce
-> Users are now listed as Invited in the Organisation and the Admin Panel
-> Users are now listed as a full member (Invite accepted and confirmed by Admin) in the Organisation but still as invited in the Admin Panel.
If I now manually create one of those users and log in, I can not access the Organisation.
Expected behaviour
User gets an Invitation and is able to join the Organisation. The described setup works perfectly on my 1.29.2 live system.
Actual behaviour
In the Admin Panel the User is not shown as part of any Organisation.
The Organisation shows the user as a full member.
@gigaion commented on GitHub (Dec 1, 2023):
Can confirm this is an issue. I've noticed also that users show up as joined the organization, even though in reality they are still invited.
Incase it helps for tracking down the issue I've noticed the following:
@jb2barrels commented on GitHub (Dec 4, 2023):
Can confirm BWDC is causing faulty issues here as well.
When inviting the user via BWDC, there will be a handful of people who will receive and invite. When they go to accept it, it shows as they've already accepted it although the Organization never shows up on their list.
Inside the vaultwarden Admin page it'll show they aren't part of the Organization. But on the vault itself in the Organization, they will show up as part of the Organization.
@BlackDex commented on GitHub (Dec 4, 2023):
Which version of BWDC are you all using?
I'm for some reason not able to reproduce this at all.
I tried via the Desktop Tool, the CLI, clearing the sync-cache, removing all the users fully from the database, keeping the users there, accounts created or not, doesn't matter in any way.
I can create accounts, login, confirm access and see the org ciphers.
Groups are created, users are configured to the correct groups.
I also tested with SMTP/Mail disabled.
So, i'm a bit confused regarding where this is coming from.
Without a way to reproduce it's going to be hard for me to start trying to debug this.
Which type of Directory are you all using?
I'm using
Active Directory / LDAPand uncheckedThis server uses Active Directorysince I'm using LDAP.@jb2barrels commented on GitHub (Dec 4, 2023):
BWDC (CLI) version: 2023.10.0
Here is a snippet from our BWDC config (some details censored):
SMTP is enabled in our scenario.
I will attempt to reproduce the bug and provide steps here in near future.
FreeIPA
@louisfgr commented on GitHub (Dec 5, 2023):
Version 2022.11.0 Windows Desktop
Active Directory / LDAPwith theThis server uses Active Directoryoption checked, as we use ADSnippet of my settings:
SMTP is enabled in my case.
@BlackDex commented on GitHub (Dec 5, 2023):
@ louisfgr i would suggest to update to the 2023 version of the Directory Connector, both Desktop and CLI, See https://github.com/bitwarden/directory-connector/releases
@mightyBroccoli commented on GitHub (Dec 5, 2023):
I am able to reproduce the inconsistent user state event with the 2023.10 variant.
I checked with some affected users that their org invite was still working, which it was, but the user was not able to fully join the org. Removing the user's access to the org and re-inviting him manually worked though.
@BlackDex commented on GitHub (Dec 5, 2023):
Invites expire after x amount of time.
I would need to good step-by-step way to reproduce this, else i'm not really able to tackle this at all.
@mightyBroccoli commented on GitHub (Dec 5, 2023):
At least in our deployment the problem presented itself with this string of actions:
@jb2barrels commented on GitHub (Dec 5, 2023):
Can confirm this is similar steps to what we've determined on our end as well.
In addition if the user is marked incorrectly as normal, but you go to revoke the user they instantly get moved back to the invited tab. If you revoke them again from the invited tab, it'll move them to the revoked tab.
@louisfgr commented on GitHub (Dec 6, 2023):
I looked at the log during synchronization but didn't notice anything unusual. Maybe someone else notices something.
Those were my steps:
I also upgraded my BWDC to 2023.10.0 for this test.
Log
@jb2barrels commented on GitHub (Dec 6, 2023):
I am seeing in the database table
users_organizationsthat the users who are shown in the web vault as a full user (but actually still in the invited state) as having thestatuscolumn with the integer value of 128.If you do revoke using the web vault, it'll update their
statusto integer 0, and move them to the Invited tab in the web vault.If you do another revoke, after the user was moved to the invited tab from the first revoke,
statusinteger becomes -128@jb2barrels commented on GitHub (Dec 6, 2023):
@louisfgr By chance is your Organization also force requiring 2step authentication?
Considering @BlackDex is unable to replicate the issue, I wonder if certain policies need to be enabled for it to replicate.
Here is our policies, incase that helps:
@BlackDex commented on GitHub (Dec 6, 2023):
Thx for all the extra information. Hopefully i can reproduce this in some way. All other information is still welcome.
I have not yet checked running it multiple times, but from memory, those didn't caused issues before.
@jb2barrels commented on GitHub (Dec 6, 2023):
Multiple times may potentially be required. I've noticed in some testing that the first round of invites all show up fine in the Web Vault. But upon another round of invites (usually after clearing BWDC cache) does it start to show issues.
@Kittin306 commented on GitHub (Dec 6, 2023):
I have been running into the same issue here using the Bitwarden Directory Connector. One of my sync settings was "Overwrite existing organization users based on current sync settings" - with this turned off, the issue doesn't appear to present.
ETA ... until a change is applied at next sync
@BlackDex commented on GitHub (Dec 6, 2023):
Looking at the configs shared above, others also have that set to false.
@jb2barrels commented on GitHub (Dec 6, 2023):
Confirming that setting overwrite to off,
overwriteExisting": false,still runs into the same issue.The following was performed:
overwriteExisting": false,I'm thinking signs are pointing to something to do with the cache clearing process.
@BlackDex commented on GitHub (Dec 6, 2023):
I just had some time, and, clearing the cache, and run it again indeed triggers it for me to!
Thanks for you patients and extra reports!
Ill see what is going on here.
@BlackDex commented on GitHub (Dec 6, 2023):
Well, that was an easy fix on a stupid bug (caused by my self).