How to link Atlassian Admin groups with SSO users' groups (Azure AD)

[Nick Block]

Hello all,

We have Atlassian Access configured with our SSO provider (Azure AD). This is working great for our tools (i.e. Bitbucket), but I'm not finding a way to associate the Atlassian Account groups with our SSO groups. I'd like to be able to associate an Atlassian Admin administrators' group with a user's membership in an AD group. Is this possible? Can you point me in the direction of where to set this relationship up? Happy to implement SCIM if that's the right answer here.

Thanks!

[Ed Letifov _TechTime - New Zealand_ · Accepted solution]

Hi @Nick Block 

In general you will have to go through what @Kieren _SmolSoftware_ desribed.

Just for clarity:

1) The reason why you want to make your current groups stop being default is because:

• Users get added to the default group when a Cloud admin invites a user to the site in the Cloud UI and gives access to product (via checkboxes, rather than explicitly assigning groups). So a default group must be writeable by Cloud.
• groups synced from IdP are not writeable by Cloud, they are locked, so can't be used as default

2) You associate groups by name, i.e., your only straightforward option is to create groups in Azure AD that have the same exact name as what Atlassian has already used in Cloud.

I am yet to meet an organisation where Azure AD admins just accepted the Atlassian naming convention.

3) If you do not create groups with matching name in Azure AD but instead go with your Azure AD admin names, e.g. some Atlassian-Jira-Application-Admin monstrosity you can still use that in Product Access setup.

However, to also use them INSIDE the product you will have to manually change all occurrences of jira-admins-xxxx to Atlassian-Jira-Application-Admin in every scheme, every role, every workflow, board, dashboard, and filter. Good luck with this, I don't envy you. Perhaps someone will write an app for this one day?

4) Specifically for bitbucket – for now there is no way to use IdP groups in Bitbucket, but watch this space.

[Kieren _SmolSoftware_ · Accepted solution]

Hi @Nick Block 

I don't have any information on how to do this for Bitbucket specifically, but I can help with how to do it within admin.atlassian.com. And if you're in one of the beta customer groups that get to link their Bitbucket product with their admin.atlassian.com org, then this would also work for your Bitbucket product.

If you're on the new user management UI and have Atlassian Access and SCIM then you'll have control over which groups grant admin roles to your products.

There are a few default admin groups you can control via SCIM (where xxxx is your site name):

1. jira-admins-xxxx
2. confluence-admins-xxxx
3. bitbucket-admins-xxxx (if bitbucket is connected)
4. There are other default admin groups for other Atlassian products, you can find them here

Before you can sync to these groups, you need to remove them as the default group for their respective product admin roles.

i.e. Manually create a new group in admin.atlassian.com called default-jira-admins-xxxx, grant it the Jira admin role then make it the default group for the Jira admin role. Next, remove Jira-admins-xxxx as the default group.

Once you've created the new groups and removed the old/original groups as default groups, you can "take over" the old/original groups... If you create the old group names in your IdP, and select them to sync to your Atlassian organisation, when they sync across they'll 'take over' the existing old groups and replace the users within those groups. The admin roles will also be preserved. Now you're able to sync users into the product admin groups.

You cannot control the site-admin group or the org-admin groups via SCIM though.

This is all a fair bit of work to do and can get quite complex with multiple products... My company is building an automation app to help Atlassian customers with issues just like this (and one that also works for the site-admin and org-admin groups!). In summary we're solving the problem in ACCESS-604. We're planning to release in a free closed beta around mid March 2024. If you're interested, contact us via our website smolsoftware.com to be a part of the beta.

-Kieren
Co-Founder @ Smol Software | Ex-Atlassian

[jessica.huebner]

Hi Kieren!

I am fairly new to the Atlassian Admin world and syncing through Azure. 

Following what you have above seems straight forward for my use case, however, based on the fact that Azure groups are not writeable by Atlassian, doesn't this mean the default groups would still need to be set as the admin group you created so that your Azure group could be named the original default group? For clarity, the steps would be:

1. Create a new group, default-jira-admin-xxxx
2. Set this as a default group in Jira Administration in Apps tab
3. Remove the default group setting from the existing jira-admin-xxxx group
4. Create a new group in Azure and call it jira-admin-xxxx
5. Sync Azure with Atlassian Admin

Does structuring my Azure in this way for both admin groups and default user groups automatically create user accounts and send invite emails to respective products when they get added to my groups in Azure, even though they are not set as default groups, for the reason mentioned above?

Appreciate your insight :) 

[Kieren _SmolSoftware_]

Hi @jessica.huebner 

1. Yes you’re correct, you still need a non-azure group to be a default group. This will still be used for manual invites or if a user self joins via the User Product Access settings. The main benefit of re-using any of the default groups is they already have all the correct global/space/product settings on them, you don't need to set them up on a new group them. See point #4 for another option for this.

2. Any user synced from Azure to Atlassian, no matter the group, will have a user created for them (if they don’t already have one). They will also get an email indicating that they have a new Atlassian Account.

3. Structuring you groups this way will not trigger any invitation emails. Invite emails are only triggered via manually inviting or manually adding users to products in the admin UI.

4. Another option I should mention is a marketplace app that I build, Admin Automations. With this app you could create rules to sync users between your Azure groups and the default groups, without having to make any of the group changes you mentioned above. The benefit of this is it's simpler and less risk for new Admins, when making changes to the Atlassian product settings.
There's also additional rules and filters that Atlassian Admin and your IdP can't do today; such as selecting all users with a non-company email (like gmail.com) and suspending them or removing their product access, for increased security.

Hope that helps!

[jessica.huebner]

Thanks so much @Kieren _SmolSoftware_ ! 

When a user gets added to the Azure group, which in turn has been configured so that group has User access to Jira in my admin center, is there anything else that needs to be done to ensure they have the access they need (aside from of course also ensuring the Azure group is of course defined in my project roles, global permissions, and projects)?

[Kieren _SmolSoftware_]

Nope, that should be it. The project roles, global permissions and project settings are the final piece.

Your Atlassian Guard settings/auth policies could also affect the user access, such as IP allowlists. But that’s outside the scope of Product Access we’ve been discussing.