This is not a real solution, we need to be able to BLOCK, not REACT after the fact.

Kicking off another delete process for 2 more sites sites that were unintentionally created by users trying to login, after deleting previous 3 sites unintentionally created by users trying to login. This is for a mid-size org of 200-400 employees in a span of 4 months. 

Strangely enough, never ran into this issue until that recent timeframe. Now it's every other week or two. 

Atlassian still out here promoting shadow IT & leveraging the diminishing availability of administrators to manage the security/billing vulnerabilities they've created.

Agreed 1b46c259bc3c BUT RE: "a +750 vote for this issue can not be taken lightly" absolutely agreed, BUT please note that actually the number of votes to improve this area is MUCH HIGHER, thanks 495ef2a83e74 for collecting up useful links, I'd consider the accurate number of votes for work on this issue to be a sum of the non-duplicates of the 750 from this CLOUD-10325 , the 1611 in https://jira.atlassian.com/browse/ACCESS-1468 and those who've voted on all of the issues linked to it, so likely to be at least 2000 people! 

PS 8f4050917dd7 LOL at your Simpsons meme. 

the "solution" is not a solution as it's reactive for most of the customers (it's only proactive for Enterprise customers). Why is it that difficult to enable that feature on all subscription-levels ? In our company we already have +65 user-created confluence/Jira instances out of our admin-control. Users are not aware of what they doing as it's a "feature" in the product. Users afterwards want to migrate their custom-created instance back to our global company instance, which takes looooots of unwanted/unscheduled/budgeted IT support/resources. So please take your customers seriously regarding this matter : a +750 vote for this issue can not be taken lightly and it's a real burden for customers to have extra time & money spend to manage shadow-IT imposed by our SaaS solution vendor: SaaS should be a service and not a shadow-IT generating service. So - with sugar on top - RECONSIDER a proper solution !

I find it somewhat ironic that even the product they called "Guard" does not actually "guard" you against this....just tell you it happened, and let you show up after the fact. Users just love it when you show up like the "uncool" parents at the high school party to shut things down.

As 416840511601 said, this is disappointing and unacceptable.

Preventing users from creating unsanctioned sites is a core security and data governance + compliance feature.

Atlassian Guard Standard is already overpriced (around USD 10.000 a year for 300 ppl product tier), and the features in it are close to none though Atlassian's attitude is more like "be thankful they are even there in the first place". To add more shame to the matter, the feature is already developed!

Atlassian Guard Standard as it is right now should be included for free, and the Enterprise tier should cost half of what they are charging now.

Boooo Atlassian!

This is a disappointing and unacceptable response and is not customer-focused.  It would be one thing if this functionality didn't exist at all, but having it available and choosing to paywall it behind Enterprise goes away from a core Atlassian value: "Dont #@!% the customer"

Hi,

This week I got contacted by our "customer success manager" of Atlassian. I explained that this is the most important problem that we currently have (along with users starting trials for addons) and that any further discussion about other topics makes no sense.

We have to take every opportunity to bring this to the attention of Atlassian:

• Keep posting comments on the different articles and feature request, even the ones that have been closed
• Keep creating a support ticket for every site that has been created by a user
• Keep filling in customer surveys and express your disagreement with the practices of Atlassian
• Keep warning Atlassian that this cannot continue: our organization will stop tolerating this in the near future
• Keep asking Atlassian about compliance of their products with recent and upcoming regulations (in the EU: NIS2, CRA...)

Thanks,

Stefaan

PS: some relevant links:

• https://jira.atlassian.com/browse/CLOUD-10325
• https://jira.atlassian.com/browse/CLOUD-12089
• https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
• https://community.atlassian.com/t5/Enterprise-articles/An-update-on-product-requests-bringing-shadow-IT-controls-to/ba-p/2840760
• https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
• https://community.atlassian.com/t5/Articles/Proposal-to-prevent-Accidental-Site-Creations-accidentalit/ba-p/2867193#M558

gjones@atlassian.com, as you can see from the comments that are still active, the issue is not over for most people. I would therefore like to ask you to reopen the issue and address it again internally.

I agree shadow IT is a nightmare I am constantly blocking sites and url that allow users to try or spin up instances. I think this is my biggest issue along with users able to request apps (I want to be able to disable that section for users)

Have also confirmed they now provide a concrete date when it can be deleted (as part of the support ticket delete process). And there seems to be redirect in the works to serve up a page for existing managed users that allows to choose existing sites.

But as of last week, I was still initially presented the option to create a new site all too easily when navigating to https://www.atlassian.com/software/jira 

Upon disregarding the new site request & closing the tab & then navigating back to URL in a new tab, I was presented the page where you can select the existing site. Will see where this goes....!

If you aren't already creating a support ticket for every deleted site, you should - supposedly they can expedite the process (although hm, it still takes 15 days). 

At the very least, I get a specific date for when the site is scheduled for deletion, so I have a reminder for when I can delete the associated organization.

495ef2a83e74 taking part in the survey is a great idea; however, for me, these links expired. I would like to propose a more effective approach. Let's create a support ticket for every newly created product outside our organization to permanently remove it. It will impact operational metrics, so they will have to handle this topic sooner or later.

