nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can I change default access groups to synced groups?

Paul O_Shaughnessy

Since migrating to SSO new users are no longer added to our jira-users and confluence-users groups. Instead, users are added to groups synced from our idp. We have replicated global permissions, jira permission schemes and space permissions and added the groups to product access but it is not possible to switch default access groups from the product permissions admin page. The option is not available and the tooltip says: "this is a read only group and cannot be set as default" so I have two questions:

1. Is it possible to change default access groups to a synced group and if so how?

2. Given that permissions and access is aligned with the default access groups, what difference does it make to change default access group? (bearing in mind that new users aren't automatically added to the group by our idp)

Accepted answers

All comments

Petter Larsen

I also wondered about this.

Robert Allen_mr8bvw

Additionally, the text on the right reads: "When a user is granted access to a product, they will be added to the products default access group."

This makes it sound like that when a user is synced down from the IDP, Atlassian is supposed to add them automatically to jira-users and confluence-users. But this is also not happening for us.

Jeremy Odle_wbippw

We are having the same issue. Users are being auto-provisioned, but then we are still having to go in and assign them to the `jira-software-users` group (even though it is set as the default access group). Has anyone found a solution?

neville_ys8x2a

Did anyone ever solve this? I'm having this issue two years later...

Paul O_Shaughnessy

FYI: We never did get an answer to this question.

Here's what we did:

First, we gave the appropriate managed groups product access

Then we added the new managed groups to space defaults (confluence) and permission schemes where jira-users had been used (for Jira) - leaving the jira-users and confluence-users in place in the short term.

After that, we stopped adding people to jira-users and confluence-users. We have a slow trickle of calls for people who couldn't get access. In every case - this meant a specific project or space hadn't been updated so we fixed the space in question.

We never got hit with too many calls and over time the calls stopped with the new groups being key and the jira-users and confluence-users being legacy.

A few gotchas:

* Personal spaces - we fixed up team space permissions reasonably quickly, but personal spaces were not accessible by default for the admin group.

* JIra group permissions - this needs to be done on a project by project basis. It's OK to update permission schemes, but project roles are often granted to groups such as jira-users

* service accounts - for our IDP we only had human accounts to service accounts are not managed and still still in jira-users and confluence-users. if you want to clean out these groups, be careful. Also, the groups remain default.

I'm sure there is a better solution, but having migrated over and with no obvious alternative, this worked out OK for us in the end. It meant no big-bang transition and a very slow move to the new process, but all our users are now automatically synced and we have very little account management to worry about

A A Ron Geister _Trundl_

Typically I have used other IDP groups and not used the defaults to allow users to gain access to a site.
This is because from IDP I can give them the proper groups and put the groups in projects as defaults as either Team Member or User role or however you have your roles configured.
Example:
IDP locked group: jira-software-okta (whatever your idp service is)

All software projects that are not restricted IP projects now make this a default group.
Set this as the default role for Team Member or Developer in the roles in system settings.

Now when you create a new users and give them that group in IDP console they will get the access to all projects that have this role.

You can do the same for all products. I would sit with your IDP engineer and map these out to come up with best solution.

This will allow you to by pass using the default licensing.
You will have to add these groups to default access. You will not be able to make this group the default but it will still give you access from IDP as long as its mapped to product access.

Kieren _SmolSoftware_

Hi @Paul O_Shaughnessy

This has been an issue for a while and unfortunately there is still no feature within admin.atlassian.com that will allow you to do this. The solution you posted (granting product access to a managed group) is a good solution, but as you discovered it's not perfect.

There is an upcoming app that could help with this, essentially we're solving ACCESS-604. It's about to be released in a free closed beta (around mid December 2023). If you're interested, contact us via our website smolsoftware.com to be a part of the beta. I'll also update this post when the app is launched publicly in January 2024.

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

A A Ron Geister _Trundl_

To make this work you have to go to each domain that is authorized and click into it to set default product access.

Once you set that up each IDP user will go into the default licensing group once they are provisioned. I have seen this fail for some users also recently on some sites but I have seen it work on most. For those sites that are not working we set the IDP groups to have to have product access after the IDP groups are provisioned you can now go into that group to set product access. This is only on new billing on old billing you have to still do this from the product access area.

Kieren _SmolSoftware_

The Approved Domain feature only works when a user tries to access a product for the first time. It does not work on a user being synced into the user list. That’s probably why you’re seeing inconsistency, some users are immediately accessing Jira/Confluence and others take some time before accessing them.

When a user is granted access to a product, they will be added to the products default access group.

This is only referring to manual invitations unfortunately, it doesn’t apply to IdPs. This is exactly why we’re building the app I mentioned! 😂 To allow users sync’d via an IdP to be automatically put into the default product groups.

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

Kieren _SmolSoftware_

We've released an app to fix the issue of not being able to sync users into the default product access groups. The Admin Automation app can automatically add or remove users from any group into another group, and to solve other challenging and time consuming admin tasks. For example:

You can sync an IdP group into any of the Atlassian default product groups.
You can remove any user from jira-users-* or confluence-users-*, if they're not in your special 'All users' group. This is a simple and quick way to ensure that, no matter which other invite features are turned on, users cannot get access to any products without being in your 'key' group.
You can sync users from the jira-users-* group into the confluence-users-* group, ensuring that Jira users always have access to Confluence as well.

Hopefully the app can help some of the people on this thread!

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

identity-manager