Using Atlassian Guard with Dynamic Groups in Entra-ID

[Carsten Severin _KUMAVISION AG_]

Atlassian Guard is a central security tool for Atlassian Cloud environments. It provides features such as Single Sign-On (SSO), Two-Factor Authentication (2FA), data protection, and real-time threat detection to ensure security and compliance.

Implementing Atlassian Guard reduces the risks of unauthorized access and simplifies user management. In particular, Two-Factor Authentication (2FA) prevents repeated credential entries while enhancing security. Furthermore, integration with Entra-ID enables efficient role and group management.

Dynamic groups automatically update their memberships based on defined rules and attributes, reducing manual administration and optimizing resource allocation.

Who has already gained experience with how Atlassian Guard handles dynamic groups in Entra-ID? What recommendations or best practices have you derived so far?

[Richard Scholtes]

We already had Okta in place as we started with Atlassian Cloud, so we already had Okta handling dynamic groups, SSO and 2FA before Atlassian Guard. While we still have AD and AAD in place and handle rights there, all that Atlassian sees and interacts with is Okta.

[OP]

AFAIK Atlassian doesn't care whether the group is dynamic or manual, uses it like any other group. We are using SCIM with Entra ID and most of our user provisioning groups are dynamic in Entra.
Only thing it doesn't like is nested groups, it can't get the members of the subgroup, so you have to assign the permissions and licenses in Atlassian to the first level (sub)groups.

[Rune Rasmussen]

Guard handles dynamic groups just fine.
We have one dynamic group that contains all active employees.
This groups is provisioned and set to give the Customer role for JSM.

Other dynamic groups provide in-app access/permissions.

We avoid using dynamic groups to grant licenses to avoid suddenly granting unintended licenses and for auditing reasons.