"How can Atlassian better support your organization?"

That is the title of an email from Atlassian, which you have probably also received, containing an invitation to "Share your thoughts in a short 5-7 minute survey".

I recommend everyone to participate and share your thoughts about Atlassian pushing shadow IT towards the managed users of customers with Jira Premium and Confluence Premium.

During the survey, there are 3 text boxes where you can type free text. Keep Atlassian informed about your thoughts!

So I have a proposal to fix this that has nothing to do with Atlassian Guard, because to gjones@atlassian.com 's credit, what the vast majority of us are experiencing is not what Atlassian Guard Enterprise was designed prevent.

What Atlassian needs to fix is the "landing page" experience for existing users. I have some suggestions here.

c05c14d41e50 while I appreciate you wanting to "stick it to the man", one of the reasons I go to the work of shutting down accidentally created sites is because depending on configuration those sites WILL SHOW UP for other users.

I'm afraid that one of these accidental sites might start being used for REAL WORK or worse still REAL WORK with multiple users.

And then I might end up in a situation where I have to migrate data from this accidental site to our real site? Ugh, no thanks.

Hi,

c05c14d41e50 wrote "So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent."

You are completely right, we must keep on bringing this to the attention of Atlassian, using all possible means, and make them spend their time on the cleanup work, too! We must also keep posting and creating new bug reports for this issue.

In the support tickets, always repeat the same information (I even made a "template" ticket for site removal requests!):

• The site has been created entirely by accident by one of your "managed" users
• You don't agree with the shadow IT activities of Atlassian towards the managed users of your "premium" subscriptions
• This is a huge security issue which must be resolved by Atlassian if they want to show any respect for their customers
• If this continues, you will have no other option than advising AGAINST the further use of any Atlassian tools

Also make references to some relevant articles:

• https://jira.atlassian.com/browse/CLOUD-10325
• https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895
• https://community.atlassian.com/t5/Questions/Why-is-Atlassian-promoting-Shadow-IT-Or-Accidental-IT/qaq-p/2731538
• https://jira.atlassian.com/browse/CLOUD-12089

Ask for the immediate and permanent deletion of the site.
And finally, also ask to keep the ticket open until the site has been completely removed (because they like to close tickets before the site has been deleted and when deletion fails you have to start all over again!).

That feature is a nightmare for our small team. Cause the new users are flooded with new features and announcements from Atlassian and click on every button they get. And at the end a Jira Instance is created which i could enter as an Admin and cleanup the mess but thats very unfortunate for multiple reasons

a) i need to wait 2 weeks to delete the product

b) sometimes it stucks completely

c) i need to be very carfull to not delete a real instance

d) its always an amount of hours i need to put into that until i find the right buttons and start the whole procedure

So as a conclusion for me, i will open a support ticket every time a user is accidentially creating an site and let the Atlassian support clean up the mess until i get some opportunity to prevent users from creating Jira instances without any admin consent.

872274a04a84 best you can do is open a support ticket to request to delete the sites and organizations. I had a list of 30+ (and growing) organizations that started to annoy me.

I agree with the rest; if you're able to verify the domain and manage the accounts, you should be able to prevent them from creating sites. Hiding this option behind an Enterprise paywall is not acceptable. I also have customers with a smaller user tier complaning about this, for which Enterprise is not fitted at all.

I have the same problem but not at the same level as some people here.

The incorrectly created Confluence product has finally been cancelled. I tried to delete the organisation today but I couldn't. After some reading (at [Delete your organization | Atlassian Support|https://support.atlassian.com/organization-administration/docs/delete-your-organization/]) it looks like I now have to wait an additional 60 days before I can delete the organisation. Surely that can't be correct?

Hi,

I didn't even know that the situation was different (and even worse) for the customers who don't have Atlassian Guard.

Let's have a look at the products and the product names:

• Premium products: the "premium" versions of Jira and Confluence are not cheap. Many companies, like ours, are spending a small fortune on these products! All customers for the so-called “premium” products are expecting those products to be mature and secure, and well suited for professional use.
• Managed users: the users are "managed" but what does this mean? In my opinion, the company must have control over those users and what they can do or can’t do on the platform. But not for Atlassian! For them, a "managed" user means a user that belongs to a claimed domain, that's all! On the contrary, Atlassian guides our “managed” users away from the “premium” managed environment, and allows (and encourages!) them to subscribe for new products outside of the managed environment! This shadow IT is a major security hazard!
• Guard: according to the name, this product should guard their customers from a number of things. The first one, and the most obvious one in my opinion, is guarding the company from the above mentioned security hazard that Atlassian is creating for their "premium" customers, who have "managed" users!

Although obvious for every customer of Atlassian, it seems none of this makes sense for the so-called product managers of Atlassian! Stopping these shadow IT practices and guiding our managed users towards to our managed environment, is basic stuff for any product that deserves the naming premium/managed/guard, and should never be hidden behind an enterprise paywall.

Atlassian, if you really want to be what you claim to be (a provider of secure and good quality platforms and services), then just act like that by providing value for money! Now you are providing a lot of garbage for “premium” money (a continuous flood of security hazards), and you are asking “enterprise” money for stopping to provide the same garbage? This is not what I understand under “provide value for money”.

