When a group name in Microsoft AD is changed in any way (Capitalization, fixing a spelling mistake, or just changing the group name) after a sync of the corresponding user directory in JIRA, there is one of 2 things that will happen.

1. if it is a capitalization change, the sync errors out with a error such as:

2011-09-13 10:39:08,022 QuartzWorker-1 ERROR ServiceRunner     [atlassian.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ 10000 ].
com.atlassian.crowd.embedded.ofbiz.db.DataAccessException: org.ofbiz.core.entity.GenericEntityException: while inserting: [GenericEntity:Group][id,11184][groupName,TestJiraGROUP][updatedDate,2011-09-13 10:39:07.937][description,null][directoryId,10000][lowerDescription,null][active,1][local,0][type,GROUP][lowerGroupName,testjiragroup][createdDate,2011-09-13 10:39:07.937] (SQL Exception while executing the following:INSERT INTO jiraschema.cwd_group (ID, group_name, lower_group_name, active, local, created_date, updated_date, description, lower_description, group_type, directory_id) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (Cannot insert duplicate key row in object 'jiraschema.cwd_group' with unique index 'uk_group_name_dir_id'. The duplicate key value is (testjiragroup, 10000).))

In order to resolve that, you have to manually edit the database to fix the capitalization of the group name. Then the sync completes successfully.

2. Any other change in the group name results in a new group being created in JIRA and the old group still staying around. Therefore, any membership updates to this group will only be applied to locations using the new group name, and not to the old group name. If the old group name is not being used anywhere, the group is still kept around after subsequent syncs as well. So, it appears as though there is no clean-up of groups that are no longer in AD and therefore, may run into issues in the future with duplicate group names.

I do have one suggestion to aid in resolving this issue. You could base all group entries in the database by using the objectGUID or the objectSid to determine if JIRA is looking at the same group as a previous entry.

Also, it would be nice for a group clean-up to be done during the sync so that if a group is not used in JIRA anymore, and it is not in the user directory being synced, then it will be removed from JIRA so that the groups do not grow out of control.

We are in the process of upgrading to 4.3.4, and were thinking about using full AD sync to control users, but since we have found this issue, we are having to re-address this to determine if we will still move forward with the upgrade. If this were to be resolved in at least a future release, then we can live with this for a little while since groups don't usually change that frequently.

Thanks.