Dave Meyer Atlassian Team

Hi @Gabriel Viger , No, each subdomain must be verified and have accounts claimed separately. So if you verify acme.com but a user account's email address is john@us.acme.com, SSO will not be enforced until you claim us.acme.com. That said, you can claim as many domains as you need under the same organization. A simple…

Hi @Darren Groom, While users may have had their access removed from repos that you control in Bitbucket, a user's account is still considered active in Bitbucket, as their may have had access to other repositories as well. If these users have left your company, the simplest thing to do is ensure that their account is…

Hi @ADyPo , If you can detect when a user is no longer active in Keycloak, you can set up a script to call the account deactivation API for that user. You would use this API to look up email and accountId mappings for users in an…

Hi @Dan Brewerton , We're actively working on this project; however the ability to set up multiple SSO providers is only slated for the final milestone. We're hoping to have this done in the first half of 2021.

Hi @I Broke It , Just create a support request (you can use the account you used to post this question) and our support team can help you out.

Hi @Sara Creenan _M_T_ , No, if you deactivate a user's Atlassian account it is not billable for our products or Atlassian Access. https://confluence.atlassian.com/cloud/manage-your-bill-for-atlassian-access-948237309.html

This error is coming from Ness' Microsoft SSO, so it would need to be resolved by one of Ness' IT administrators that manages which applications employees have access to.

Hi @Pankaj Thapliyal , This is because someone at Ness has enabled SSO through Microsoft for all users with @ness.com email addresses on their Atlassian account. When SSO is enabled, you are no longer able to log in with your standard credentials, you have to log in through Microsoft SSO.

Hi @Tom King , There's no downtime when you enable SAML SSO. As soon as it's enabled, new logins will automatically start being delegated to your SSO provider. Two things we recommend before enabling SSO: 1. Ensure you have an account that is an administrator for your Atlassian organization that is not on one of the…

Hi @Pankaj Thapliyal , It sounds like when you log in with your @ness.com Atlassian account, you are being redirected to your company's SSO login, which is blocking you from accessing Atlassian Cloud products. Typically this would be maintained by your company's IT department if the error is coming from the SSO login…

Hi @Harish Vaddepelli , Based on your reference to the version number, I'm assuming you're using Jira Server 8.2.3. In this case, I would refer to the Jira Server audit log documentation. https://confluence.atlassian.com/adminjiraserver/auditing-in-jira-938847740.html

Hi @Cronje van Heerden , There's no impact to any of these. Technically, there's no migration involved. After you verify your domain, the users existing Atlassian accounts will become "managed" by your organization and you will be able to set up SSO for those accounts, but that simply delegates authentication for the…

Hi @Joe Doherty , Yes, you can achieve this. In fact, it's the standard behavior. If you verify a domain and configure SSO with Okta, it will apply to all users with accounts on your verified domains. Non-domain users that have access to your cloud products will not be affected in any way – they will still have access but…

@Phalgun Maddali , if the user's profile says that their account is managed, but when you go to your Managed accounts screen it says that you have no managed accounts and prompts you to verify a domain, the likely explanation is that the organization that you administering is not the one that has verified that user's…

Hi @Phalgun Maddali , in order to change a user's email address, you need to be an administrator of the organization that has verified that domain (and therefore manages the account). Based on the fact that you've referenced the verified the domain, I am assuming that you are. Based on your description, it looks like you…

That's correct. It's mentioned here but a little bit buried https://confluence.atlassian.com/cloud/verify-a-domain-for-your-organization-873871234.html We maintain the ongoing check of your text record as a security measure against cases where an attacker may have temporarily gained illicit control of a domain.

Hi @Elijah Lapson , check out this answer more details: https://community.atlassian.com/t5/Atlassian-Cloud-Migration/Re-Implications-of-connecting-GSuite-domain-to-Atlassian/qaq-p/1315007/comment-id/106#M106 Yes, you do need to claim the accounts before SSO can be enforced, and unfortunately this does trigger another email…

Hi @[deleted] since per-repo 2FA is a Bitbucket Premium feature, I would recommend asking this question under that forum. Cheers, Dave

@Desiree Olivito It's not possible to claim a subset of users, we currently require a single organization to claim all users on a domain. Once you've claimed a domain and subscribed to Atlassian Access, you can configure SAML SSO for all users on the domain via Okta. When you enable SSO, it's enforced on users' Atlassian…

Hey @George Kuznetsov , If you are confident that the user logs in through SSO on the web, but when they use the same email address to log in through the mobile app, they are able to log in without using SSO, then I would recommend contacting our support team. This is not expected behavior.

Hi @Pineda Castaneda, David Ernesto , You can find information about internal and external audits that Atlassian conducts at https://www.atlassian.com/trust Atlassian Access is a subscription that is deeply integrated into the identity system that is used across all our products and services, so it is implicitly covered in…

Hi @Manali_Bera , Domain verification is intended to allow you to manage accounts of the users within your company. If you have signed up for a free trial of Atlassian Cloud, you do need need to verify the URL of your Atlassian Cloud instance. Domain verification is for your company's domain. So if you used your…

Hi @Joost , Since you don't have an Atlassian Access subscription right now, you don't need to worry that your bill will go up, so unverifying your domain is probably not necessary. (It is possible to do this, however. Just go to the Domains page.) To see exactly how many users you should expect to be billed for if you…

Hey @Karim , Yes it's a little bit confusing starting from admin.atlassian.com. The organization name is actually clickable and will take you directly to the organization settings, but we have seen from a number of customers that this isn't intuitive. We're aware of the issue and are looking at new designs for this page in…

Hi @Lex_Heredia , I would recommend contacting Atlassian Support directly to help resolve this situation, they can help diagnose what has gone wrong and disable the G Suite sync temporarily if necessary. https://support.atlassian.com/contact/

Hi @asanti82 , You should be able to set a password by clicking the "Trouble logging in?" link and going through the Forgot Password process.

Hi @George Kuznetsov , We don't currently log out existing users from their mobile devices when SSO is enabled. If you have SSO enabled, then if you log out on your mobile device and log back in, it should take you through the SSO login flow. Cheers, Dave 

Hi @Stefan Berkenhoff , Changing the organization name itself should have no user-facing effects. The only place it should be visible is to you within admin.atlassian.com. Unfortunately, that also means that changing the organization name won't trigger a change in your instance name. When you create your instance, the…

Hi @Pramod Kumar Mandadapu , When you configure SSO, it applies to all instances of all Atlassian products, regardless of whether the sites have been linked to your organization. The linking of sites to your org drives other features like the audit log and admin insights, and helps you collect everything in one place. But…

@Lucas Duggins not at this time. We've designed Atlassian Access as a wall-to-wall solution to provide visibility and security for the entire company. If you're planning to configure SAML SSO, this is usually necessary anyway because company's SSO providers are centrally managed. Many customers have found success by…