Internal instance, expanding admins (or not)

[Rita Nygren]

I was looking forward to the mods to site-admin vs org admin,but it doesn't seem to be helping my internal confluence instance.  We are using the Azure Connect for Nested Groups, which will sync a list of azure groups as seen under Security/Identify providers every 4 hours.

My service desk team adds additional groups relatively often (several times a week?).  They don't have access to this location, so they need to contact an org admin to adjust the security of a confluence space (once the azure group is added to Atlassian and the sync runs, they can do the permissions work on the space).

I had hopes that the recent mods to site-admin could get them to where they could admin the user groups, and if we only used inside-atlassian invitations, that would make sense, but right now, actually adding new groups from Azure is not something I can give them without giving them OrgAdmin, which I am loathe to do.

Am I missing something?  Anyone else hitting this limitation?  Got any work arounds?

[Kieren _SmolSoftware_]

Hi @Rita Nygren 

Just so I understand the current process:

Your service desk team will create new groups in Azure. Those new groups get sync'd to your Atlassian Org via SCIM. They then contact you to update various confluence space settings to include these new groups. Is that about right?

I think you have two options:

1. Grant some of the service desk staff the Confluence Product Admin role. They can use this role to access the Confluence Space settings and make any changes to the group permissions they need to. This role will also give them access to the Confluence docs/pages/content, and they will count towards your Confluence and Atlassian Access bills.

2. If they need to add Confluence Product access to some of the new groups; Grant some of the service desk staff the Confluence Product Admin role, and a few of their staff the User Access Admin role for that Confluence product. The User Access Admin role has fewer permissions in the Org than an Org Admin, they can update group product access settings. And the Confluence Product Admin role will allow them to manage the Confluence space settings.

Your comment "right now, actually adding new groups from Azure is not something I can give them without giving them OrgAdmin", makes me think I'm missing a key function you need the service desk team to use that is only available to the Org Admin role. Can you tell me what you think you need them to do that is only available to the Org Admin role?

-Kieren
Founder @ Smol Software | Ex-Atlassian

[Rita Nygren]

Nope.  My service desk get requests to change or add permissions on a space.  They create new groups in Azure.  They are now stuck until someone else comes up and adds those groups to the SCIM sync list.

(once that sync is done, they are fine & have the rights they need to update the perms per space.  You have outlined a solution downstream that I don't need.)

I want them to be able to adjust which groups get sync'd, without having org admin privileges.

[Rita Nygren]

Oh heck, I see what I did.  It's technically still scim, but the tool in question is called "Azure Connect for Nested Groups".  Does that make the problem more visible?

[Kieren _SmolSoftware_]

"Azure Connect for Nested Groups" - I've not heard of this tool before. Is this an App that has been installed from the Atlassian Marketplace?

If you're referring to how Atlassian Access is setup here, then you'd need to select "Sync all users and groups" to avoid having to select each new specific group you need to sync.

If it is an app, then they might be relying on an API key or token to setup and execute the group and user sync. If it's an app that only site admins or org admins can use, then I'm afraid the only thing you could do is talk to the App developer to ask them if they have a workaround for you.

"I want them to be able to adjust which groups get sync'd, without having org admin privileges."
If we're talking about Atlassian Access, there's no role other than Org Admin (right now) you can grant to allow a user to access the IdP sync settings.

[Rita Nygren]

https://support.atlassian.com/provisioning-users/docs/connect-and-sync-azure-ad-for-nested-groups/

This became available last year.  While onpremAD groups could be nested, as we move into Azure, the legacy scim provisioning allowed only flat groups - it ignored any nests, which is quite annoying.  But we trade out one issue for another - one needs to actively add each group to the sync list, and only the org admin can do it. 

I kinda wish this had been spelled out before we moved to this connection type.