MS Teams & SharePoint Online: Some Disintegrations! Part 2

If you read last week’s blog post (and why wouldn’t you have?) you will remember that I covered why sometimes a SharePoint Online admin gets a face full of “Access Denied” when trying to create a new site collection. In short, it happens because of an integration failure between the time-tested SharePoint Online site collection URL structure and the scrappy young Microsoft Teams site URL structure. This creates problems for you SPO admins for numerous reasons.

  1. Administrative Roadblock (cannot create a site collection if a MS Teams site by the same name already exists)
  2. Administrator Lockout (cannot access a MS Teams site you did not create — even as the Global Admin)
  3. Administrative Blindspot (MS Teams site do not appear in the SharePoint Online admin panel)
  4. Easy Exploitability (nothing to stop User X from creating a /HR or /CEO Teams site and using it to spear phish other users!)

We addressed items #1 and #2 in last week’s post. Let’s get into #3 today:

Microsoft Teams site Owners: They are Everyone and They are No One.

The Goals:To know how many of these blasted Teams sites exist, who the heck they belong to and, most importantly, to reclaim their URLs!

The first part is easy because all MS Teams sites share two particular traits by default:

1. Their URLs all contain the ‘/sites/’ segment (which is why they conflict with site collections)
2. The ‘Owner’ field is empty (i.e. blank, but not null)

There are two MS Teams sites named ‘HR’ and ‘Security’. Neither of these appear in my SPO admin panel.

Sometimes you have so many actual site collections, that it’s hard to visually pick out the MS Teams sites. But thanks to the URL and Owner quirks being unique to Teams sites, you can expand your Get-SPOSite PowerShell command to list all MS Teams sites while not listing anything else (e.g. real site collections, My Sites). Remember when filtering like this, the “Owner” value we want is empty but not null. That means you should  match on just a pair of empty quotes like so:

Get-SPOSite –Limit All | Where {$_.Url –like "*/sites/*" –and $_.Owner –eq ""}

Behold! A literal plurality of Teams sites!

So you have a list of all the Teams sites in your tenant. But with the value of the Owner property blank, how do we know who to yell at for making them in the first place? The first time I hit this particular obstacle I wasn’t sure what to do. I tried leveraging Select-Object or adding the -Detailed switch to Get-SPOSite, but no matter what I did the value of Owner was always blank. I Google’d the heck out of it and got nowhere. Eventually though, those two summers I spent at Batman Detective Camp paid off big time.

“Sir, we’ve never met before is that correct?…”

It occurred to me that what I needed to do is re-run the Get-SPOSite command against a single URL. Since I already had all the MS Teams sites stored in the $msTeams variable, I used that and pulled the “Url” property from the first item in the array. In this case, that was the /security Teams site. The results were still not pointing to a person to blame, but at least the value of Owner was no longer empty.

Bingo! Wait…what? The value of Owner appears to be a GUID of some kind.

I know enough about GUIDs to know that they generally do not end with “_o”. I think that is telling me this “Owner” isn’t a person but an Office 365 group. But that can’t be right? I mean, how can a group be the “Owner” of a site? Doesn’t it have to be a user account? Has the whole world gone crazy?

Then I had whatever the SharePoint admin version of an epiphany is called. A SharePiphany? I don’t know. Anyway, I figured that if this was indeed a Office 365 group then it should be in the Azure AD database somewhere. The way to query that was my old friend MSOnline. Yes, I know MSOnline is being replaced with a more inclusive module, but that’s what I used so we are going with it.

“…is THIS your Owner?”

I trimmed the ‘_o’ from the GUID and saved it to a new variable $guid. Then I used the MSOnline PowerShell module and queried the GUID. WHOA.

It’s a madhouse! A madhouse!!

Not only is the “Owner” of the MS Teams site a group, it’s distribution group (apparently). But wait, if there’s a group of any kind that means that someone or something is in there. Only one way to find out I guess. After saving the group’s ObjectID to $id, I hold my breath.

User name withheld pending notification of next of kin.

Huzzah! There it is! The current Owner of this specific Microsoft Teams site is [redacted]. And it only took two PowerShell modules and a 5 bizarre steps to find this information for one MS Teams site. Oh, and don’t forget that there can be multiple Owners. The default Owner is whoever created the site but they can promote invited Members to Owner status, who can in turn invite and promote more people, and so on. In my (completely unproven) analysis, the first name on the list is the person you should talk to.

So let’s say you did just that. You talked with [redacted] and found them to be appropriately contrite. They clearly meant no harm. That’s nice, but it doesn’t really help you because you have Prudence pushing you to get her new Cybersecurity site up and running. But, despite any contrition by [redacted], you still cannot access the needed MS Teams site. They could make you an Owner but then, how do you delete the site and free up that URL for legitimate business use?

Reclaiming a Teams URL: Kill it With Fire

Sure and Global Admin cannot access the Microsoft Team Site, only the Owner(s) of the site can do that. But something the Global Admin can do is redefine the site Owner. If you still have the associated site URL stored in the $security variable, it just a simple command:

Set-SPOSite $security.Url -Owner winslow@[tenant]

Set it and Forget it!

As soon as you set yourself (or whomever) as the Owner, access to the site is possible via the browser like any other site. If you want you can log in and snoop around. The existing Owners don’t get dumped so they can still access the site as well. But if your goal is to reclaim the URL, the site has to be deleted.

Warning: You should only do this if you need to delete the Teams site to reclaim the URL. Overriding the default ownership on an existing MS Teams site, while very satisfying, will break its connection to the underlying Office 365 group. That means the site may no longer function as a user would expect a MS Teams site to function. I can’t say exactly how but, look just don’t do it unless you have to. People really like these Teams site things and there’s nothing to gain by needlessly breaking hearts.

To permanently delete a MS Teams site and get your URL back run the following in order:

Remove-SPOSite $security.Url -NoWait
Get-SPODeletedSite $security.Url
Remove-SPODeletedSite $security.Url -NoWait

You should be able to go back to your SharePoint Online admin panel and create a new site collection with “…/sites/security” as you were (trying) to do in the first place.

And there you have it. You can find your MS Teams sites, find their Owners (scolding as needed), and handily obliterate them with extreme prejudice grace and tact.

Next week: What a bad person can do with a MS Team site and a hijacked URL.



Contact Us

On Key

More Posts

WME Security Briefing 27 May 2024

Kinsing Hacker Group Exploits Docker Vulnerabilities Overview Recent investigations have shown that the hacker group Kinsing is actively exploiting Docker vulnerabilities to gain unauthorized access to systems. The modified hacker group targets misconfigured Docker API ports deployed with cryptocurrency mining malware.

Read More »
WME Cybersecurity Briefings No. 010
Cyber Security

WME Security Briefing 20 May 2024

Advanced Persistent Threats: North Korean Hackers Launch Golang Malware Overview A new malware strain, called Titan Stealer, is currently actively circulating in the threat landscape, targeting a variety of personal data and linked to North Korean state-sponsored cyber espionage

Read More »
WME Cybersecurity Briefings No. 009
Cyber Security

WME Security Briefing 08 May 2024

Exploitable vulnerability in Microsoft Internet Explorer, used to deploy VBA Malware Overview Cybersecurity researchers discovered a severe exploitation targeting a bug that had already been patched in the Microsoft Internet Explorer browser. Their report added that

Read More »
Be assured of everything

Get WME Services

Stay ahead of the competition with our Professional IT offerings.