Dave Meyer Atlassian Team

You should be able to use the account that you're currently using for Atlassian Community to create a request, we should be able to get the request associated with your existing account.

Hi @Tom Horton , Please contact Atlassian support directly, we can help get SSO disabled temporarily while we help you diagnose what went wrong. https://support.atlassian.com/contact/#/

@Rohini Kumar we don't provide a public SEN for individual apps, as far as I know. You should see one SEN for your entire site (foo.atlassian.net) on my.atlassian.com

@Rohini Kumar you can contact our purchasing team for a quote https://www.atlassian.com/company/contact/purchasing-licensing

We're currently planning to implement visibility into which users on your site have enabled 2FA relatively soon (ACCESS-797). We do have a plan for supporting actual enforcement of mandatory 2FA on external accounts; however this is going to take quite a bit longer. Follow ACCESS-102 for that one. Thanks! Dave 

Hi @[deleted] , No, Atlassian Access is an additional subscription that provides additional features on top of what you can do by verifying your domain and claiming accounts. Once you've claimed the accounts they become "managed accounts". You can do the following (apologies if this list isn't completely comprehensive)…

Hi @Rohini Kumar , If you have started a trial for Atlassian Access, the SEN number should be visible to you in my.atlassian.com. The reason we don't provide a quote for an annual subscription until after you've verified a domain is that your Access billable user count is based on the number of users on your domain. So…

Hi @Rohini Kumar , I recommend contacting Atlassian support and we can help diagnose issues with domain verification. It's not necessary to verify a domain to start an Atlassian Access trial itself (you can do it from https://admin.atlassian.com/atlassian-access if you haven't already) but most features require a domain to…

Hi @Edwin Lloyd-Jones If I enable SAML will it change it for all users or just the users I assign to the Azure AD Enterprise Application? Essentially enabling a split login some users on SAML some using Atlassian username and password. When SAML is enabled it is enforced on all managed accounts on your domain, so all user…

Hi @Chalhoub_Dev , yes unfortunately at this time you need to do the claim accounts step before user provisioning will work. The purpose of separating the "verify" and "claim" accounts step is to allow you to notify users that they will receive an email from Atlassian that their account is now managed by your organization…

@Chalhoub_Dev no, the limit only applies to licensed users, so this shouldn't be a problem.

Hi @Chalhoub_Dev , There are no limits on the number of users that you can have covered by an Atlassian Access subscription itself (although I think the pricing calculator on the website tops at 40,000, we have tested up to 100,000). So that means you would have no problems setting up Atlassian Access for SSO for 14,000…

Hi @Sravani Kirla , No, you need to claim the accounts before you can enable SAML SSO. At a high level, the process is: 1. Verify domain 2. Claim accounts 3. All claimed accounts become "managed" by your organization 4. Enable SSO, which is applied to all your managed accounts. The purpose of separating out the domain…

Hi @ramani_chandran , It's important to understand that when you verify your domain and configure SSO, this applies across all tenants. The domain verification is not specific to any one tenant. The reason we've designed our system this way is to help you get full visibility into Atlassian usage in your organization. If…

Hi @Mohamed Lrhazi, When you connect your G Suite account, it verifies that you own the domain associated with your G Suite account (see https://confluence.atlassian.com/cloud/verify-a-domain-for-your-organization-873871234.html for more info). When this happens, all existing Atlassian accounts that are tied to an email…

That's correct @staceyking , however I would just note that in most cases "deactivating" is sufficient without doing a permanent deletion on each account (which can take some time). You're not billed for deactivated accounts. https://confluence.atlassian.com/cloud/deactivate-a-managed-account-961259517.html

Hey @ramani_chandran , It's only based on the domain, not based on the tenant. So if you have only verified ex.abc.com.au and configured SSO, it will apply to all users with an @ex.abc.com.au email address, regardless of whether they are accessing jiratest.atlassian.net, jiraprod.atlassian.net, or even this site (Atlassian…

Yes just to confirm, if you have users that have access to your Jira or Confluence site but are external (i.e. not on one of your verified domains), nothing will change for them. They'll still have access to your site as usual and they will still log in as they did before. 

Hi @ramani_chandran , No that's not correct. Regardless of whether you have one or more products linked to your organization, your SSO configuration applies to all Atlassian cloud tenants and services because it's tied to users' Atlassian account, based on the domain you have verified. The domains you verify are not scoped…

Hi @bb777 , Claiming accounts will make them "managed" by your organization: https://confluence.atlassian.com/cloud/managed-accounts-873871203.html Besides the email notification that goes out after you claim the account to let them know that their account is now managed (as covered in the doc you linked) there are no…

Hi @ramani_chandran , See my answer here (the same advice applies regardless of whether you're using Azure AD or ADFS) https://community.atlassian.com/t5/Atlassian-Access-questions/Re-SAML-Configuration/qaq-p/1178658/comment-id/757#M757

That's correct. We do plan to work on this feature request later this year. In the meantime the best course of action is exactly what you described @Larry Katz.

Hey @Justin Wienckowski , It sounds like you may not be an administrator for the organization that your site is a part of. It requires a separate "org administrator" permission that sits above both the "site-admins" group (which makes you an administrator of your site) and the "administrators" group (which is used for…

Hi @Justin Wienckowski , that's strange. If you click "Get started" on https://www.atlassian.com/software/access it should take you to a screen where you can choose from your existing organization(s). We'll look into it. In any case, if you can access your existing organization from admin.atlassian.com, you can follow the…

Hi @[deleted] , Unfortunately we don't support the ability to split users on the same domain across different SAML configurations. However this is on our roadmap to address in the near future: https://jira.atlassian.com/browse/ACCESS-572 If each school's users are on a separate email domain, you could create an…

Hi @Balaji Shinde , did you follow the instructions here to generate your API token? https://confluence.atlassian.com/cloud/create-an-admin-api-key-969537932.html It's important to understand that the organization API key is not the same as a personal API key.

Hi @Edwin Kyalangalilwa I think @Balaji Shinde has the correct API, this is indeed a new API that we provide to organization administrators for deactivating accounts across all Atlassian products. Deactivating accounts for users that have left the company is the type of scenario it's designed for.

Hey @raman sharma , If I understand you correctly, you're using AWS's managed Active Directory service, which effectively allows you to run an on-premises AD environment in AWS infrastructure. In this case, it's effectively equivalent to running Active Directory on local hardware. Active Directory doesn't support the…

Hi @Paul De Graaff , Yes, we know that this is one of the biggest issues facing customers looking to set up directory sync with Okta. It's at the top of our roadmap and we are planning to work on it in the next 12 months. We will share updates on ACCESS-608. Regards, Dave Meyer Group Product Manager

Hi @Ioan Damian If a user is removed from all groups that are assigned to the Atlassian application in Azure AD, that should trigger Azure AD to deactivate the user's Atlassian account on the Atlassian side automatically. I have an active user in scope of the sync. If I deactivate that user in Atlassian Access (the user is…