First off, I added this under the topic "Crowd" but it affects the complete stack of (on-prem) Atlassian tools .
Background: We are using the on-prem server versions of crowd, jira, confluence, bitbucket and bamboo. Crowd is connected to our windows active directory and syncs groups and users. Permissions in confluence, jira etc. are based on those active directory groups.
Today we need to change those group names to reflect organisational changes in our company. Everyone who was in this position probably already knows where I am going: changing group names (or making them reflect active directory group name changes) in any of the mentioned Atlassian products is not as easy as one might think.
This almost 20 year old feature request describes the issue. TL;DR is Atlassian uses the group name as the UID and therefore simply changing the name of a group changes the UID and breaks all assigned permissions.
While there are documented (but unsupported) SQL queries at least for JIRA and Confluence to somewhat workaround this limitation, I could not find such documents for Bitbucket and Bamboo. Also it being unsupported means if we break things we are all alone and support won't/can't help. No bueno.
We are not getting around renaming those groups, so one way or another I will have to migrate those permissions. I was just wondering how if anyone has done this in the past. Trust that the prepared SQL queries are working as expected? Spend days doing it manually? Also any hints or tricks would be greatly appreciated.
I’d absolutely recommend the internal directory approach above if you’re not sure when the AD changes are going to be made, or your AD > Crowd > application sync time isn’t near real time.
You could also do the opposite of this by setting up an internal directory and add the new group names to it, then start adding the new (empty) groups to the applications ahead of the AD change, once AD is changed, the applications will see the groups with members in them, then you can start removing the old (now empty) groups from the various locations in the apps.
CCM
Thanks for the response and the described approaches. I was kind of hoping to hear some user experiences about using the documented SQL 'scripts' - specially for jira. Creating a second directory will take some pressure of by providing an easy rollback, however it does not reduce the amount of time needed to make the actual changes.
I still hope Atlassian considers this much requested feature for on-prem versions of the tools soon - because this is not a one-off thing but such changes in the active directory structure can and will happen again.