Hi, Access Community! This AMA will go live February 8th. Start submitting your questions below, upvote others' submissions and watch this space as we will be answering your questions after we close submissions on February 22nd. Want to learn more about Atlassian Access? Click HERE.
Here’s how it works:
|
Community moderators have prevented the ability to post new answers.
CLOUD-10325 / Product Requests allow Enterprise customers to prevent their claimed / managed users from creating signing up to new Atlassian products / sites.
When will this be made available to all Atlassian Access plans? If not, why not?
FREE Trello / Bitbucket in particular causes a significant impact to the plans for Standard and Premium customers. Enterprises are arguably less financially impacted as their enterprise users (intentionally licenced users) already have Atlassian Access included.
This functionality was voted for by all Atlassian Access users however only Enterprise users are benefiting from a range of Atlassian Access features.
Hi David, we are invested in providing more admin controls to manage creation of new Atlassian products/sites.
We recently launched a feature in Atlassian Access that allows admins to add themselves as org admins to products created by their managed users, allowing them to determine the next best steps for that particular product. Note: This feature does not work for Trello at the moment.
Learn more about it here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi! What are some pitfalls to avoid when setting up Atlassian Access?
Also, what prep work/data clean-up would you recommend beforehand?
Any additional best-practices before/during set-up?
Thanks!! 😊
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Kim - Yes, some key considerations are:
Consider who in your organization needs access to Atlassian products and choose an appropriate way to create accounts for them in Atlassian.
Consider what security posture is ideal for your organization and map those to controls in Atlassian Access. To get started quickly, you can use the controls Atlassian recommends , even if your team is stretched thin.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Is a feature planned to transfer all user accounts of the associated domain to the new default policy after a directory has been added?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Patricia, you can export a CSV with all your managed accounts (navigate to Directory > Managed accounts and then click on “Export accounts”), and then use that CSV to add users in bulk to the new authentication policy:
Select Security > Authentication policies >
Select Edit.
Select Members tab > Add members.
Select Bulk entry > Select Upload to add CSV file (only up to 10,000 emails from your managed accounts are allowed).
Select Add.
This process is explained in our documentation (see “to enter members in bulk” under “Add members to your authentication policies”)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
When linking domains to a directory, it would be very handy if you could directly select all the domains that have previously been claimed with a single click and not have to select all the domains individually.
Is there a trick for this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Patricia, thanks for the feedback. We’ll take this improvement to the domain-linking interface into consideration for our roadmap.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Further questions about Automatic setup Provisioning (Entra ID)
You can claim domains twice via "Automatically set up user provisioning", for example if you have verified a domain before setting up Atlassian Access. In this case, the domains are then shown twice in drop-downs. Is this a intended behavior?
The "All Directory Sync" via the "Automatically set up user provisioning" function can take a very long time, depending on the system. A rough progress bar would be great.
Are further options for limiting the All Directory Sync planned for the future, for example only synchronising security groups?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Patricia, we are aware of the “duplicate domains” issue that you described - we know that this is confusing and we appreciate your feedback on the need to improve this.
From your description, it sounds like you’re talking about the Azure AD syncing for nested groups. This feature does provide the ability to sync specific groups rather than all groups as part of the setting titled “Select users to sync”. Please review our documentation for more details.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We have some Questions regarding SAML configuration:
Will there be a way of configuring SAML via metadata.xml? With URL would be optimal to be able to switch certificates purely via the IdP?
It would be great to display the configuration URLs of Access ("SP Entity ID" & "SP Assertion Consumer Service URL") on one page together with the configuration. Currently you have to enter the placeholders in the Entity ID to be able to download the certificate, for example. Is a feature planned for this?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Patricia, on your first question - would a public API that helps you configure SAML for Atlassian Cloud (as opposed to having to set it up in the Atlassian Administration UI) meet your requirements?
Thanks for sharing your feedback on the friction during the SAML configuration process. We’ll evaluate improvements to make SAML configuration more streamlined.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
In our ecosystem, we have differing levels of users that interact with Jira in different ways. In the case of our largest population of users that have high add/remove change rates, we face some challenges that don't have easy answers like assigning the right authentication policy so we can vary session termination values without impact to other users.
As a Premium customer, how can I use automation to handle the high volume changes occurring in our Access user population and easily automate authentication policy assignment or change assignment en masse for any given population?
We also have a use case where our HR team interacts with personnel through email in JSM, and the inclusion of special Customer records using this email address is pervasive in every project throughout Jira, and this has an adverse effect on selecting the right "user" in Jira Software projects that are only used to seeing 200+ users. Now they also see all the HR Customers when selecting an Assignee or Reporter.
Is there anyway with Access to limit the visibility of any population of user records such that they don't appear in a Project? Any tricks outside of Access?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi James, thanks for sharing feedback on the need for automated assignment of users to authentication policies. We’re currently exploring more flexible/automated mechanisms for applying authentication policies as well as offering APIs for moving users between authentication policies.
Regarding your use case of limiting the set of users displayed in user pickers in Jira Software projects, please refer to this documentation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We need to see additional functionality in managing Atlassian Access - Session Termination settings, going beyond the Reset Sessions button, reflected this in a request at https://jira.atlassian.com/browse/ACCESS-1740 - noted there are quite a few adjacent/similar requests, would like to see Atlassian tackle this promptly as it has implications for your FEDRAMP ambitions and customer base.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Brian, two updates on this:
We’re currently exploring functionality to automatically rotate sessions for users while they are logged in. This is part of an ongoing effort to enhance session security. This will be separate from the “idle session duration” setting that exists today in that it will apply to users who are actively using Atlassian products.
As part of Atlassian Cloud for Government, the upcoming FedRAMP Moderate solution that’s on our Cloud roadmap, we plan to offer hard session limits (24 hours with hard logout)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We need to see additional functionality in managing Session Termination settings, reflected this in a request at https://jira.atlassian.com/browse/ACCESS-1740 - noted there are quite a few adjacent/similar requests, would like to see Atlassian tackle this promptly as it has implications for your FEDRAMP ambitions and customer base.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.