-
Bug
-
Resolution: Fixed
-
Medium
-
3.5, 4.0, 4.1, 4.2, 4.3, 5.3, 5.9.10, 5.9.4, 5.10.4, 6.0.2
-
47
-
Severity 1 - Critical
-
Steps to Reproduce
- Add a connection to LDAP in Confluence Admin >> User Directories with the Read Only, with Local Groups option
- Sync the directory and make sure that LDAP users are returned
- Add 1 LDAP user to a local group (membership)
- Change the User Object Filter in the directory's configuration in Confluence Admin >> User Directories to a dummy filter, such as the following:
(&(objectclass=inetorgperson)(cn=dummynonexistentuser))
- Sync the directory again (Notice that the LDAP users are missing)
- Revert the User Object Filter to the previous working filter
- Sync the directory again (notice that the LDAP users are back, but their local group memberships are gone)
Workaround
- Restore the instance's database backup to a new database (i.e. not production) prior to the point where memberships were lost.
- Follow the instructions in step 1 of Migrating Local Group Memberships Between Directories to generate a CSV file of users and their memberships.
- Run through the rest of the instructions in that KB article to populate the production instance's group memberships.
- has a regression in
-
CONFSERVER-58751 User Loses all Local Group Memberships If LDAP Sync is Unable to find the User, but the User appears again in subsequent syncs
- Closed
- is caused by
-
CWD-4849 User loses all local group memberships if LDAP sync is unable to find the user, but the user appears again in subsequent syncs
- Long Term Backlog
- is related to
-
CWD-4179 synchronization of large groups in Crowd timeout and starts to remove users from cache
- Closed
-
KRAK-258 Loading...
- relates to
-
JRASERVER-24937 When a user is deleted in AD or Crowd, JIRA could keep the user in JIRA as an inactive user
- Closed
- was cloned as
-
CONFSERVER-58751 User Loses all Local Group Memberships If LDAP Sync is Unable to find the User, but the User appears again in subsequent syncs
- Closed
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...