Azure AD Default Groups

[Gary Williams]

Hi all,

New to the community and JSM, couple of hoping quick questions as can't work out a solution here ...

1. How does the "All users from Azure AD" get built, is this derived from from all the unique users in selected sync groups?

2. If we set up the default group names in Azure AD to sync i.e. "jira-servicemanagement-customers-xxxxxxxx" they are not updating in Atlassian, is there any reason for this?

Regards,

Gary

[Kieren]

Hi @Gary Williams 

1. Yes, this is a unique group that is created the first time you sync your IdP. It has the unique set of all the users you're syncing to the Atlassian directory.

2. This has been an issue for a while and unfortunately there is no feature within admin.atlassian.com that will allow you to sync an IdP group to a default group. It's a huge pain point for Atlassian Admins who want to utilise the default or custom Atlassian groups for both SCIM and non-SCIM sync'd users.

The reason you cannot sync to the default groups, is the Invite and product access features in Atlassian Admin rely on the default groups to be able to grant users access to products. When a group is being sync'd to, it becomes read only in the Atlassian Admin UI, so admins can no longer invite and control product access via those default groups.

There are two ways to get around this:

1. There is an upcoming app we're building that will solve this, essentially we're solving ACCESS-604. It's about to be released in a free closed beta, if you're interested contact us via our website smolsoftware.com to be a part of the beta.

2. Create a new group called New-JSM-Customers-Default, make that group the default product access group for JSM. Remove the default group setting from jira-servicemanagement-customers-<sitename> and then you can sync to your old default group (jira-servicemanagement-customers-<sitename>) and it will retain your in product JSM security settings. This is a complex way to go about it, and means that users who get invited vs sync'd will be in different groups and require the same security settings to be created in JSM for the new group New-JSM-Customers-Default.

Hope that helps.

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

[Gary Williams]

Thanks for your time Kieren, will take a look.

[Ed Letifov _TechTime - New Zealand_]

@Gary Williams 

Just to be precise the term "default" is overloaded here... You were asking about filling groups that come with a site by default, i.e. controlling them from the IdP.

However these groups also (by default, as in "out-of-the-box") are used as "default groups denoting access to a product behind a single checkbox in the invite screen" and they cannot be readonly.

What @Kieren is suggesting is unlinking these groups from this "default group for a product" functionality.

Having said this, if you are controlling access to products from IdP, then "invite" should really not be used by your site admins (maybe for external users only – and in this case maybe the group should explicitly mention "external-users").

For our customers we practically always create "default-do-not-use" group and assign that as the default group, and treat appearance of any user in this group as processes being broken (admins using invite functionality instead of relying on IdP to do its job)

[Kieren]

For our customers we practically always create "default-do-not-use" group and assign that as the default group, and treat appearance of any user in this group as processes being broken (admins using invite functionality instead of relying on IdP to do its job)

This is a great idea, I'll suggest it to others too. Thanks @Ed Letifov _TechTime - New Zealand_ 

[Gary Williams]

Thanks @Ed Letifov _TechTime - New Zealand_ 

Gives me a clearer picture now, all access is going to be managed by AD Azure and the inviting isn't required as at the moment its all internal staff and using SAML.

I've put these default groups with no members and updated the description, the only group we'll use for key IT staff will be org-admin, other than that all group access will be managed through AD.