Stefaan

At least Guard admins can see the products being created by their managed users, and make themselves org admin and delete. Admins without Guard only get an email telling them that one of their users created a product somewhere with a link to buy Guard.

Its not automatic product discovery we need, its automatic product restriction, and this should be opt-in, not opt-out.

Agree with all comments. The resolution was molded to the easiest option rather than the expected resolution, which i$ already available, a$ long a$ you are willing to pay...

Gah, thought I made it to 13 days, but nope.

And this was entirely predictable - It's been two days since the expedited deletion request finally went through for roku-team.atlassian.net, which is the site name that Atlassian's broken login/signup workflow suggests for users. It certainly would "look" right to a user just trying to log into OUR EXISTING site, roku.atlassian.net. But nope. Atlassian doesn't check if that's what the LOGGED IN user was trying to get to. Instead it gives them a big blue button to Get Started, and that's what this user did. It would be great if somebody at Atlassian fixed the problem.

The original description has been removed during edits by Atlassian:

"Prevent users under a verified domain for being able to sign up for a new Cloud instance.
Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance.
If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator."

The current description does not reflect IN ANY WAY the orginal request.

Marking the request as "Fixed" is ridiculous.

Atlassian, how about telling the truth: you are using this flood of accidentally created sites as an extortion scheme to force all customers towards the "enterprise" version.

Don't forget this is a huge SECURITY HAZZARD! "Managed" users should never be able to create (and start using!) a site outside of the organization! This makes your "premium" products INHERENTLY INSECURE.

Securing your product, by blocking managed users from creating new sites, IS NOT A FEATURE. Hiding this behind the "enterprise" paywall is plain extortion: "premium" customers who don't need "enterprise" features, have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian? Paying for not getting unwanted stuff is extortion.

Hey Atlassian! Are you listening? gjones@atlassian.com your most recent update is wildly disingenuous to suggest you've been 'closely monitoring' this thread. Sorry that this might sound personal but hey - you're literally the one making these nonsense updates. 

"Automatic product discovery is not limited to the enterprise plan and any customer of any size can purchase as subscription for Atlassian Guard Standard to gain access to this feature."

This is NOT the issue. It never was. The request is to STOP managed users creating sites AT ALL. I cannot - even stretching the benefit of the doubt - see how you and your colleagues cannot see this, since it has been repeated ad nauseam throughout the many tens of comments. As a watcher of this ticket my inbox is currently blowing up with people saying the same thing, so clearly you're aware of what people are saying.

You haven't fixed it. Stop claiming that you have. Be the cloud provider you claim to be, re-open the ticket due to the clear and obvious customer demand, and just fix the issue. It's clearly not that hard since the prompt to control requests is ALREADY available in the admin section.

34 (currently) in an instance of 2000 users....

e2c1e07fea9d : Oh, you beat us there. we have about the same user tier but haven't migrated Jira to the Cloud, yet. But I bet we can beat you there in a few months. 

Best I had was 5 products, too. 4 of which were created by the same person who was just trying to get into out Confluence instance and had no intend of creating new sites.

In my eyes this ticket should not be the goal. The goal should be that users don't even stumble into the option to create new sites and orgs. 

OH man, I'm sorry e2c1e07fea9d!

So, I don't know if somebody advised me to do this, or if I just got impatient, but I have been filing tickets requesting "Expedited Deletion of Accidentally created Sites" (I'm advocating that we add #accidentalit to help them track these).

There's a required back-and-forth where I have to "CONFIRM" that I REALLY want to delete the sites I put right there in the request and also CONFIRM that I'm not trying to rename any of the sites. (!?)

But after that, support will reach out to the "site deletion team" who will then give you a scheduled date for deletion. The shortest delete date I've gotten has been 14 days after filing a request. Not great, but better than a month!

I track all of this nonsense on an Excel sheet. I was able to delete five orgs today!

8f4050917dd7 within 45 days... They are all marked for deletion, but it takes over a month before they actually drop off.

My user base is 4,000 Atlassian Guard Licenses; with a similar number of Jira and Confluence licenses.. 1,000 JSM and 300 JPD.

12 days sounds nice! I dread those almost daily emails "1 product created outside" hahaha

A quick search of my emails show that he most I've received was "5 products created outside" on 8/27/2024 – but multiple with 4 and 3; countless with 2 and 1. 

Wow e2c1e07fea9d - 29 sites! How recently were those created? What's the size of your userbase?

Not to brag, but personally I'm on a bit of a roll:
 

(Ooof, of course that may change any day. I'm posting daily snapshots here.)

Since this month, many companies in the EU must comply with the NIS2 directive, which has the goal to enhance security practices in EU companies (and their supply chain):

• https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

From next year onwards, digital solutions sold in the EU must comply with the Cyber Resilience Act, which has the goal to enhance security of digital products and solutions provided to companies and consumers:

• https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act

I wonder about the answer from Atlassian for both legislations on this specific subject.

Security shouldn't be a premium feature, prevention beats cleaning up every time. I appreciate Griffin and the team keeping an eye on this ticket but it's very clear that a business decision is forcing us to play janitor instead of actually securing our data.

Attention Atlassian stuff - Sarcasm!
Atlassian Product Management ist getting better and better. Changing request definition to deliver something nobody asked for, but internal statistics are looking good - great job!
Ignoring customer needs and responses is also a proper way to get them to resign and don't create requests anymore as it's useless. So the the number of requests will get reduced - so again, internal statistics are good - great job again!
Just keep going, that is certainly the best way to be successful in the long term - congratulations! I hope you'll receive a bonus payment for this great strategy!

I just wanted to echo a sentiment of Stefaan's. 
Whenever I have reached out to the support team, they have been so helpful and understanding. No matter the issue they have strived to do their absolute best to resolve the issue.

In no way do I believe that the response from this ticket is in line with how the support staff operate. It seems to be the higher ups making decisions at Atlassian that have no clue.

I absolutely adore the Atlassian support staff. Best support of any vendor we use, by far.

Shame on the higher ups to make the whole company image seem so much worse.

Absolutely unacceptable that this continues to be the response. That was the most eloquent "we don't care at all what you want" response that I've ever read. My company spends a small fortune every year paying for Atlassian, only to be ignored over and over on important issues such as this one. You have received so many upset responses about this issue, yet you simply close it, and then double down on closing it? Wow. 

The way things are worded in the October 30th response do not correspond to reality, nor do they correspond to what has been requested by the customers.

This kind of response only shows that (some people at) Atlassian don't give a damn about customer satifaction by offering a good product.

They just want to hide a basic security feature behind a paywall. It is plain extortion: "premium" customers who don't need "enterprise" functions, would have to PAY EXTRA FOR NOT GETTING UNNEEDED, UNWANTED AND INSECURE PRODUCTS from Atlassian.

This guy probably doesn't care, but I feel truly sorry for the helpdesk staff, who are well aware of the magnitude of the problem, and who have to lie to customers on a daily basis. This is a response I received in a ticket after my complaint about the never ending flood of sites created by our MANAGED users:

“Thank you for taking the time to share your concerns with us. I genuinely apologize for any frustration this situation has caused, and I completely understand your standpoint on the importance of robust data protection and security measures, especially given the context of new regulations in the European Union.

Your feedback is incredibly valuable, and I want to assure you that it has been relayed to our internal development teams. While the support team is primarily tasked with facilitating communication and passing on insights from our customers, please know that we are committed to advocating for changes that align with our customers' security needs. I understand the critical nature of meeting industry standards and how essential it is for you to ensure that your organization is protected.

I also realize how disconcerting it must be to feel that a basic security feature is only available under specific plans. I want to emphasize that we, as support teams, are continuously in discussions with our product teams to address these issues and work towards a more secure and compliant experience for all our users based on your feedback and comments.

We are committed to taking your feedback seriously, and it plays a significant role in driving improvements. Thank you for your patience and understanding as we work to address these important issues.”

Absolutely agree with Mike and Kirsta.

gjones@atlassian.com or someone from Atlassian, sorry for my ignorance but do you mind giving me an example on how the IT department of any company, regardless of their subscription tier, can benefit from the existence of a shadow IT?

I completely agree with Krista... gjones@atlassian.com this is a ridiculous response. Yes, you gave us discovery... BUT

1. We are not notified for days... that's days of a potential exposure of data.
2. it's admin overhead and work for no reason other you creating a paywall. Very few people in a large organization have these types of permission. 

What don't you understand? 

I have 29 discovered instances right now... All pending deletion... in what realistic world do you think that's ok? 

Griffin, in response to your update on 30th of October
What a ridiculous response. We never asked for the ability to take over sites; we asked for them to be prevented from being created in the first place!!
Stop moving the goalposts and actually listen to what is being requested.
This is wasting your customer's valuable time. I wonder how many customers have moved to other products due to this? It's absurd to put cyber security behind an enterprise paywall FOR EVERY ATLASSIAN APPLICATION!!
It's not enough that we have an enterprise subscription to JSM and Guard. We can only prevent our users signing up for JSM! Should we really go out and purchase an enterprise subscription for all the products we DON'T USE just to prevent our users signing up for them by mistake??

This " release ‘add admin’ functionality, making the feature more actionable." is not a viable solution. Your reason is extra money from the Enterprise or Atlassian Guard subscription. It's your businesses, you can make that call. But could you at least be honest?

This feels much more like a money move that a "small-to-medium customers don't need this" thing. 

This is in regards to the new October 30th update that just dropped.

"In the last year, the team worked to release ‘add admin’ functionality, making the feature more actionable. Now, an admin can take over the discovered product and determine the appropriate next steps".

Admins do not want the the ability to take over a discovered product, they want the ability to stop people from creating new products. This does not solve the issue that was reported. This just creates more overhead for administrators who have to babysit the discovered product page to see if any new ones showed up.

"We will keep this ticket closed and appreciate your understanding, as well as your time to comment and interact here."

There you have it folks. Atlassian doesn't care and will keep this ticket closed. Hope you enjoy the "solution" they provided, otherwise upgrade to enterprise to get the feature you want.

I don't understand why this is behind a premium/enterprise wall at all. All of these ghost sites cost Atlassian money. Removing all of these things manually also costs time/money for the customer. Its a security nightmare. Surely it would benefit all plans and Atlassian to block these things. If Atlassian really think that unintended subscription fees are really worth hiding this feature behind Enterprise, then they are sinking quite low.

Also of note: When 23ef3e30d63c made her change, she retained the original summary and description as part of the Description. It looked like this:

Original summary and description

"Prevent users under a verified domain for being able to sign up for a new Cloud instance"

Not allow users of a Cloud instance which has the domain already claimed for being able to use their email(verified domain) for sign up to a new Atlassian Cloud instance.

If some user wants to get a new Cloud instance for any reason, it should ask for the instance Administrator.

On 15/Oct/2024 4:41 AM gjones@atlassian.com updated the description to remove that original context.

So I've been getting y'alls recent comments, but looking at the Summary of this ticket today, I had a moment of confusion:

"Allow non-Enterprise administrators to control managed users' associated sites and products"

I mean... they added the ability for regular Atlassian Guard admins to control (become admins) of managed users' sites back in ... Feb 2024. So it sure sounds like they delivered. Good job everyone. Milestone met!

And I was like. Man, so why are we still complaining?

Except... that in the History of this ticket, we can see that on 16/Nov/2023 7:27 PM, 23ef3e30d63c made a change to the Summary, which was originally:

"Prevent users under a verified domain for being able to sign up for a new Cloud instance"

Huh.

Well... I guess if you move the goalposts, it's a lot easier to make that kick.

Anyways. Feeling a little gaslit.

Wow, just wow, this should not be a premium feature, at least other products make it difficult to accidentally create a new site.

ac8ecbf6db22 Must the same people who thought my cafeteria could save money by making the free coffee taste terrible!

A member of Atlassian Support kindly raised CLOUD-12089 for me after my feedback that during the cancellation requests, none of the offered reasons made it clear what the situation was, recommend voting for it so that each cancellation we do adds to the case for a change in decision, I suspect a number of Atlassian users don't regularly use Atlassian's own Jira.  

In the last two days, we have seen the creation of 10 new products outside the organization. Additionally, our users are not aware of this situation. This occurs due to a gap in the process maintained by Atlassian. It seems unreasonable to require an upgrade to the enterprise plan only for this reason.

After 4 site deletions in a few months, it sure seems Atlassian's open door policies allowing licensed users with a claimed domain to go out and create new sites that get billed back to the original is just too convenient.

The provided "solution" is just shuffling off additional manual work to administrators & waste time going through the same mundane & tedious steps: reach out to user that created organization, cancel whatever subscriptions they set up, create a ticket to Atlassian support to DELETE the organization, wait for 2-3 weeks, repeat.

Oh my lord, you guys really put what should be a standard (or at least Premium, what are we paying extra for??) security feature behind the Enterprise paywall?  

I'd say that decision did accomplish one thing, now we know this security 'gap' was architected by Atlassian as an opportunity to collect unintended subscription fees. And their solution to fix the gap is....collecting even higher unintended subscription fees.

I guess we'll just keep opening PCS-Tickets for each and every site that our users accidentally create.

The Atlassian CEO and CSO should be ashamed of this as a resolution. Any organization that is internally promoting Shadow IT and doesn't prioritize customer data is a risk to do business with. 

It's only a matter of time before data is exposed from the wrong organization and Atlassian is blasted in a lawsuit and our industry... all over trying to make a little extra money. 

What a phenomenally bad and tone-deaf "resolution."

I'm afraid this is a dead (closed) ticket.

I also raised this question:

https://community.atlassian.com/t5/Confluence-questions/SECURITY-ISSUE-during-login-procedure-of-managed-users/qaq-p/2841895

Outrageous that this has been closed, detailing a 'fix' in Enterprise even though the ticket title is for Non-Enterprise - and further doesn't even fix the problem in Enterprise, per 3a86d20e561c 's comments. another vote here for re-opening this ticket - the problem is not solved!

Hi all,

Title of this security issue:

• Allow non-Enterprise administrators to control managed users' associated sites and products

Answer by Atlassian:

• With the Enterprise plan feature product requests, admins can set a policy and then either deny or approve requests for a new user-created instance. This feature is available to customers who have a Jira, Confluence, or Jira Service Management Enterprise plan - and coverage now expands to Trello and Bitbucket (Premium plan, in beta).

Conclusion:

• Atlassian does not care about the security of their Premium customers.

The intention is clearly to trick the managed users of a PREMIUM customer towards the creation of a shadow IT site and to start using it for work related data, outside of the managed organization, disregarding the fact that the CUSTOMER has already paid for the PREMIUM products of Atlassian.

This is definitely BAD INTENTION and a SECURITY ISSUE.

Stefaan

In general, apart from the fact that Atlassian has once again raised the prices of its products, it is ridiculous that the Administrators cannot block new sites that are created from verified domain email addresses.

To bad that Atlassian is a registered CNA - otherwise this would certainly warrant a CVE for allowing unprivileged users to perform a critical operation. Especially when taking 3a86d20e561c's remarks into consideration, that it doesn't even work when the enterprise feature is being used.

gjones@atlassian.com, you haven't 'solved these issues'. Please listen to all the feedback you're getting and reopen this ticket.

Two new products on my Discovered Products list today. One was created four weeks ago, but only appeared on the list today. More pointless admin to get these closed down.

For those saying that the solution is locked behind a paywall, we recently switched to enterprise for Jira. Even this doesn't solve the problem. The 'require admin review' option that comes with enterprise only applies for certain ways that users can create products. See Why can users create products when requests are required? (Which doesn't tell you why users can still do this, just confirms that they can.)

The solution put forth is clearly a middle finger to your premium customers.

Apparently this request is "Closed" now . I spend about 2 hours a weeks doing a clean up job to prevent users from unknowingly creating orgs and products as going against our companies attempt to promote collaboration and transparency to our users.

This functionality DOES THE OPPOSITE of what Atlassian is promoting on its website

• "Plan, track, and deliver your biggest ideas together."
• "Connect and consolidate scattered docs and disconnected teammates in one, central source of truth"
• "align everyone with product roadmaps - all in one single Jira platform."

gjones@atlassian.com please let me as an Admin of a Premium subscription disable allowing new products by going to Atlassian Admin > Security > Product requests (https://admin.atlassian.com/o/[...]/product-requests/settings). I frustratingly see the option, allow me to select it.

We will never double our cost by upgrading to Enterprise ONLY FOR THIS FEATURE. Atlassian is already a nearly impossible sell to our tech procurement because of issues like this.  

Honestly, I don't know what to say as it's not the only issue which is handled like this - it's basic Atlassian philosophy.
Just tell us directly that you don't care about your customers!
Everytime the same sh..! Feature requests have to be created for missing basic functionalities which should be of course logical to be there. Then we wait for ages to get the information that nothing will be changed.
What the hell to we pay money for every month and every year a lot more?!

gjones@atlassian.com Your update from October 15, 2024 does NOT describe a solution to the problem mentioned, which not only customers with an Enterprise plan have, but also those with a Standard plan. This is a serious security issue for all your cloud customers, which cannot be completely prevented with appropriate URL filter rules on a proxy or firewall (remote worker, etc.). This would only be a work-around anyway and not a real solution.
We therefore strongly urge you to reopen this ticket and finally create a suitable solution after more than 7 years!!!

If you have any difficulties in recreating the problem, I can only refer you to the very good and detailed comment by 8f4050917dd7 from October 15, 2024! (Thanks for that, Darryl!)

It is unbelievable that Atlassian is pursuing dubious strategies to drive business at the expense of its customers' security! 

Hi 8f4050917dd7 ,

Thanks. I had missed your comment.
You are right about mobile devices. That was very helpful.

Hi 198a0d57c156 - yes other users like 0b89c650c7a1 have previously posted URLs/patterns to block signups:

• https://admin.atlassian.com/o/create
• https://www.atlassian.com/try
• https://www.atlassian.com/try/*

Which is great, except it's not going to help me block mobile signups, as my users' devices are not managed.

I regret that Atlassian has indicated a willingness not to consider this as an essential security feature for its customers.

An alternative solution must be considered.

Would it be effective to block the trial start URL for each product with an internal proxy? (Except for the organization administrator, who would need to set up a trial site.)

For example, the URL for Confluence trial sign-up is as follows

https://www.atlassian.com/ja/try/cloud/signup

0b89c650c7a1 - I'm sorry I missed you in Barcelona. We should've had a meetup over this issue!

I also talked to a few PMs for Atlassian Guard. And to give some grace to gjones@atlassian.com, I (and they) honestly don't think this is an Atlassian Guard issue, or a feature, or a suggestion.

It's a BUG in the sign-in flow. These instances that have been created by my managed users, all 42 of them - they are NOT Shadow IT. NONE of the users who created these instances intended to stand up their own Confluence or Jira site.

They were created by mistake because of a broken login flow that after properly authenticating a user, they get redirected to a page that displays "Welcome back, Darryl", and presents them with a big blue button to continue, when it really should be redirecting them to https://start.atlassian.com or https://home.atlassian.com or whatever they're calling their central landing page now.

So if a new BUG can be filed about the broken login workflow, I think it should go something like this:

Summary: Broken login workflow when users start on atlassian.com
Steps to reproduce:

• User forgets what the URL of their Jira/Confluence site (CLOUD-6999)
• User types jira, confluence, or atlassian into their web browser/search bar
• User clicks a link to one of the many big blue buttons to "Try now", "Get it free", "Get Confluence free", "Get Jira free"
• User either enters their work email as prompted OR clicks on the tile for their IdP
• User logs IN using their company's IdP, thinking they are on the right track

Expected Results:

• Because Atlassian can see that the user is part of an organization that already has one or SEVERAL existing Jira/Confluence sites, it redirects them to https://home.atlassian.com, where they then choose the correct site.

Actual Results:

• User is redirected to the signup page for Jira or Confluence, where it gives them a comforting "Welcome back, Darryl" message in all bold, tricking them into thinking they are on the correct path
• The "Your site" is pre-filled with a name that contains the organization name: org-team, or because that probably was already accidentally created org-team-randomletters.
• Because site name does contain the name of the organization, the user thinks "Oh yeah, that's right" and clicks the big blue button, ignoring that it says "Agree and start now" because ... sure, they agree. It's probably just usual TOS.
• New site and org is created
• User does NOT end up on the site they were trying to get to

(There's some other things about admins having to clean up this mess, if they even can since w/o Atlassian Guard Standard you can't even do that, but yeah, that's probably sufficient.)

I do have some screenshots documenting this issue here.

Can't believe this ticket has been resolved without any sort of real resolution. Atlassian would rather you have to police the "discovered products" page, join the organization as admin, delete the instance than to lock down the ability for your users to create new products.

Also "With our Atlassian Guard (formerly Atlassian Access) feature automatic product discovery, admins are able to see what user-created instances exist within their cloud footprint, and join these instances to take over control. By doing so, they can remove certain users, products, etc. - and determine the best next steps." is not a real solution. Essentially you're spending time having to clean up organizations and having to wait 14 days for them to be deleted from Atlassian's environment.

Working in a field that handles PII and HIPAA data this is a huge issue. Shame on Atlassian for locking this behind an enterprise paywall. You should be ashamed for the blatant greed.

Request to reopen please.

As others have mentioned, this was not implemented at all. 

For example:

My users can go sign up for a Trello "free trial". Nothing ever indicates to them there will be charges incurred.

These users then become billable under Atlassian Guard. 

"Make a non-billable policy" workaround is not viable. My users still need to login to my JSM portal with SSO to create internal help tickets.

The last line of your resolution mentions:

For further information, please refer to our latest community post: An update on product requests: bringing shadow IT controls to Trello and Bitbucket

That article clearly states controls have been expanded for, "organization admin[s] with Jira, Confluence, and Jira Service Management’s (JSM) Enterprise"

How does this address the title of this request?

 "Allow non-Enterprise administrators to control managed users' associated sites and products"

gjones@atlassian.com "With our Atlassian Guard (formerly Atlassian Access) feature automatic product discovery, admins are able to see what user-created instances exist within their cloud footprint, and join these instances to take over control. By doing so, they can remove certain users, products, etc. - and determine the best next steps."

You're basically letting users create whatever they want, publish data, make it billable, expose it to the internet with the correct clicks, and then 24 to 48 hours LATER inform an admin. 

You've created unnecessary complexity, security vulnerabilities and toil... When all you need to do was block the users from creating the products in the first place. 

ticket resolution contradicts with the title. 

for everyone else URL blocking via firewall does the magic for free  - as per one of the comments earlier

@0b89c650c7a1 They all know... They are not being truthful about it. This is by design to drive sales. I've worked with various Atlassian leadership for over 2 years on this (please see my post from a few months ago). gjones@atlassian.com has made it clear, this is here to stay. 

"Shadow IT product manager (***Griffin) you previously engaged with, and he has confirmed that, unfortunately, we will not be including the shadow IT controls that enable you to block product creation, specifically "Product Requests," in any edition other than enterprise at this time. It's important to recognize that this challenge is not unique to our tool but rather a common occurrence in the software industry, reflecting the growth mindset that all SaaS providers strive to foster."

Strive to foster... code for MORE money for the vendor... NO security for the customer

I was in Team 24 in Barcelona, and literally talked to everyone who worked in Atlassian in each of the product booths about this issue.

No one there seemed to know anything about this issue or know who could address this within Atlassian.   

I saw Mike Cannon-Brookes (Co-Founder and Chief Executive Officer of Atlassian) and regret not asking him directly. 

Gathering interest for 7 years and 749 Votes, what does it take to get this pesky issue fixed!!!!!!!!!!!!!!!!!!!!

Please urgently add this feature.

It is a shame that Atlassian is promoting the use of shadow IT towards the employees of their paying customers.

And it is a pain in the *ss to remove all sites that the users are creating (this week alone: 8 sites!).

Most of the users that created their own orgs and sites don't even know how they did it. 

Right now, out of 18 discovered products only 2 were created voluntarily and only one of them is in use. 

In addition the users who weren't able to understand that they are creating a new site/org now get emails that their data is going to be deleted if they do not log in. they don't understand that they have access to multiple orgs, giving them access to administrative functions and confusing them.

After a well organized and straight forward approach in Confluence DC, the Cloud gives them options they shouldn't see.

It's actually ridiculous that they've put the feature to control this behind the enterprise subscription. We're paying for Guard that lets me know they exist but we have no ability to stop them unless I get Enterprise for both Jira and Confluence? Guard is your security tool so let me use it to make my organization secure. Don't nickle and diming while promoting shadow/accidental IT. Clearly something has changed recently where these accidental orgs are now popping up on a weekly basis. Somehow your team managed to make a problem worse before you make it better. Color me surprised....

I'm glad y'all are having to waste your own cloud resources to create and host all these accidental orgs. I'm now actively seeking alternatives to your products. Thanks.  

+1

There is a switch to disallow managed users from creating Jira projects in the Standard plan, yet the switch to disallow the creation of new instances requires an upgrade to an Enterprise plan. IMO there is no logic to such market segmenting. It really should be the other way around - users are limited to 1 instance in a Standard plan, and my company would have to pay more in order to unlock multiple instances.

Same problem here as for a00469ca237d.
Please make that available soon. That would prevent our users doing stupid things as they don't know what they do and would save me and I guess a lot of other admins a lot of time.
Thanks.

This feature is so important , we are on premium plan, but our users keep creating new sites by mistake , there must be a solution ..

What was in your photo, 09bb9c7a8ac1?

I have a recent photo of my Discovered products page showing 15 sites created in the last two months by MISTAKE by my users. Oh, and ONE which was created in June, but wasn't "discovered" until yesterday, somehow. (I've got a support ticket asking about that...)

I also have a lot of photos of Atlassian's pages which instead of directing already logged in users to the sites that they already have access to, instead shows a nice "Welcome back, Darryl" then encourages them to click a single button to create a new site.

I'm happy to help stir the pot...and I reject your cookies.

I am trying to stir the pot on this. We'll see  (I guess you cannot attach photos here) I emailed premium support

7 years since creation of this suggestion and still nothing...

For those of us who work in organizations that guard HIPAA data, this leads to the possibility of huge HIPAA violations. Anyone could create a product outside the organization and store HIPAA data outside of our protected realm, leading to violation of federal guidelines. Please fix this, Atlassian.

ID-7697 - Prevent managed users from creating cloud site using a verified domain. seems related. 

+1

Seems pretty ridiculous that this safeguard feature is locked behind a hefty enterprise tier paywall. There is no reason any managed account should be able to create a product outside of your organization. This can be dangerous if company information is accidently shared on the newly created product and public links are enabled which essentially circumvents any security measures you have in place on your real organizational product.

Additionally, you have to play babysitter by making yourself an admin of their organization, then you must talk to the employee about not creating products, spend time moving their data off and deleting the organization.

I can't believe that this is not standard. You get into a maintenance hell when using Guard and identity integration.

We need to pay for users in Guard, who are already deleted from the identity provider and who created a free Trello account. We don't have any chance to delete the account or the product.

The domain admin should have control over all products where the domain is used for a user account.

A managed domain account/email address should not be able to create a new Org with products. Yes, I can join as admin & cancel and delete the org, but that takes time and it should not be allowed in the first place.

Brian's comment is the way.

These CLOUD tickets make no reference to the other products Atlassian continues to release - Atlas, JPD... all being spun up and impossible to block or join as admin regardless of Premium vs Enterprise.

If you can, have IT block the URLs Brian listed.

If you can, find a way to automate a monthly or bi-weekly export of the directory to monitor the number of columns exported for the addition of new sites to hunt down for deactivation (and then teach me how because I do it manually).

And although Trello and Bitbucket are mentioned, the user directory export gives 0 information on which site is in use.  So, if you can, make sure you are cross-checking the user list exported from the Bitbucket site your claimed domain owns vs. the Bitbucket active users in your directory export to again, manually, hunt down.  I have searched CLOUD tickets for something requesting this, can't find one but if anyone knows please share.

And I have no idea what to advise about Trello unless you have deep pockets and can just get everyone in to JWM or at least get on Trello Premium.

https://admin.atlassian.com/o/create
https://www.atlassian.com/try
https://www.atlassian.com/try/*

@992b0dfccfdd 
Makes no difference.. Griffin has already made it clear this will NEVER see the light of day. They want you to purchase enterprise.. period. 

The correct way to vote for this issue is to click "Vote for this issue" in the "People" panel (top right). Please do not write "+1" comments – they produce unnecessary notifications for people watching this issue. Atlassian do not use comment count as a measure of popularity.

+1

+1

Atlassian Team, 

Please provide urls and ways, when regular users allowed to create new discovered products. We will try at least block those ULRs by vpn or other tools.

Why you can't disable this feature till providing smart solution for managing it by Org admins? and at least notify about some pilot and ask customers, who need this feature prior pushing it to anyone. 

We need to have this feature because it’s not reasonable for users to be able to do this. Please allow administrators to control managed users’ associated sites and products, or give us the option to block this option to our users as admins.

This needs to be fixed as soon as possible.

This is not an Enterprise feature, but core functionality found in every well-built, secure system i.e., a non-administrator must not be allowed to complete an administrator level task.

As a non-Enterprise customer, you are presented with the "Product request settings" option in the console, but it is disabled. The text linked under 'Product permission' reads:

"You need a Jira Enterprise subscription to be able to review requests for this product."

The text linked under 'Product permission' should read:

"Since you didn't pay for an Enterprise license that you obviously don't need, we decided to disable a core admin and security feature of the product. In addition, we have chosen to frustrate your administrators by showing a feature they can't use, having an open issue where we will openly ignore input and justify the lack of security in the interest of perceived possible future revenue, and finally waste their time by forcing them to manually check and delete unauthorized products creation done by any user in the organization."

But I guess there is not enough room in the module window, so they went with the shorter text.

As Org admins we should be able to manage what users are allowed to do on our tenant. please add this functions asap