Full disclosure: Today’s article is based upon one of my posts on techcommunity.microsoft.com from back in August. At the time I was contracting with a local school district as a SharePoint specialist. Since questions about this issue still come up I thought it would be good to reexamine the situation and write it up for WME in a (slightly) more formal manner. The ‘Mike Baker’ on the forum post is me, I swear!
First, a little SPO admin tale of terror to set the mood (based on actual events):
<nightmare>
Your name is Winslow.
The corporation you work for has finally taken your advice and formed an official cybersecurity department and seems to finally be taking IT security seriously. A few days later, you get an email from the new department head. Let’s call her ‘Prudence’.
“Hey, Winslow. Can you set up my department with a couple of SharePoints so my team can install the Azure storage on all their Netscape servers?”
(wanting to make a good impression, and still giddy from having another grownup follow your advice for once, you decide to ignore her well intentioned, but ultimately failed attempt to “connect with the IT guys”)
To facilitate her request, you have to first decide what kind of ‘SharePoints’ to make; a subsite or a site collection? The latter will have a more defined security boundary than the former so, given the nature of this new department, you decide the best thing to do is spin up a new SharePoint site collection. You shall call it ‘ Cybersecurity Department’ and it will have a address of /sites/security. You open up the SharePoint admin panel and look over your existing site collections. You don’t see any other site collections using that address so you are good to go.
Nothing to worry about here. Nothing at all….
You respond: “Hey Prudence! Give me like ten minutes to set it up for you! Your new SharePoint site will be [tenant].sharepoint.com/sites/security”.
In the web browser, you go through the 30 second process to create a new site collection. But things do not go as planned.
But I am the Site Admin!
Okay, maybe there’s just a problem with the browser. Like a expired cookie or something. You have the SharePoint Online PowerShell module installed already (as you should) so it’s simply a matter of running the New-SPOSite command and….Whaaaa????
$url = '[tenant].sharepoint.com/sites/security'
New-SPOSite -Url $url -Owner winslow@my.company -StorageQuota 500 -Title 'Cybersecurity Department'
New-SPOSite : A site already exists at url [tenant SPO root]/sites/security.
It seems that, despite the ‘/sites/security’ collection NOT being listed in the admin panel, a site collection with this URL already exists.
What is going on? Has someone hacked your tenant? You better find out fast because the clock is ticking and you don’t want to tell the head of the SECURITY department that you can’t create her SECURITY site collection because someone has breached your tenant SECURITY. You start to get short of breath. Prudence is really tall. She looked a lot stronger than you too. Oh, why didn’t you work out more? Game over man! Game over!
</nightmare>
Okay, relax Winslow! It was all dream. A terrifyingly plausible dream. But seriously, you are going to be okay, okay? You have not been hacked. Your experience is what happens when platform integration doesn’t work. In fact, you could call it…wait for it…platform disintegration!
MS Team sites: All URL Belong to Us.
In short, here is what is going on:
When a end-user clicks on the ‘Teams’ tile under the Office 365 waffle, they are allowed to name it whatever they want. Typically, we don’t care about such pedestrian issues. However, there was (apparently) a slight miscommunication at Castle Microsoft when the Teams product was rolled out to all Office365 tenants. See if you can find the problem below.
- The default “Web Site Address” for any new SharePoint Online site collection created in the browser is:
[tenant].sharepoint.com/sites/[whatever] - The default URL for any user-created Microsoft Teams site created when they click the ‘Teams’ tile is:
[tenant].sharepoint.com/sites/[whatever]
See how similar identical the two URL structures are? That’s the issue. When a end-user names their new Teams site, the URL is created to match. Since the URL structure is identical to those created for SharePoint site collections, whichever product grabs that name first, wins. In the case of poor Winslow, it seems that some at his company, as some point in the not-too-distant past, said to themselves “Hey I wonder what that new Teams tile does.” and then said “Hey look! Something I have never seen before! How pretty!” and then finally said “Well, since I have no idea what this is, I may as well name it Security after the spaceship in that show Fireflies”. And just like that, the /sites/security URL is hijacked by a non-admin user. You are welcome.
So now you know why you may sometimes get the (misleading) “permission denied” when trying to do something as simple as create a new site collection. But, other than the occasional fist-fight with Prudence, how can this negatively impact business operations? Oh, you have no idea. Two Words: Spear Phishing.
But fear not True Believer, my next post will provide you with a Threat Matrix of possible ways this “feature” can be exploited for all manner of litigation-ready actions AND ways to mitigate or, in some cases, eliminate the threat.
See you on the flip flop,
Mike
