Renaming LDAP Groups and consequences for Confluence, JIRA Bitbucket, Bamboo and Crowd

Question

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.

SG_p11cl8 · Answer

Hi @Craig Castle-Mead

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.

Craig Castle-Mead_20fp9z · Answer

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

Craig Castle-Mead_20fp9z · Answer

Hey @SG

You’re well aware of the problem here it’s sounds like. When the groups change in AD - the Atlassian applications will see them as a brand new group that happens to have the same members as the old group, which it now thinks has been deleted, so any permissions relying on the old group are broken.

Bitbucket and bamboo are a lot simpler database structures for the groups than Confluence and Jira (especially if you use lots of marketplace apps in Jira/Conf). The approach we’ve taken is to work on reverse engineering the database structure of the core apps and marketplace apps (and these may/do constantly change too), to try and understand where a group may be referenced, and then just have a run list of changes. Some of these (eg: switching groups in permission schemes/space permissions) may easily be scriptable - but some you may just need to handle through the UI.

unless you have a decent outage window where you know users will be OK with a lot of broken access, it might be worth adding another Crowd directory that’s an internal Crowd directory and replicating your current AD groups and memberships - before the AD changes are made, these will effectively just be the same memberships, however as soon as the AD changes are made, you’ll at least have the old groups effectively available while you refactor the applications. Once you’re confident all/most of your changes are made in the apps and referencing the AD groups, just unmap the internal directory from the Crowd Applications. If you have any critical issues and need to quickly grant previous access back again, you can remap the directory to the apps while you investigate/fix further.

CCM