Summary

This was reported on a Stash/Bitbucket Server instance with embedded Crowd. Using LDAP with local groups, having a local group named "foo", and then adding the group 'foo' in the LDAP directory will cause it to not synchronise, but the user is unable to delete the local group either. Stash/Bitbucket Server Logs report:

2016-03-10 18:32:25,522 DEBUG [clusterScheduler_Worker-7]  c.a.c.d.DbCachingRemoteChangeOperations group [ foo ] in directory [ 917505 ] matches local group of same name, skipping

Environment

• Stash 3.11.2
• LDAP has been configured with "Read Only, with Local Groups" in Stash/Bitbucket Server.
• Membership Aggregation enabled in Stash/Bitbucket Server
• Nested Groups enabled
• LDAP user directory is set at the highest priority (first user directory)

Steps to Reproduce

1. Configure Stash/Bitbucket Server with LDAP with local groups
2. Create a local group name "foo" to match an extsing LDAP group "foo"
3. Trigger a sync with LDAP

Expected Results

Group Memberships are synced for users correctly that belong to the "foo" group.

Actual Results

Group Memberships are empty or not synced correctly for users belonging to group "foo" and following message is reported in Stash/Bitbucket Server logs:

2016-03-10 18:32:25,522 DEBUG [clusterScheduler_Worker-7]  c.a.c.d.DbCachingRemoteChangeOperations group [ foo ] in directory [ 917505 ] matches local group of same name, skipping

Additionally, the local group can't be removed via the UI.

Notes

Querying the Stash/Bitbucket Server database on the "cwd_group" table shows that there are two groups by the name of "foo" - one local and one LDAP but both are enabled:

| 4128772 | foo                                          | foo                                          | 2014-10-29 07:29:20 | 2014-10-29 07:29:20 | NULL                                                                                                                                                                                                                                 | GROUP      |       917505 | T         | T        |

| 6783242 | foo                                          | foo                                          | 2016-02-18 17:21:29 | 2016-02-18 17:21:29 | NULL                                                                                                                                                                                                                                 | GROUP      |      1802241 | T         | F        |

Note that the Directory id '917505' corresponds to the local user directory and has the "is_local" field set to 'T'.

Workaround

1. Ensure you have a complete backup of your Stash/Bitbucket Server instance.
2. Stop the application
3. Update the above record in your database for local user directory '917505' and set the 'is_local' flag to 'F'.
4. Restart the application.
5. Note that if the group has any local memberships (that are not on the remote LDAP server), these would be lost after the change. The following might be reported in Stash/Bitbucket Server logs on subsequent synchronization with the LDAP server:

   2016-05-19 07:49:00,567 DEBUG [clusterScheduler_Worker-4]  c.a.s.i.crowd.HibernateMembershipDao Deleting object: com.atlassian.crowd.model.membership.InternalMembership@5f84bbfd[parentId=4128772,childId=983314,membershipType=GROUP_USER,groupType=GROUP,parentName=foo,lowerParentName=foo,childName=foochild,lowerChildName=foochild,directoryId=917505]
   2016-05-19 07:49:00,567 DEBUG [clusterScheduler_Worker-4]  c.a.s.i.e.TransactionAwareEventPublisher Deferring publishing for GroupMembershipDeletedEvent until AFTER_COMMIT
   
   2016-05-19 07:49:00,573 INFO  [clusterScheduler_Worker-4]  c.a.c.d.DbCachingRemoteChangeOperations removed [ 1 ] user members from [ foo ] in [ 14ms ]
   2016-05-19 07:49:00,577 DEBUG [clusterScheduler_Worker-4]  c.a.s.i.e.TransactionAwareEventPublisher Publishing GroupMembershipDeletedEvent after commit