Dave Meyer Atlassian Team

Comments

  • Hi @Eric Vormelker , There are several ways users can be granted access to a site beyond direct invitations from an admin. I would review this document to see if any of these other features are enabled (in particular, the "Approved domains"…
  • Just for context, the primary reason that Atlassian does not support nested groups for user provisioning is that this feature is not supported by major cloud identity providers like Microsoft Azure AD and Okta, which account for the vast majority of our user provisioning API usage.…
  • Hi @nighterz , If you have an account that's managed by an organization, only an organization admin can change your email address. You will need to contact the admins of the org and have them change it on your behalf.
  • @Michael Corcoran sorry I think I accidentally deleted the last character in the URL. Here you go https://confluence.atlassian.com/cloud/transfer-products-to-another-organization-967318518.html
  • Hi @Michael Corcoran , An organization would have been automatically created when you created your cloud site, but if you started a trial of Atlassian Access directly from atlassian.com, it's possible that you created a second one. You can see all the organizations you're an administrator of by going directly to…
  • Hey @Nic Brough -Adaptavist- , The organization-level directory in admin.atlassian.com currently only includes managed accounts (accounts on domains you have claimed). You can still invite external users directly to individual Jira and Confluence sites. We're currently working on two areas that are relevant to your…
  • Hi @Erik H , Check out https://confluence.atlassian.com/cloud/give-users-admin-permissions-964957877.html Cheers, Dave
  • Hi @Jason Harwood , if your customer's users are already seeing the Okta login screen when they attempt to login to your company's Confluence, it means that that customer's IT team has set up Okta SSO for all users managed by that company, even if they are using their accounts to log into your company's Confluence…
  • Hi @Nitin Patel , No it doesn't require an Access subscription. However, it does require that you verify a domain to manage accounts for your organization. Regards, Dave
  • Hi @Navneet Gupta , can you share the error that Trello users are seeing when they try to log in?
  • Hi @Julia Foden , Your existing "local" Atlassian groups that you've already created remain as-is, and permissions and other references to them are never affected. The directory syncing with Azure AD pushes groups from Azure AD as "new" groups by default. If you push groups from Azure AD that have the same name as existing…
  • Hi @jason.chau , Is there a reason you need to add the "www." part of your domain in order to get it to verify? I think this is the root of the problem. We're typically looking for the root of the domain as it shows up in an email address. So if your users have email addresses like john@acme.com, then you would want to…
  • @Joy Knox if you've configured SSO, it should be strictly enforced on all your organization's managed accounts (users with email addresses on a domain you've claimed). If you're seeing behavior where this is not the case, I would recommend contacting Atlassian support, as this is a security risk and not intended behavior.
  • Hi @Jimmy , Do you have both the branch.contoso.com and branch.acme.com domains verified currently? That's the state I would try to target first. Have both domains verified, and then it's much easier to change users email address from one to the other. From an Atlassian functional benefit, there's no difference between…
  • Hi @Hannes , Check out this answer https://community.atlassian.com/t5/Atlassian-Access-questions/How-can-I-configuration-SAML-in-Keyclock-to-use-atlassian-cloud/qaq-p/880278 It looks like the Keycloak docs linked to in that answer are broken. Here's the correct…
  • Hey @Lucas Hornung , So it looks like what's happening here is the site with your Confluence, Jira Software, and Jira Service Desk is part of a separate organization than the one where you've verified your domain and set up user provisioning, but you are not an admin of that organization. I would recommend checking with…
  • Hi @Lucas Hornung , Yes, in order for your synced groups to be available in Jira and Confluence, you must have your site linked to your organization. What's probably happened here is that your Jira/Confluence site was automatically added to a different organization than the one where you've verified your domain and set up…
  • Hi @[deleted] , Yes, domain verification and users being managed accounts are prerequisites to enabling SSO, so you should configure SSO in that organization. You can follow the link above https://confluence.atlassian.com/cloud/transfer-products-to-another-organization-967318518.html to consolidate the other organization…
  • Hi @Sahar Yacout , It's important to understand that when you enable SSO, it is applied across all Atlassian cloud products and tenants, regardless of whether they are "part" of your organization or not. It's not currently possible to have Bitbucket as "part" of your organization, but when you configure SSO for your org,…
  • @Sahar Yacout yes, however it may still be simpler to set up G Suite on the existing organization. If you configure and enable G Suite, all your managed accounts will remain (assuming the domain you verified is also associated with your company's G Suite organization). That said, SSO for Bitbucket should already be…
  • Hi @cmbollareddy , Is your question about setting up SSO for Atlassian's self-hosted products using Crowd? If so, I recommend asking your question under the Crowd category. https://community.atlassian.com/t5/Crowd/ct-p/crowd
  • Hi @Sahar Yacout , Currently Organizations and domain verification only apply to existing Atlassian cloud products and users, so any configuration you have for your Bitbucket Server instance would not be affected. (Although features to support this scenario are on our roadmap!) If you already have your domain verified and…
  • @Nicholas Molina your understanding is correct. As mentioned you can mitigate this risk through session duration controls (or using device management software, but this isn't my area of expertise). But IP allowlisting via the Premium plan is the easiest way to comprehensively assure there is no non-VPN access.
  • Hi @Tim Lloyd , Unfortunately we currently don't provide any capabilities for enforcing security policies on unmanaged users (especially since those users could be on domains managed by another organization enforcing their own security policies). We're aware of the issue and we do plan to introduce some capabilities here…
  • Hi @Norman Bailey-Powers , AD FS only supports single sign-on, not group syncing. In order to sync groups from Active Directory to Atlassian cloud, we support a number of cloud identity providers like Azure AD and Okta that can source users and groups from an on-premises Active Directory and sync them to Atlassian's cloud.…
  • Hi @Rakesh Kundula , the G Suite integration does not sync groups themselves from G Suite. You can use G Suite groups to define which users to sync, but the groups themselves are not copied. So you don't need to worry about merging groups. https://confluence.atlassian.com/cloud/connect-to-g-suite-873918510.html
  • @RMA yes, we recommend this as a precaution. Usually not because we are worried about the SAML connection failing, but we do see people make mistakes during the initial SAML configuration setup and end up locked out. So it's a good idea no matter what :) 
  • Hi @RMA , A couple points I would make in response to your question: * Once a user has logged in, they will have a session cookie, so in the case of an SSO outage most users would be unaffected. * We consider login and authentication (including SSO) our most critical service after our infrastructure itself, so we strive…
  • Hi @Robert Piscitello, Claiming accounts has no impact on the various instances that the claimed accounts might have access to. When you do a domain claim, the user's accounts become managed under your organization, but it's intentionally independent of the products that each user has access to (the users might be using a…
  • Hi @William B Dobbs , Check out the suggestions in this thread for contact support using a separate account. https://community.atlassian.com/t5/Atlassian-Access-questions/After-trying-to-get-SAML-single-sign-on-to-work-with-Azure-AD-I/qaq-p/1342461