Author Archives: Vlad Software Engineer

About Vlad Software Engineer

Microsoft 365 Teams, SharePoint, Search, PowerShell, Azure...

Access SPO Site Programmatically via MS Graph API and SharePoint API

5 Replies

Scenario

You are a software developer. Your company uses Microsoft Office 365 (SharePoint, Teams etc.). The need is to work with a specific site collection programmatically (from code – Python, C#, Java, PowerShell, JavaScript etc.) – e.g. upload/download documents, update list items, search etc.

The code must run without user interaction (unattended, aka daemon app). Sometimes this is also called “SharePoint Automation”.

The solution is based on a new Graph API feature – Sites.Selected and a classic SP-Only app.

Solution

  1. Register an Azure App and configure it as usual.
    Select API Permissions blade and add two permissions:
    – Microsoft Graph -> Applications Permissions -> “sites.selected”
    – SharePoint -> Applications Permissions -> “sites.selected“
  2. Request “Grant admin consent” from a tenant/global admin
  3. Request SharePoint admin to run PowerShell code (e.g. this one) to assign proper permissions to your azure app for a specific site collection (consider site owner consent)
  4. (optionally) Provide SharePoint API permissions:
    (require Site Collection Owner/Admin account) – use
    https://YourTenant.sharepoint.com/teams/YourSite/_layouts/15/appinv.aspx
    to add SharePoint API permissions to your app. E.g. full control permissions to site collection would be
<AppPermissionRequests AllowAppOnlyPolicy="true">  
   <AppPermissionRequest Scope="http://sharepoint/content/sitecollection" 
    Right="FullControl" />
</AppPermissionRequests>

Consider minimal permissions (e.g. Right=”Read” see more with Sumit)

Problem Solved

  • you get access to one and only one site collection (“least privilege” principal)
  • you get both – SharePoint API and Microsoft Graph API permissions to SharePoint
  • you can use app secret or certificate to authenticate – depending on what are your security requirements

Note: if your scenario require authenticated user present – the solution would be a little different: Connect-PnPOnline Interactive with Client App Id

Update:

Sites.Selected API MS Graph permissions was introduced by Microsoft in 2021. It was a huge step forward, but still devs were limited with MS Graph API against SharePoint.
So devs had to use AppInv at site level to provide ACS permissions to their apps to use SharePoint CSOM and REST APIs.
Recently Microsoft introduced Sites.Selected SharePoint API permissions for registered Azure Apps! So now devs should be fully happy without ACS-based permissions AppInv.aspx. (See more here on disabling SP Apps Only SPNs)

Thanks to Leon Armston and Scott Murdock

Update 2:

Microsoft announced end-of-life for ACS permissions, so we’d need to avoid ACS permissions for new development.

References:

Authenticate to Microsoft Graph from PowerShell Interactively

Leave a reply

Scenario

You are a developer or power user in a company with Microsoft 365 tenant.
You need to connect to Microsoft Graph and then call Microsoft Graph API to consume some MS Graph resources on behalf of authenticated user programmatically with PowerShell – e.g. add/remove documents or list items, search for sites or documents content etc. – whatever available with Graph API.

You do not have tenant admin permissions or any tenant-level admin permissions (SharePoint, Teams, Exchange etc. ). But you can register an Azure App and request tenant admin consent.

Solution

  • register an Azure App
  • under authentication blade – add platform – “Mobile and Desktop app”
    add “http://localhost” (and select …/nativeclient Url ?)
  • under API permissions blade – add delegated permissions you need
    (refer to specific API you’ll use)
  • install MSAL.PS PowerShell module
  • use the following code to get graph access token and call graph API
$AppId = ""
$TenantId = ""
$connectionDetails = @{
    'TenantId'    = $AppId
    'ClientId'    = $TenantId
    'Interactive' = $true
}

$token = Get-MsalToken @connectionDetails
# or 
$token = Get-MsalToken -TenantId $TenantId -ClientId $appId -Interactive 

$Headers = @{
    'Authorization' = "bearer $($token.AccessToken)"
}

Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

You can find the code sample here: https://github.com/VladilenK/

Did not work:

Az PowerShell module did not work for me:

Connect-AzAccount -Tenant ""
$azAccessToken = Get-AzAccessToken -Resource "https://graph.microsoft.com" 

$Headers = @{
  'Authorization' = "$($azAccessToken.Type) $($azAccessToken.Token)"
}

Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

As I understand we need somehow let Azure know API permissions we want (e.g. via app registerd)…

PnP did not work for me too:

$url = "https://orgname.sharepoint.com"
Connect-PnPOnline -ClientId "" -Url $url -Interactive 
$pnpToken = Get-PnPGraphAccessToken 
$Headers = @{
    'Authorization' = "bearer $($pnpToken)"
}
Invoke-RestMethod -Uri 'https://graph.microsoft.com/v1.0/me' -Headers $Headers

# did not work as well:
$pnpToken = Get-PnPAppAuthAccessToken
$pnpToken = Get-PnPAccessToken

the error message was (maybe I missed something – please let me know):

“code”: “InvalidAuthenticationToken”, “message”: “Access token validation failure. Invalid audience.”

References

SharePoint site full permissions report

1 Reply

There has always been one problem in the SharePoint world: full site permissions report. Full means across entire site – including all objects with broken permissions.
It seems like Microsoft has solved the problem: Full site permissions report is available for site owners out-of-the-box.

How to get SharePoint All Site Permissions Report

(Ensure you are site collection admin or team/group owner).
Just navigate to Site Usage, scroll to the end and run report.

  1. Select gearbox “Settings” and then Site usage:

Or Select “Site Contents”, then “Site Usage” as shown below:

2. Scroll down to the “Shared with external users” block and click “Run report”:

  1. Create/Select folder (*) for the report and click “Save”:
    • If there are no folders in the Documents folder – you need to create one (otherwise you will not be able to save it:)
  • Once yo have a folder available – just click “Save”:

Give it some time (5-10 minutes) – check the folder’s content. There should be a file with a report on all site permissions.
For items shared with direct access, the report contains one row for each user / item combination.
SharePoint groups are shown in the report as groups (not individual users inside them… so you have to check group membership to get really full permissions report).

Again, you must be a site admin to run the report.

  1. Secure the permissions report
    If you don’t want other site members to see the report – secure the report’s folder – e.g. for site owners and for those who must be able see the report…
    Consider creating a separate library for permissions reports and secure it instead of securing a folder under Documents.

Some more ideas on SharePoint permissions

Permissions are tricky in SharePoint. By default, you have permissions assigned to the root site of the site collection and all subsites, libraries etc. inherit root permissions.
But you can break inheritance at any level you need to provide specific (unique) permissions to the resource.
Of course you can always navigate to the resource and check resource permissions. But… what if there are hundreds of broken permissions… should you iterate everything under your site to check manually if permissions are broken or inherited?

So the real problem was – you never knew who have access to your site as there was no out-of-the-box tool to get all site permissions in one single report. There are third-party solutions – like ShareGate, Metalogix or SysKit – or you can develop PowerShell script generating report on all SPO site permissions. But… finally Microsoft solved this problem – Microsoft implemented out of the box full site permissions report.

Reference:

Microsoft Report on file and folder sharing in a SharePoint site

Microsoft Search country-targeted bookmarks: new “Use Azure AD locations” flag

Leave a reply

If you have country-specific content – Microsoft Search allows bookmarks to be configured to pop-up only for users from a specific country.

And “Use Azure AD locations” flag is a new option that make it actually works…
For a long time country settings were the same but without “Use Azure AD locations” flag. So what does “Use Azure AD locations” flag do?

Use Azure AD locations

“Use Azure AD locations” flag is a straight-forward configuration settings. It says: “This bookmark will only appear for users with Azure AD locations that match selected countries or regions. If cleared, the user’s IP address will be used to determine location. This checkbox can be altered from both Country or region setting and Targeted variations setting.”

I have tested this new “Use Azure AD locations” flag – it works. Once you configure user’s country in AAD and country-targeted bookmarks – all works good. Bookmarks appear for the user.

What if we do not “Use Azure AD locations” flag

to be provided

What was before “Use Azure AD locations” flag

What was before Microsoft implemented this “Use Azure AD locations” option? How did Microsoft understand “this user is from that country”. What was the criteria to correlate User <-> Country? License assigned country? Windows locale? Browser settings? Azure AD properties?

How does Microsoft define “this user is from that country”. What are the criteria to correlate User <-> Country? Physical IP address? License assigned country? Locale? Browser settings? Azure AD properties?

It turned out, the way it was designed previously:
– configure Microsoft 365 integration with Bing
– in Bing -> Settings : select Country/Region
– search from Bing
that was the only way to make it work! So yes, do not leave “Use Azure AD locations” option unchecked. Microsoft confirmed it was poor design.

Always “Use Azure AD locations” flag.

Resources:

SharePoint sites shared with Everyone and Microsoft Delve issue

Leave a reply

There is was a known problem with Microsoft Delve. It’s not a technology problem though. (Upd: Delve is scheduled for retirement in Dec 2024)

We know SharePoint site permissions are not easy to manage. E.g. you can break permissions inheritance at any level – subsite, library, list, folder, list item or specific document. Anybody with full permissions can do that. The worst thing is there is was (*1) no native ability for site owner to get full site permissions report. We must have used third-party tools or PowerShell to have all permissions in one document.

So no wonder SharePoint sites were heavily over-exposed. Especially when a site owner tired with complexity of SharePoint permissions system decided to share resource with “Everyone”. And the other person, not knowing site is shared with everyone, might save some sensitive data. That is the real issue.

Now, what is Delve? It’s a service that
– get signals from allover Office 365 – who did what etc.
– based on that, using AI and Office Graph, generates suggestions – “what others do”.
Of course, Delve is security-trimmed, i.e. it will neve suggest you a document you do not have access to. But some sites might be overshared. Delve works as it should work – it suggests you documents it believes related to you (based on Microsoft Graph insights) and you already have access to.

Now bad thing happens – people start seeing documents they never new they have access to. Where are these documents from? Of course from sites shared with Everyone. Who to blame for the security breach? Delve? Microsoft Graph? Microsoft 365 SharePoint Online?

Strictly says, it is not Delve’s problem. It’s more human problem than technological.
Delve just does it’s job, and does perfectly. Delve simply displays the information already shared widely.

How do we solve the issue?

  1. Disable Delve?
  2. Disable search (stop sites crawling and remove results)?
  3. Restrict users who can provide signals via item insights privacy?
    see Microsoft KBA on how to disable MS Graph for a specific User

Those methods are half-measure. Methods above are just hiding the problem – not solving it. Agree it helps stop the deterioration, bud does not fix the root cause.

How do we solve the real problem and what is the root cause?

  1. Of course, we need remove incorrectly provided permissions. How?
  2. Only site owner (data owner) knows which content should be shared with whom with which access rights. So we need to ask sites owners to review their permissions. How?
  3. First, we need a list of over-exposed sites. How?
  4. There are two methods (more details – check this article)
    • Brute force – use PowerShell or 3-rd party tool to get permission report on all sites in tenant, select permissions provided for Everyone…
    • Smart move – use Microsoft search. As search is security-trimmed, we can search for available content on behalf of a user with no permissions provided.
  5. Then we find owners for each wide-open site. How?
    • for group-based sites we get member of the “owners” group
    • for non-group based sites we get site collection administrators
  6. We would also sort sites by “is it supposed to be public?”. I.e. if the site was born as public – e.g. Public Team or Public Yammer community – or Communication site – maybe it’s less concern.
  7. It would be a good idea to bring DLP and/or automatic content sensitivity labelling, so we could start remediation from sites labelled as storing most sensitive data.
  8. Finally, we need to let site owner know that his site is Open to everybody and ask to fix it. How?


References

Bill Baer’s on search and “prevent sensitive files from being exposed in search”