Migration (Guard) maintain groups/role/product access

[matthew_hickman]

So we have Guard Configured on a test instance and have proved SSO is working and also SCIM provisioning of users, but I need some help to understand the migration of users, e.g. how to we maintain product access, group and role member ship etc

[Darryl Lee]

Oh man. I feel like this could be a whole article. Here's some top-of-mind takeaways:

Product Access

Atlassian sets up a bunch of default groups for Product Access, Admin, etc etc.

• Default groups and permissions 

You don't have to use these, although it probably makes your life easier.

However if you're migrating from DC, then you may already have IdP groups that you use for these purposes. It is possible to sync those groups and use them for Product Access, Admin, groups, roles, etc. (See my section on Groups below.)

One important thing to know is that if you use the "toggle switches" to grant a user access to Jira/Confluence/whatever site, it adds them to the "DEFAULT ACCESS GROUP" defined in Product Access settings. So you cannot have the DEFAULT be a managed (synced with your IdP) group, since Atlassian won't be able to add users to it.

I did recently find out about an app (from @Kieren) that lets you "sync" the default groups with our managed groups, which is another approach:

• Admin Automations for Jira and User Management 

Groups

• We initially setup Atlassian Guard (then known as Access) to provision users and groups via SCIM.
• We have a LOT of groups that we use for Project permissions, shared filters, space/page permissions, etc.
• From my understanding of SCIM, our Identity team would have to explicitly add each of these groups to enable them to be "synced" with Atlassian.
• Many of these groups are Nested.
• SCIM provisioning doesn't support Nested groups.
• SO, we ended up switching to Azure AD syncing for nested groups, which can also be its own article.

Confluence Default Space Permissions

Thing I learned the hard way - Confluence's default space permissions use Atlassian's default groups. So if you previously granted access to all spaces using your own groups, you'll want to change these defaults.

I ended up with a bunch of Personal Spaces with incorrect permissions because I didn't discover this until later.

Interesting note: if you have to do a bunch of bulk-changing of group permissions, you technically could do this with the API, but it seemed so daunting, I asked support about it and as part of migration support (I think) they were able to do this for me, probably in the database.

Other stuff

Ooof, there's probably something I've forgotten. OH OH OH. FORMER/INACTIVE users.

After migration we have several Confluence pages "Owned" (previously "Created by") "Former User". This kind of sucks.

The way to avoid this sounds... annoying (and if you didn't know about it, you can't go back and fix it):

Deleted or inactive users and directories 

Any deleted users or users in inactive directories that are referenced in your Jira data will appear as Former user after migration. If you need to migrate the references to these users, reactivate them (or the directory) before migrating.

Users with disabled status in your Server site will be migrated as active but without any product access. This means they will not be counted as active Jira users for billing purposes. Learn how users are managed in Cloud

SO.... you might want to test that. Having to bulk reactivate all of your former users during the migration and then bulk deactivating them sounds... complicated. We didn't know about this, didn't do it, and now suffer with pages where we don't know who previously worked on them, which is a bummer.

Anyways yeah, I'm sure there's something I've forgotten. Got a bit of PTSD.

[Kieren _SmolSoftware_]

Great answer @Darryl Lee.

I feel like this could be a whole article.

I started writing an article on our website about different types of security setups within Atlassian products, from our last community thread. It can get very complex...

@matthew_hickman - I'd also add that more info on your current Server/DC security setup/policies/groups will help provide better guidance on how to replicate it in Cloud. e.g. If you need to have separate groups that grant access to each Jira Project and everything is really locked down; vs everything is open and only a few projects are locked down to individual users. Both are doable in Cloud, and there are multiple ways you could achieve it. This could mean the difference between managing thousands of groups with 5-10 users per group, vs managing 100 groups with 50-1000 users per group...

Your scale and complexity will determine how easy or hard some methods of securing your products are.

There's also user authentication policies, both for internal users (within your company) and external users to consider, https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/