You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
Thank you to all those who joined our What’s new in Atlassian Access webinar last week! We received so many great questions about existing functionality and newly released features of Access. I’ll cover the questions asked during the webinar and share some relevant resources on what was covered.
The questions below are categorized by these topics:
If you missed the webinar, the recording is available on-demand for you to watch at your own pace.
Access Product Guide - overview of each Access feature, why it helps, and how it works
Support Docs: Configure SAML single sign-on with an identity provider
Authentication policies - product guide | support docs | blog
Automatic product discovery - product guide | support docs
Identity providers - Google Workspace | Ping Identity
Statuspage - support docs
Org insights 2SV chart - product guide | support docs
CASB integration - product guide | McAfee MVISION
Domain verification process - support docs
Provisioning external users - support docs
How is this going to help if the org admin enforces SSO and their users are not aware of it? If you are enabling SSO on your users, we currently notify users of the change. We also strongly recommend you handle internal change management and messaging before enacting security policy changes.
Can org admins be automatically added as org admins to any product sites created? All the sites our users created were not approved and by accident. Some of them had left the company. It would be nice to immediately have access to the other sites so we can manage them without needing to reach out to someone. If a domain is claimed, products accessed by users on that domain will be included in your organization. Org admins automatically become product admins of all products contained within an organization. If you discover new product instances your users have created and want to manage them, claiming domains and adding them to your org will give you all admin permissions.
How do I remove shadow products for users who are no longer with the company and have deactivated accounts? If there is still an org admin for the shadow IT product instances, you can contact them through the Discovered Products interface and they can cancel the site’s subscription. If there are no remaining org admins for these product instances, you can contact Atlassian support or reactivate the removed user’s email account, log in as the user, and remove the shadow product instance(s) using their account.
What instructions do I give users to remove products they accidentally created? Is there a step-by-step guide? You can remove products that were accidentally created when you are made a site admin (or org admin) of the product, which the current org admin(s) of the product would be able to do. Once you have a site or org admin role, you can cancel the site's subscription.
Can you prevent managed users from setting up separate instances of products? Can this be done with group permissions? Today, the feature does not yet prevent managed users from setting up their own product instances separately. Group permissions will apply to current product instances for the Atlassian org where the product instances reside, but do not apply to other orgs' product instances (in the case of these user-created products). Prevention and proactive control is an area on our roadmap.
Can you add warnings to admins when a product is not managed and they are adding users with our domain address to indicate that user is subject to domain owner policies for Access? Also, when an org admin is from a domain that is owned, can you provide a message and approval from the domain owner? Yes, we are exploring how to surface this.
Is it possible to automatically de-provision external accounts? e.g., deactivate entirely or toggle “site-access” off entirely for our sites? Accounts can only be deactivated by orgs that manage the account. When you deactivate or delete an external account that is synced to Atlassian through your identity provider, the accounts will be removed from the IdP groups and hence will lose product access granted through this method. These accounts will retain “site access”. “Site access” can only be removed on a per user basis from the site’s user management -> users -> <user detail’s page>.
Do external users provisioned in Access take up an Access license? No. Only managed accounts count towards Access bill.
When will the external user security controls be released? Our team is working on it! It is listed on our public cloud roadmap and you can follow this ticket to track its progress.
Can external users automatically be deactivated or access removed if they didn’t log in for a specific time? Not automatically, but you can export a CSV of all your users and see their last login time then decide to deactivate or remove them.
When managing external users, can you manage external customers to a JSM portal? Yes, you can provision external users for the purpose of giving them access to a JSM portal. For example, you could provision users from an IdP into Atlassian Cloud and configure your JSM portal to be accessible to anyone in your org.
What if external users are already signed up for SSO with their company? How can we provision them through SCIM? If you have configured SCIM in your organization and your synced groups contain external users, we will sync these external user group memberships to Atlassian and these users will inherit the product access from these groups. This does not interact with SSO setting for the user accounts. These users will still login to the Atlassian accounts through their company’s SSO before accessing products in your organization.
I want to set a different policy for external user that is more strict than internal users. If I set a user group as “External” and assign all external users to that group, will the policy for that user group only? Authentication policies only apply to managed accounts. External accounts cannot be added to authentication policies. Our team is working on security controls for external users. It is listed on our public cloud roadmap and you can follow this ticket to track its progress.
I am an Atlassian partner and have my own account that I use with all of our cloud clients. Should I recommend they set up a new policy for external users like me? Authentication policies only apply to managed accounts. External accounts cannot be added to authentication policies. Our team is working on security controls for external users. It is listed on our public cloud roadmap and you can follow this ticket to track its progress.
For automatic de-provisioning for external accounts, can we disable site access in addition to product access? It seems like they are able to access things like service desks set to “anybody with an account.” If you are syncing those users from an external identity provider and have deactivated or deleted the user in that identity provider, the user will be deactivated in Atlassian Access. If the user is deactivated, they should no longer be able to log in to their account, including access to the support desk. If you remove product access from a user without deactivating their account, then yes, they can continue to access a service desk.
Can we clone/mirror access of external user to a new account (both external user)? You can do this by adding the new accounts to all the groups the old account.
Can I enforce MFA for users managed by other domains? There is currently no capability in Access to enforce authentication policies on users outside of your organization or on domains managed by other organizations. However, this is a feature that we are exploring - no promises on timing, but we know it’s something people need. Feel free to add feedback on this in jira.atlassian.com.
If using just Jira Cloud Premium and Confluence, what benefit is there using Atlassian Access? Cloud Premium plans pair really well with Atlassian Access! If you’re currently on or considering a Cloud Premium plan, it’s likely your organization is growing and you will need to find ways to scale and secure your company data. With Atlassian Access, you add an enhanced security layer by connecting an identity provider to enforce SAML single sign-on on your managed users. You can also leverage that identity provider to provision users through SCIM to help you scale user lifecycle management.
Can the security MFA be applied to service desk customers when logging in? MFA can only be enforced on your managed accounts. If your service desk’s customers are not your organization’s managed accounts, you cannot enforce MFA for them.
Does Access work with Trello? Yes! After claiming a domain, org admins can see a list of managed accounts and which ones have Trello product access. With an Atlassian Access subscription (assuming users are not put into a non-billable policy), you can enforce authentication policies on all managed users, including those with Trello access.
A lot of people have Trello accounts, whether they need it or not. How can an organization manage user count? We do not want to necessarily pay for those users who are only using Trello. This is an area that we are actively working on. If you would like to be a design partner and tell us more about your use case and how you are looking to control Trello user count and their workspaces, follow this ticket. For the time being, you can move Trello-only users into a non-billable Access policy, which would also remove them from policy enforcement with Access.
What is in the works when it comes to administering Trello under Atlassian admin? We are actively investigating Trello administration within admin.atlassian.com so that there is no need to deactivate the user’s Atlassian account in order to manage Trello product access. Follow this ticket if you’d like to track progress on this work. We are actively looking for admins to be our design partners on Trello administration!
When can we provision users on Bitbucket? Any plan to centralize user management for Bitbucket users and groups? Unfortunately, no timeline on this yet. We are investigating scope and are working on Trello ahead of Bitbucket at this time. We will be sure to communicate an update. Note that de-provisioning will work because when an account is deactivated in the identity provider, their global Atlassian account will also be deactivated and the user will lose access to all cloud products at once.
Is Atlassian Access support for Jira Align in the works? If this is something you want for your organization, vote for it in this ticket and follow for progress.
Does it make sense to use Atlassian Access if users and groups are provisioned and managed by my identity provider? Definitely! Atlassian Access enables you to connect your identity provider to Atlassian cloud products, such as Jira, Confluence, etc., so you can automate user provisioning and de-provisioning, enforce users to log in with SAML SSO, etc.
Talk more about how Atlassian Access auto de-provisions users. When you connect your identity provider to cloud products with Atlassian Access, you can automate user lifecycle management by leveraging the SCIM protocol. When a user joins, leaves, or moves between teams on the identity provider, it is automatically synced with their Atlassian cloud product permissions. You can learn more here.
With Atlassian Access, is it possible to synchronize groups from Azure to Jira cloud and keep the users belonging to these groups constantly synchronized? Yes, with Atlassian Access, setting up user provisioning via SCIM will provision group and users from Azure AD into any Jira instances contained within your organization. As long as you don’t disable your SCIM integration, users and groups will be kept synchronized with your identity provider. See our documentation for more information
I’d like to bring in additional Active Directory attributes, such as phone number, office location, manager, etc. Is this on the roadmap? This feature is currently not on our roadmap. At the moment, you can provision the following fields: display name, email address, organization, job title, time zone, department, and preferred language.
The directory available to admins to manage users has very limited features. Are there plans to have activity timestamps visible and sortable? It would also be helpful to be able to bulk deactivate (especially in the case with old Trello free accounts). The managed accounts page has last active timestamps within the individual account view, but it’s not sortable at this time. Bulk deactivation is available in the UI, but for larger bulk operations and custom sorting we recommend using the admin api.
Can we restrict specific products from ever being provisioned to a domain user? Currently, there is no way to prevent all product instances of a certain type from being created by or joined by a managed user in a domain, since products set up by a user would belong in a separate logical Atlassian organization from a centrally managed IT organization. However, improved controls over managed users are on the roadmap. If you would like to speak to our team about your specific needs, please follow this public ticket.
Can we add a specific site user under Access control? Yes, if you claim that user’s domain. If you claim a domain, you will capture all users on that domain as managed accounts. If you want to apply an Access security feature to specific users, you can add them to an individual authentication policy.
I understand I can have multiple sites under a single organization on Cloud Enterprise. Is there a difference in managing users across the various sites in Atlassian Access with multiple sites? Atlassian Access is available as part of your Cloud Enterprise subscription. So there will be no difference in how you manage users between the 2 subscriptions.
I assume my identity provider domain is the same as my mail domain when it comes to domain verification. I use several mail domains, including sub-domains - how can this be addressed during domain verification? As an Atlassian cloud organization, you can claim multiple domains and/or sub-domains you manage. You can learn more on our Product Guide and Support Documentation.
When an org admin claims a domain and user accounts are now managed by the organization, are users notified through the product starting now or do they receive an email? As of early May 2021, our team released an update that removed the email that gets sent to users. Since it is still a legal requirement for us to communicate that their account is now managed by their organization, we now show this message inside the product within their profile settings instead of an email.
I do not want to manage all users at the same time. How can I verify my domain without impacting all my users? Domain verification is a mandatory step of setting up Atlassian Access. With authentication policies, you can now select groups of users that you want to apply policies on and then place the rest of the users in a non-billable policy without Access functionality. However, you would still manage all the claimed users from the verified email domain.
If an existing account is updated to use an email address under a managed domain, is there any way to change the account back to the original email address (a non-managed domain-based email address)? We recently changed this because of issues customers were encountering in their configurations when they switched an account’s email domain. However, we’re also getting feedback that this change is causing new problems. Please add feedback here if this is something you need.
How do you surface user email as part of the payload from an API call? User email is included in the payload of a call to fetch organization users. See our API documentation.
Could we have an API call that searches for an existing user by email address, rather than having to parse the entire directory? You can search for a user by email address in the admin.atlassian.com managed accounts list. In the API, the only way to do that is fetch all users then match against the email field.
When will BYOK be supported? Our team is investigating BYOK encryption and how we bring that to life. This is listed in our public cloud roadmap for you to track progress.
Is there documentation on CASB and Azure MCAS? Here is the product guide on how Atlassian Access works with CASB integrations. We currently only support McAfee MVISION Cloud. If there is a CASB partner you’re keen on leveraging for Atlassian cloud products, we highly encourage you to communicate this to your partner so we can work on it together.
Are there any plans for additional user auditing and reporting features to help admins and security teams with governance and compliance? Yes, we plan on continuing to add additional audit log coverage over time. This is listed in our public cloud roadmap. In the next few quarters, expect to see additional Jira and Confluence user events focused on reading, creating, modifying, and deleting issues and pages to be added to the audit log.
What concerns are there with cloud migrations from server? We have a Migrations Center filled with resources to help address your concerns. We’ve also rounded up the top concerns from our server customers who are considering migrating here, with specific questions on Atlassian Access , user management, and how to migrate users for customers using Active Directory or an existing LDAP. If you want to familiarize yourself with the cloud migrations process, you can download our Intro to Migrations Ebook here.
Talk through the use case of a divestiture, where a group of users will be migrated to a new instance and org and need to update their email address from unmanaged to managed. How would that work? As an org admin, you can update the email address of the accounts that you manage. Only the user of an unmanaged account can update the email address of that account from managed to unmanaged. You read all about updating the email address of an Atlassian Account here.
Is there a suggested approach to deal with billable users who had previously registered Trello with a company email but never used the product? Yes, you can go into managed accounts to see which of your users are Trello only and have not been active in a long time and deactivate them. If you have many such users, you can automate the process by scripting against the cloud admin API and filtering for users with an old last active date, then making API calls to deactivate users in that set.
If I adopt Jira Service Management as a helpdesk solution, will I need to pay for Atlassian Access for all end users to log issues if I want them to log in using their Microsoft O365 company credentials? No, Atlassian Access is only billable for helpdesk agents, not customers. If those helpdesk customers do not have access to another billable Atlassian product (Jira, Trello, Confluence, etc.), enforcing SSO for those users is free through Atlassian Access.
Product Marketing, Enterprise Trust + Cloud Security
1 accepted answer