Uploaded image for project: 'Crowd Data Center'
  1. Crowd Data Center
  2. CWD-3764

Changing groupname casing causes intermittent loss of group membership in Confluence and JIRA

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 2.7.2
    • 2.7
    • None
    • None

      Diagnosis

      Group names have had their case changed in the source directory. The following will appear in the atlassian-crowd.log:

      2013-09-12 01:44:15,408 WARN [scheduler_Worker-9] [atlassian.crowd.directory.DbCachingRemoteChangeOperations] findGroupsToUpdate remote group name [ group1 ] casing differs from local group name [ GROUP1 ]. Group details will be kept updated, but the group name cannot be updated

      Steps to Reproduce

      1. Set up Crowd 2.7 and Confluence 5.4.1 (these are the versions I used, but this bug has been apparent since at least Confluence 5.3.1, JIRA 6.1.2 and Stash 2.11.2)
      2. Create a Crowd user
      3. Create a group called 'group1'
      4. Add the user to the group
      5. Create a group in Crowd called confluence-administrators and add the user to it
      6. Set up Crowd as a directory in Confluence (or JIRA) and sync it
      7. Change the name of the group in tthe Confluence (or JIRA) database to 'GROUP1' and sync again
        (This is to simulate the casing being changed in an external directory, eg AD. You cannot change the case directly in Crowd, but if AD is connected to Crowd and Crowd is connected to Confluence, when the casing changes in AD this issue occurs)
      8. Log in to Confluence as the user.
      9. Go to Admin > Users in Confluence (confirm the password when prompted)
      10. View your group memberships and confirm you are a member of GROUP1
      11. Go to the Dashboard
      12. Click in the top banner to drop admin rights
      13. Go back to Admin > Users, confirming password again when prompted
      14. Confirm that you are no longer a member of GROUP1
      15. Repeat steps 11 - 13 and confirm that you are a member of GROUP1 again
      16. Repeat again and confirm the membership is gone

      NB: This is similar to old issues that used to occur when the casing changed, but they all occurred on intermittent directory syncs. That does not appear to be occurring anymore, and it is now only authenticating into the admin section of both JIRA and Confluence that causes this issue.

            [CWD-3764] Changing groupname casing causes intermittent loss of group membership in Confluence and JIRA

            stipx added a comment -

            Is there any way to not get these warnings any more? I mean is there something I can do to fix the group name in Bitbucket 7.7.1 to not send me an email every day because there is a group that was renamed?

            stipx added a comment - Is there any way to not get these warnings any more? I mean is there something I can do to fix the group name in Bitbucket 7.7.1 to not send me an email every day because there is a group that was renamed?

            Robin Kargoll added a comment -

            Hi, we just upgraded Confluence from 5.2.3 to 5.4.4 and are now having this issue of intermittent loss of group memberships. When will this fix be available in a download version?

            FYI - this does not appear to be related to any changes being made to the group casing as we have not made any changes to the groups that disappear – just seems to affect many, but not all of our mixed case group names, especially our distribution lists.

            Robin Kargoll added a comment - Hi, we just upgraded Confluence from 5.2.3 to 5.4.4 and are now having this issue of intermittent loss of group memberships. When will this fix be available in a download version? FYI - this does not appear to be related to any changes being made to the group casing as we have not made any changes to the groups that disappear – just seems to affect many, but not all of our mixed case group names, especially our distribution lists.

            Diego Berrueta added a comment - - edited

            I've debugged this. When a group is renamed (casing-only), DbCachingRemoteDirectory puts it in the groupsToAddUser and groupsToRemoveUser bags at the same time. Then, new memberships are added and duplicated membership errors are ignored, which means that the operation behaves idempotently. Then, "old" memberships are removed, causing the existing membership to be removed.

            Swapping the order in which these operations are performed should fix the problem.

            Diego Berrueta added a comment - - edited I've debugged this. When a group is renamed (casing-only), DbCachingRemoteDirectory puts it in the groupsToAddUser and groupsToRemoveUser bags at the same time. Then, new memberships are added and duplicated membership errors are ignored, which means that the operation behaves idempotently. Then, "old" memberships are removed, causing the existing membership to be removed. Swapping the order in which these operations are performed should fix the problem.

            Diego Berrueta added a comment -

            I have reproduced this issue with just Crowd (no Confluence or any other product). Here are the simplified instructions:

            1. Set up a LDAP server with a user and two groups. The user must be a member of the groups. In my case, I used OpenLDAP.
            2. Create a LDAP connector directory in Crowd and point it to the LDAP server.
            3. Synchronise the directory.
            4. Verify that Crowd picks the user and both memberships.
            5. Add the directory to the list of directories mapped to the 'crowd' application, enable 'Allow all to authenticate'. Directory order is not relevant, as far as there are no clashes in the user/group names.
            6. In the LDAP server, do a case-only name change of one of the groups. For instance, rename the group from 'group1' to 'Group1'.
            7. Logout from Crowd as an admin, and login again as the LDAP user.
            8. Check the user's memberships, either in the user console and the admin console (after logging again as an admin).

            Expected result: user is still a member of both groups.

            Observed result: the user has lost the membership to the group that was renamed, but maintains the membership to the group that didn't change. Synchronising the directory again restores the lost membership.

            Diego Berrueta added a comment - I have reproduced this issue with just Crowd (no Confluence or any other product). Here are the simplified instructions: Set up a LDAP server with a user and two groups. The user must be a member of the groups. In my case, I used OpenLDAP. Create a LDAP connector directory in Crowd and point it to the LDAP server. Synchronise the directory. Verify that Crowd picks the user and both memberships. Add the directory to the list of directories mapped to the 'crowd' application, enable 'Allow all to authenticate'. Directory order is not relevant, as far as there are no clashes in the user/group names. In the LDAP server, do a case-only name change of one of the groups. For instance, rename the group from 'group1' to 'Group1'. Logout from Crowd as an admin, and login again as the LDAP user. Check the user's memberships, either in the user console and the admin console (after logging again as an admin). Expected result: user is still a member of both groups. Observed result: the user has lost the membership to the group that was renamed, but maintains the membership to the group that didn't change. Synchronising the directory again restores the lost membership.

              dberrueta Diego Berrueta
              dunterwurzacher Denise Unterwurzacher [Atlassian] (Inactive)
              Affected customers:
              1 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: