Why is Atlassian promoting Shadow IT? Or Accidental IT?

[Darryl Lee]

Why is Atlassian promoting Shadow IT?

So, in their documentation, Atlassian warns about the dangers of Shadow IT and even talks about how Atlassian can be part of this problem:

"In the context of Atlassian, you’re unable to centrally manage these products from your Atlassian organization. This means that you won’t find them under the Products tab at admin.atlassian.com with the rest of your organization’s products."

So then, surely Atlassian must provide some tools to IT administrators to manage shadow IT? And why yes, yes they do, as described in Discover products your users administer. Oooh, what's this: Manage your users' requests for products?

Wow, you mean I can choose to prevent MY USERS from creating these problematic "shadow" instances of Atlassian products? That sounds EXACTLY what I need!

Oh, but sad trombone we don't have Enterprise Cloud. 

How much would Enterprise Cloud cost?

So our smallest instance is a JSM of 300 agents. Enterprise would cost $48,000 more per year. Is this worth the extra hours I spend having to delete instances? Hm....

Oh but wait, reading the screenshot above "update your request settings for each Enterprise product" (emphasis mine). Ok, that'd be $148,000/yr more for Confluence (5000 users) and $236,000/yr more for Jira (6000 users).

Ah well. I guess we should just hire an intern then.

Hrm.... I see this has been discussed before, ad nauseum. Or perhaps just ad nauseating: 

• Cloud Enterprise admins can now proactively manage product requests
• CLOUD-10325 - Allow non-Enterprise administrators to control managed users' associated sites and products
• ACCESS-1651 - Premium organisation admins ability to approve or deny the creation of new sites
• ACCESS-1272 - Allow to block non-administrators from creating new organizations

And the OG ticket, closed after 1600+ votes after they "fixed" it, but only if you pay for Enterprise:

• ACCESS-1468 - Allow Administrators to control managed users' associated sites and products

Some highlights:

"Lets call it what this is, hiding the age of the ticket by creating new ones. Now instead of looking almost 4 years old, it's just a recently created issue."

--mattpatenaude comment - 06/Oct/2023 9:28 AM the day Atlassian "resolved" the issue

Not Shadow IT, but Accidental IT 

Here's the thing though. We migrated about to Atlassian Cloud about a month ago - Jira, Confluence, JSM. Users want to use it. (Well, they don't have a choice.)

But users… get confused. In the nearly one month since we migrated, we've had nearly a dozen new instances created by mistake.

How does this keep happening?

Google

Users don't remember that our servers that used to be named jira.COMPANYNAME.com or confluence.COMPANYNAME.com are now COMPANYNAME.atlassian.NET. (.NET? Really? Ahem, CLOUD-6999)

So they Google it. Or type it into their browser bar, which… Googles it.

And they end up here:

Big Blue Buttons

And so, they click on Confluence. Which takes them here, with two very big, friendly, blue buttons, and one very tiny "Sign in" link.

Now, those of us who are Atlassian Admins know that you're not supposed to hit those blue buttons, but instead click on the very tiny "Sign in" link:

Sign up/Login? What's the difference?

But I'm guessing that 11 people at my company did not. Instead they clicked one of the blue buttons, and oh look, it's what kind of looks like a login page. Oh and we just migrated to Confluence Cloud, so perhaps this will give them some kind of tutorial. It does say "Get started with Confluence":

Now because me and my team have done the work to connect Atlassian Access Guard to our IdP, Confluence happily recognizes that user's account. They may have even been redirected to our Azure AD page and done their whole SAML login. Very secure! And now they're back.

Go team go!

Huh. "roku-team-...." that sounds right. I work for Roku. I'm on a Team. Let's go hit another friendly blue button.

And that… is why I now have an Excel sheet tracking "shadow" Atlassian Cloud sites created by mistake, including emails addresses of the users who mistakenly created them (who have ALL indicated they did this on accident), when I cancelled the sites, and assuming the cancellation actually goes through (which it often DOES NOT), when I have deleted the Organizations that were also set up for each site.

I guess this is a huge win to Atlassian's Sales Team who have designed a very efficient "funnel" to get users to sign up for new Atlassian Cloud sites. (Assuming they only measure sign-ups, and not cancellations by irate Atlassian administrators.) 

[Darryl Lee]

So this is fun: 

Last week I found that Product Discovery, er I mean Discovered products failed to discover a site that was created 2 weeks prior. No email, but worse still, it didn't even show up on the "Discovered products" page, which is what all of us poor standard users get. (HUH. Maybe they could add it to Atlassian Guard Premium, for less than Enterprise, but more than Standard.)

BUT WAIT. I also found a site created THREE (3) MONTHS ago that it did not find or list or email me about.

I mean, it had one job: Discover products.

(Yes, I've opened a Support Ticket. The Dev team is looking into it.)

[Darryl Lee]

So, last answer for tonight (or maybe ever, in case the person unhappy with my comment on CLOUD-10325 also decides to delete this question):

OF COURSE Atlassian wants to make it easy to sign-up for their products. It's how they got started.

• Atlassian - 20 years of Atlassian, 20 lessons learned 
  
  Software should be bought, not sold. 
  

  With most of our target market across the Pacific ocean in the U.S., Atlassian could either invest heavily in a traditional sales team or invest in building a self-service purchase experience. Mike and Scott chose the latter, even though it was a bit risky. They woke one morning in 2003 to find an order from American Airlines lying on the fax machine. According to company lore, they looked at each other and said, “Did you talk to them?” “No, did you?” … “Holy shit! American Airlines saw Jira on our website and bought it just like that!”
  
  

• Forbes - Product-Led Growth: The Atlassian Way To $2.8B And Counting 
  

  They began by looking online for tools they needed to complete their work. They realized that it was nearly impossible to get access to the software. You could go to IBM’s website but couldn't download software.

  SaaS had yet to develop. Walls existed between the users and solutions. So, they were forced to say, “Let's just get our tools online and make sure people have access to them.”

  They posted online and realized they had to have a significant market if they were going to sell products online. They said, “Hey, we have to think globally from Day One.” They started doing some Google search engine stuff early in 2002 to get that distribution.

  They believed they should make the software so inexpensive and easy to use that people would download it, try it and buy it.

  Within six to 12 months, they got a check in the mail for $10,000 from a major US airline. So, they doubled down.

And it would be fair to say that this was part of the plan for a while though. I mean, back in Dec 2020 Jay Simons laid it all out in this podcast:

To borrow from the analysis at How They Grow - How Atlassian Grows:

Eventually, most companies end up with a blend of these strategies. Like Atlassian today, who has a tiered pricing structure with trials (free, standard, premium, and enterprise). But, on their path to their first 1K customers where they were on a quest to get into as many companies as possible, not just the companies with the most seats — they kept it much simpler.

> [In the early days], we were so focused on reducing the cognitive load on the customer that was coming to us. And if you have four different versions at four different price points, that’s very difficult to help the customer wade through.

> It helped us when we were unknown and young and small because it was just so simple — the KISS principle actually worked in our favor, where you just came to the web and it was like, ‘Oh, Jira’s one price’. I just need to think about the number of users, I don’t need to think about, ‘Does it include this? Does it get SSO and the security stuff or no, that’s in the enterprise package. Is it worth twice as much for that stuff?

> There are all these questions that the customer gets bogged down into thinking about and that’s friction. [Which] can be okay in the right context with the right approach, but in our particular case, we chose not to introduce it. We were just going to make it simple. We're going to go for high velocity volume customer acquisition, and we're going to reserve future opportunity to have those expansion conversations with those customers.

— Jay Simmons, via First Round

Pressing on that last comment of Jay’s there a bit more. To to do that effectively, they used a free trial to bring users in, and then focused on getting them hooked so they’d then set off a domino approach and get others join. And with a low price point, people could easily try and buy Atlassian with a credit card rather than going through the headaches of financing.

As mentioned, they eventually expanded their pricing structure. But by then, as Jay says, “They’re already hooked. They’re already deeply committed. They love the product, and it’s used by thousands of users. Now they just want some extra security features and if we want to charge them for it, it’s probably easier.”

(Boldfacing mine, because welp, it's right there.)

[Darryl Lee]

Ooh ooh ooh. I know. Atlassian is leaving this as an opportunity for a third-party vendor to "fill the gap" (classic Atlassian)!

I mean, the Organizations REST API does have endpoints to Get organizations (so you can find out when somebody has created yet ANOTHER company-team-zx82asd site, by I guess checking every day ...)

And it even has a new (Beta!) endpoint for getting workspaces:

A workspace refers to a specific instance of an Atlassian product that is accessed through a unique URL. Whenever a user initiates or adds a new product instance, it results in the creation of a distinct workspace.

This API will:

• Return a paginated list of workspaces in a given org
• Return more details about an organization's products (including product URL).

Great! So now all we need is an API to:

• Request cancellation of sites that were created accidentally
• Delete organizations that were created accidentally

Oh, and your app is going to need to wait 14 days for cancellation to occur. *Sigh*. Oh and sometimes even then you can't delete the organization.

Maybe your app can also file a support ticket to ask them to fix that?

What a great opportunity! What marketplace vendor is going to step up to create this awesome tool?

[Darryl Lee]

OMG, I missed @Rob Allan's comment from yesterday:

"If you have the improved billing experience, you have to wait an additional 60 days after the products are deactivated to delete the organization." 

Seriously Atlassian? Is this a joke!?? 

From: https://support.atlassian.com/organization-administration/docs/remove-domains-and-products-from-your-organization/

 So yeah, ok, your app will have to wait 60 days.

[Darryl Lee]

Ugh. I realize that using the official Get organizations endpoint won't work because for discovered products, you are NOT the org admin until you add yourself.

SO ok, I guess I've gotta go rogue.

If you export your admin.atlassian.com cookies from your browser, this curl command will dump all of the rogue sites to a JSON file:

curl -b cookies.txt \
https://admin.atlassian.com/gateway/api/admin/v1/orgs/{org-id}/products/unmanaged> 20240924-discovered.json

So now I have a list of sites that includes when they were created, who created them (so you can send them a nice email), and their status. You ALSO have the org and site IDs, which is important for the next step:

You'll need to make yourself an org admin so you can request the site be cancelled.

curl -b cookies.txt \
https://admin.atlassian.com/gateway/api/adminhub/organization/{org-id}/shadow-org/{rogue-org-id}/join-as-org-admin?siteId={rogue-site-id} \
-d {"aaId":"YOURUSERID"}

But these are just some building blocks. And they rely on a cookies instead of a proper Org API key.

If I really want to automate this, I'd need to:

• Send an email to the creator, to confirm that the site was created by mistake. (Fun fact, since our onboarding of users to Cloud back in March 2024, out of 36 sites created by non-admins, exactly 0 of the creators got back to me to say they did it on purpose.)
• Request Cancellation/Deletion of the site, with explanation Other: "Created by mistake due to atlassian.com not offering path to log into existing site"
• File a support ticket that request deletion be expedited, because I don't want this site hanging around for 2 weeks.
• Automatically reply to the support ticket confirming my request, because they want to make SURE you want to delete the sites you requested be deleted.
• Monitor the support ticket to see when they will finally delete the site.
• On the day the site is supposed to be deleted, check if it has, and then attempt to delete the Org.

Because yeah, those are all manual steps right now.

[Michiel Schuijer]

I tried this approach with the cookies today, because we're seeing an uptick in sites created outside our domain, and I wanted a such a useful list, but unfortunately our Guard trial has ended and without that it is not possible do this.

You can test it by visiting the URL in question

https://admin.atlassian.com/gateway/api/admin/v1/orgs/{org-id}/products/unmanaged

if it returns "Subscription required", you know you need Guard :( 

[Michiel Schuijer]

With a trial of Atlassian Guard I was able to find out the current state of shadow IT on our organisation: 16 sites created accidentally in the past months only (between July and October).

The standard answer when asking my colleagues why they created a site was "oh, sorry, I didn't know I did that".

It is also easy to spot these types of sites from the naming convention and the fact there are usually only about 5 - 15 people added, the number of their team members...

Site name examples: ourcompany-team-xwl3ovsb.atlassian.net

Removing them is a burden and it is even worse for the older ones where the employees have been deactivated because they left our company and it is necessary to create support requests to "Billing", to ask if I can be added as org admin so I can then ask support to remove them?!

Oh, and when our Guard trial is over this is probably not possible anymore, because we're not getting the budget for Guard. Does mean I can't do the burdensome work, so maybe that is a relief? 

¯\_(ツ)_/¯

[Darryl Lee]

via GIPHY

Ugh yeah, it's infuriating that without Guard, you can't do anything about these sites.

And these emails that notify you about them without actually TELLING who created it or what the site URL is are infuriating. 

It's does feel a bit like a hostage/blackmail situation:

                        TAKEN (ADVANTAGE OF)
                        based on true events

FADE IN:

OFFICE BREAK ROOM
People are enjoying coffee and bagels, chatting about how great RTO is. 
So much synergy is happening.


CLOSE-UP COMPUTER SCREEN

Ominous music starts playing. Ding of a new mail. (Picture below)

              From: "Atlassian <noreply-ofcourse>".
              Subject: 1 product created outside YOUR COMPANY.

            VOICEOVER (Liam Neeson-like actor):

     So... someone in your domain, which you've gone to the 
     trouble of verifying, so we know you care about such things... 
     they've created a site that where they can:

• Invite other users in your company to access

• Invite people outside of your company to access

• Make the pages/spaces/projects/issues visible to the world, without any login

• Share PII, PHI, HIPAA, proprietary, top secret data without ANY REVIEW, again, using accounts with YOURCOMPANY domain."

     If you ever want to see these sites, or know who created them, 
     you need to pay us $4/user. We accept credit cards and of course 
     can issue a quote for your billing department to issue a purchase order.

     Remember: Until you pay us the ransom, any of your users can 
     create a huge security headache for you!

     We'll be waiting. 

(Sorry this screenshot is from an email back in 2021 when we didn't subscribe to "Access".)

[Darryl Lee]

Hum. Worth a separate article, methinks:

• What's another word for blackmail? 

[Peter Fjelsten]

Thank you for your quest.

I agree wholeheartedly with everything you have written.

Atlassian need to fix this or it will be just another reason for admins to looking for alternative products - IMO Jira is overpriced. Yes, they do not have all the features but are a fraction of the price. We're a 1000 user installation. 

[Darryl Lee]

Welp. This is a pretty depressing answer, found in a recent comment on CLOUD-10325:

I have over 2 years of emails and meetings going back and forth with Atlassian on this issue. I even worked with their Shadow IT team while they were building the solution to block these from being created...

However, to date, it's only a feature for customers on their Enterprise plans.

I have confirmation provided to me today, Friday June 21st 2024, that Atlassian has no plans to extend the feature to non - Enterprise customers.

Here is their email:

I truly appreciate your patience as we delved deeper into this matter internally. I reached out to [*Name removed because I care about privacy and data security; unlike Atlassian*], the Shadow IT product manager 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.

 Hum. That sucks.

[Darryl Lee]

So not an answer, but even worse news:

Another Community Leader tells me that even with Enterprise, he's still seeing rogue sites show up, and he suspects it's because Atlassian's "Product Requests" feature doesn't cover/block requests from folks on their mobile devices.

That is... not great, considering that for many users (ahem, YOUNGSTERS), they spend more time on their phones than in front of computers.

As previously mentioned, we're not on Enterprise, but I just checked, and the path to accidentally creating a site via mobile is MUCH MUCH easier. Oof:

So then, play in 1 act:

Customers: Hey, can you stop letting our managed users create new sites?
Atlassian: Sure, give us that Enterpri$e Money$
Customers: Grrr, ok here.
Atlassian: Haha, did you think it would also prevent mobile users from creating new sites? $ucker! For that feature you'll need to pony up for Enterpri$e Plu$!

[Darryl Lee]

To be clear, my example above is if you have previously logged in on your phone to your company's Atlassian site (which I assume my users must've done once before), but shows up even if you have logged out.

If you not ever logged in (or clear all Atlassian cookies from your browser, which, can you even do that on a phone?), you will see this screen:

(Screenshot from an Incognito session)

From there typing your email (if your company has claimed your domain) and clicking "Sign up" will take you to your company's SSO. OR, since we are on Azure, some users will click [Microsoft].

In any case, once authenticated, users will end up on the "Welcome back" page. Actually trying from Incognito just now, I'm seeing this page is even more streamlined:

It's kind of a bummer that if they're Welcoming me back, they're not showing me https://start.atlassian.com/ (which I guess now is https://team.atlassian.com/)

[Michiel Schuijer]

And the saddest thing here is, I can only "like" this comment and your very astute post :( 

[Darryl Lee]

Ohey! I was told at Team 24 Europe last week that Atlassian has supposedly FIXED the bug that still allowed managed users in orgs with Atlassian Guard Enterprise to create sites on mobile devices (even if Product Requests are set to require review).

So hey, paying for Enterprise is totally worth it now. ;-P

[Ed Letifov _TechTime - New Zealand_]

And the cynical analysis of the problem behind the scenes is no doubt:

"a problem exists between the keyboard and the chair"

I feel you @Darryl Lee especially on the "assuming the cancellation actually goes through" bit.

And then someone will design a technological 3rd party solution faster than proper controls are implemented. And charge money for that too. Maybe this is my💡moment?

[Darryl Lee]

So over in https://jira.atlassian.com/browse/CLOUD-10325 (where I might be banned?) @brian_g wrote:

I just recieved a potential ray of hope. 

It was suggested that we could create a firewall rule in our corporate network/VPN to restrict network access to the following addresses:

• https://admin.atlassian.com/o/create

• https://www.atlassian.com/try

• https://www.atlassian.com/try/*

so users could not create Atlassian organizations themselves and could not open the pages that allow them to start their own site subscriptions.

Please note that such network rule will not block you from adding additional products/sites to your current organization, but will be a blocker should you legitimately require to create another cloud site for your company in a separate Atlassian organization.

Hrm. I guess I could ask our network team if they can redirect those URLs to a proper login page. Or to a Confluence page asking if the users were trying to create a new site.

Thanks!

[Dave Liao]

@Darryl Lee - thanks for putting this together.

I'm also affected by this system behavior, and it's frustrating.

In terms of luck, so far no one has spawned a Cloud instance out of malice (i.e. trying to work around my team), and it has all been accidental.

I voted up the JAC requests that directly affect my team/company, and also will mention this to my Atlassian rep to know this is a concern for us. 

[Kristian Klima]

Shadow or accidental, when it comes to consequences, it doesn't really matter.

This was posted on a Community forum yesterday.

https://community.atlassian.com/t5/Confluence-questions/advice-after-anonymous-access-allowed-rampant-page-and-draft/qaq-p/2731249#M316076 

[Darryl Lee]

Oh man, that is awful. I really hope he has backups from Aurora.

[Hans Polder]

I wholeheartedly support your frustration @Darryl Lee , it has been an evolving issue in the companies that I have worked for. And even with the new 'Add admin' feature, it is still annoying and time consuming to wait the unpredictable waiting period after cancelling the products, to be able to hopefully delete the organization that was created with it.

On the other hand, it's one of the things that keeps us busy and employed, so.... 😅

[Darryl Lee]

Hi @Hans Polder - If you file a support ticket (which I do, and which I've very nearly automated), you can request that they expedite the deletion process, and they will also give you a definitive date when the site is scheduled to be deleted.

Yes, I track all this in an Excel sheet so I remember to delete the org when the site is finally deleted.

Truly, I would rather be doing other things with my time, and my employer would too.

[Sid Pathirana]

Hi @Darryl Lee - we occasionally have this problem as well, although not frequently as you do!

From previous experiences, I know the standard cancellation and deletion process can take months as it factors in:
• Subscription cancellation date
• Next billing date
• Suspended for 15 days of grace period after the billing date
• Retention period of 60 days after the grace period before the deactivation of the product and removal from the site
• Deletion of the Org

You mentioned about having nearly automated the process to submit a support ticket for the deletion process - I'm interested in that, are you able to share more details please?