Call to sites Graph API requires “owner” permissions for site collection regardless of app permissions

Okay – yet another weird issue, and a hacky workaround. I was developing an app that was calling a SharePoint site through Graph API, using jQuery $.ajax call (developed in TypeScript), and ran into surprising 401 errors. I did find a workaround, but am also working on an actual fix.

Description

To get SharePoint site ID, which is needed when accessing SharePoint lists, the calls seemed to fail for my test accounts. Everything was working fine for my developer account, which was a global admin, so the first thing I was suspecting was of course permissions…

The first offending test account was a Group member, and a restricted reader in the site collection I was trying to access via Graph. The account was also a contributor on the root site of the tenant. And all of my accounts were licensed with E3/E5.

I knew that this part of the code was supposed to get a site id for a certain SharePoint site collection with a call to Graph API, similar to this one:

https://graph.microsoft.com/v1.0/sites/<tenant>.sharepoint.com:/sites/<site>/

It worked for my developer account, but just wouldn’t work for the test accounts! This is the error I got:

I found this quite weird, as all the other calls to Graph API worked just fine. I was definitely authenticated just fine, as even with Graph Explorer everything else seemed to work. Just not the sites call (using /beta endpoint instead of /v1.0 didn’t change that).

You can even repro the issue in Graph Explorer:

Unauthorized call to /sites in Graph Explorer

Unauthorized call to /sites in Graph Explorer

 

Solutions

Okay, so I’m still investigating this, but I found a solution.. Or rather a dirty workaround! If I find actual solutions, I’ll be adding them below. Comparing the behavior to another site collection revealed, that it’s not consistent – some sites work with reader -permissions, some require owner -permissions… So there’s surely some kind of a setting or a switch that I’ve missed here!

Solutions that didn’t work for me (but might work for you)

Well, I tried the obvious steps first:

  1. Re-granted permissions to the app from Azure AD. That didn’t do anything.
  2. Made sure the test users could access the SharePoint site I was trying to call. They could, via browser, without errors.
  3. Added some more permissions to those accounts – namely, from restricted reader -> contributor, and invited to Style Library and Reusable Content (which were the 2 lists I was going to call)
  4. Granted ALL of the delegated permissions to my app. This is already quite dirty, but maybe I was missing something? Did not help, though.
  5. Granted “Full Control”-permissions to SharePoint Sites in Graph API for the application. This is already app permissions, not delegated anymore, so it should’ve worked. Did not.

So, yeah. In short, everything failed!

Solution that DID work: Add Owner-level permissions to the offending account

Someone could maybe call granting the app ALL delegated permissions, and even Full Control app permissions ridiculous. But the fix is actually (kind of) even more ridiculous. To access site X via Graph API, my test account had to have _at least_ Owner-level permissions on the site. Site Collection Administrator permissions worked, too.

 

 

The following two tabs change content below.

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.This is his personal professional (e.g. professional, but definitely personal) blog.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.