OneDrive and SharePoint

Enabling Enprivacy to read files from OneDrive for Business or a SharePoint Online document library — Microsoft 365 administrator guide

Audience: Microsoft 365 / Microsoft Entra ID administrator
Privileges required: Application Administrator or Cloud Application Administrator (to create the app registration) and Privileged Role Administrator or Global Administrator (to grant tenant-wide admin consent). The optional least-privilege path in section 3b additionally needs a SharePoint Administrator.
What this enables: A dedicated, single-tenant Enprivacy instance running for your organisation can read files from the OneDrive drives or SharePoint document libraries you nominate. Read-only. No writing, no deletion, no upload.

Unlike the Gmail integration, this is app-only access: there is no per-user consent screen and no signed-in user. An administrator grants the permission once, to the application, and Enprivacy reads with that grant on a schedule. That makes the scope of what you grant the whole of the access control, which is why section 3 is the part worth slowing down on.

One guide, because it is one integration

A user’s OneDrive and a SharePoint document library are both Graph drives, read through the same API by the same connector and the same app registration. Almost everything below applies to both, and the app registration you create serves every drive and library in the tenant — so there is one of it, not one per source.

Only three places differ, and each says which kind it is about:

	OneDrive	SharePoint
§3 — permission	`Files.Read.All` (tenant-wide)	`Files.Read.All`, or `Sites.Selected` scoped per site
§5 — what identifies the drive	the user	the site address
§6b — source fields	User	Site URL, document library

Everywhere else — the registration, the secret, the credential, verification, rotation, auditing — is the same for both.

1. What is being granted, and what you exchange with Enprivacy

Enprivacy authenticates with the OAuth 2.0 client credentials grant against your tenant and calls the Microsoft Graph v1.0 API. Both OneDrive and SharePoint are read through the same Graph driveItem endpoints — a user’s OneDrive and a SharePoint document library are both drives — so one app registration covers both, and the only difference is which drive a given source points at.

The token request

Enprivacy requests the scope https://graph.microsoft.com/.default. This is not a choice and not a wildcard: the client credentials grant issues one token per resource, and the identity platform requires the /.default suffix, refusing any individual scope with AADSTS1002012.

/.default means “the application permissions an administrator has already consented for Microsoft Graph” — no more. So the set of permissions on the app registration is the grant, and widening it later is a change in your tenant, made by your administrator, with its own approval and audit trail. Enprivacy cannot broaden its own access.

What you will need to hand (in section 6)

Collected as you go, and entered into Enprivacy by you. None of it is sent to Enprivacy — the app registration is yours, the secret never leaves your tenant except into your own instance.

Value	Where it comes from
Directory (tenant) ID	Entra ID → the app registration Overview blade
Application (client) ID	Same blade
Client secret	Created in section 4; shown once
Secret expiry date	Shown beside the secret in Azure; recorded against the credential
User principal name (OneDrive) or site URL (SharePoint)	Whichever drive is being scanned — section 5

2. Create the app registration

Sign in to the Microsoft Entra admin center as an Application Administrator or Cloud Application Administrator.
Go to Identity → Applications → App registrations, and click New registration.
Name: something identifying, e.g. Enprivacy Content Scanner. This name appears in the consent dialog, in the enterprise-application list, and in sign-in logs — make it obvious to a colleague auditing later.
Supported account types: select Accounts in this organizational directory only (Single tenant). Enprivacy runs single-tenant per install and never needs multi-tenant.
Redirect URI: leave blank. There is no browser flow here, and an app registration with no redirect URI cannot be used for one — which is a small, free reduction in what the registration can do.
Click Register.
On the Overview blade, copy the Application (client) ID and the Directory (tenant) ID.

3. Grant the permission

Two options. Decide between them before granting — switching later means re-consenting and re-testing.

3a. `Files.Read.All` — simple, tenant-wide

This is the permission Microsoft’s own scanning guidance names for applications of this kind, and it is the straightforward choice.

Be clear about its reach: Files.Read.All as an application permission grants read access to files in every user’s OneDrive and every SharePoint site in the tenant. Enprivacy will only read the drives you configure as sources, but that is Enprivacy’s restraint, not the tenant’s — the token permits more. If that is acceptable for your posture, this is the option to take.

In the app registration, go to API permissions → Add a permission.
Choose Microsoft Graph, then Application permissions (not Delegated — there is no signed-in user).
Search for and tick Files.Read.All.
Click Add permissions.
Click Grant admin consent for {your tenant} and confirm. The Status column must show a green tick; until it does, every call returns 403.

Do not add Files.ReadWrite.All, Sites.ReadWrite.All or Sites.FullControl.All. Enprivacy only reads. A write permission on this registration is capability nobody needs and everybody inherits.

3b. `Sites.Selected` — least privilege, per-site grants

For SharePoint document libraries, Sites.Selected is the narrower path and generally the right one where your policy resists tenant-wide grants. The app is consented for SharePoint access but receives zero sites by default; a SharePoint administrator then grants it read on specific sites, one at a time, and can revoke a single site without touching the rest.

Add and admin-consent Sites.Selected (Application) exactly as in 3a.

For each site Enprivacy should read, grant the app the read role. With the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scopes "Sites.FullControl.All"

$site = Get-MgSite -Search "Finance"      # or resolve by hostname + path
$params = @{
  roles = @("read")
  grantedToIdentities = @(@{
    application = @{
      id          = "<Application (client) ID>"
      displayName = "Enprivacy Content Scanner"
    }
  })
}
New-MgSitePermission -SiteId $site.Id -BodyParameter $params

Revoking later is Remove-MgSitePermission against that one site.

Enprivacy needs no configuration change for this — because the token carries whatever you consented, the same source settings work under either permission model.

The limit worth knowing: Sites.Selected scopes to SharePoint site collections. A user’s personal OneDrive is technically its own site, but there is no application permission that scopes file access to a named list of users’ OneDrives in the way Sites.Selected scopes SharePoint. If your sources are OneDrive drives and tenant-wide Files.Read.All is unacceptable, the practical answer is usually to move the content into a SharePoint library that can be scoped, rather than to scan personal drives.

4. Create a client secret

In the app registration, go to Certificates & secrets → Client secrets → New client secret.
Description: e.g. Enprivacy instance. Expires: choose the shortest period your rotation process can sustain; Microsoft’s maximum is 24 months and the portal default is 6.
Click Add.
Copy the Value column — not the Secret ID.

The secret value is displayed only now. Once you navigate away it cannot be retrieved, only replaced. Treat it like a password: never email it in plain text, never commit it, store it in a secret manager.

Note the expiry date — you will enter it into Enprivacy in section 6. Enprivacy records it against the credential and shows it on the expiry horizon at Estate → Credentials, along with an “Expiring 30d” count. Without that date nothing warns you: when the secret expires, the health check on the source flips to failed with an authentication error and discovery stops. Rotating is creating a second secret, updating the one credential in Enprivacy, and then deleting the old secret.

5. Identify the drive to scan

OneDrive

Enprivacy needs the user principal name (alice@contoso.com) or the user’s Entra ID object GUID. It resolves that user’s default OneDrive automatically.

The drive_id field is optional and normally left blank — it is there for the rare case of a user with more than one drive.

This must be OneDrive for Business, not a consumer OneDrive account. App-only access against a personal Microsoft account is not supported by this grant.

SharePoint

Enprivacy needs the site address, copied from the browser — https://contoso.sharepoint.com/sites/Finance. It is split into a hostname and a path on save, and both remain editable if you would rather set them yourself. The tenant’s root site is just the hostname with no path.

Enprivacy reads the site’s default document library. If the site has several and you need a specific one, list them and note the id of the one you want:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/drives

6. Configure Enprivacy

Two steps, and the split matters: the app registration is stored once, and each source points at it. A tenant has one registration; an estate usually has several sources (a few SharePoint libraries, a few users’ OneDrives). Entering the secret once means rotating it once.

6a. Create the credential (once per app registration)

Go to Estate → Credentials → Add credential and choose Microsoft Entra ID app registration.

Field	Value
Name	How this registration should read in pickers, e.g. `Contoso tenant`
Expires	The secret’s expiry date from section 4
Directory (tenant) ID	From section 2
Application (client) ID	From section 2
Client secret	The secret value from section 4

Setting Expires is what puts this registration on the estate’s expiry horizon. It is optional, and it is the only thing that will warn you before a lapsed secret stops discovery.

The credential’s page lists every source using it — so before rotating, you can see exactly what is affected.

6b. Create the source (once per drive or library)

Go to Estate → Content → Sources → Add source, and choose OneDrive or SharePoint.

Field	Value
Name	How this drive should read in the estate, e.g. `Finance SharePoint`
Entra ID credential	The credential from 6a
User (OneDrive only)	UPN or user GUID from section 5
Drive ID (OneDrive only)	Leave blank for the user’s default OneDrive. Only needed for a user with more than one drive.
Site URL (SharePoint only)	Paste the site address from the browser — `https://contoso.sharepoint.com/sites/Finance`. Split into hostname and path on save; both stay editable.
Document library (SharePoint only)	Leave blank for the site’s default library, or paste a drive id from section 5.

Repeat 6b for each drive or library. They all share the one credential.

Narrowing what gets read

Three optional filters, applied to the human-readable path within the drive (Finance/2026/report.docx). They are the second layer of restraint, under the permission grant — use them to keep Enprivacy off material it has no reason to see:

Filter	Effect
Prefix filter	Only items whose path starts with this string.
Include filter	Regular expression; only matching paths are kept.
Exclude filter	Regular expression; matching paths are dropped.

7. Verify

Save the source. Enprivacy runs a health check — it should report ready, with a message naming the resolved drive. The check both resolves the drive and lists it, so a missing admin consent shows up here rather than at the first discovery.
Run a discovery (Find Documents) against the source. It should report the number of objects found.
Open the source’s item list and confirm the files and folder paths look like the drive you intended.

If it does not work

Symptom	Cause
`AADSTS7000215` — invalid client secret	The Secret ID was copied instead of the secret Value, or the secret has expired
`AADSTS700016` — application not found	Wrong client ID, or the registration is in a different tenant from the tenant ID given
`AADSTS1002012` — scope not valid	Enprivacy is on a release predating platform #1680; upgrade
`403` on every call	Admin consent was never granted, or the green tick in API permissions is missing
`403` under `Sites.Selected`	The permission is consented but no `read` role was granted on that particular site (section 3b step 2)
Health check failed, “Default drive not found”	The UPN or site path does not resolve — check for a typo, or a user with no provisioned OneDrive
Health check impaired, network or throttling error	Transient. Graph throttles per application per tenant; Enprivacy waits out `Retry-After` and the next scheduled discovery resumes

8. Testing before you commit a tenant

Two ways to see this working before pointing it at production data.

A sandbox tenant. The Microsoft 365 Developer Program issues an isolated E5 tenant with sample content, which you can configure exactly as above and throw away afterwards. Note that eligibility now requires a Visual Studio Professional or Enterprise subscription, or membership of the ISV Success or Microsoft AI Cloud Partner programmes — it is no longer open to any signup.

A real tenant, narrowly. Where a sandbox is not available, the low-risk shape is a fresh app registration granted Sites.Selected (section 3b) with a read role on a single throwaway SharePoint site holding sample files. Nothing else in the tenant is reachable, and revoking is one Remove-MgSitePermission.

No tenant at all. For engineering work on the connector itself, the Enprivacy repository ships bin/fake-microsoft-graph, which serves a local directory as a drive and speaks enough Graph for the adapter to run against it end-to-end — including refusing an incorrect OAuth scope the way Entra ID does, and injecting throttling responses on demand. That is a developer tool, not a way to validate your tenant’s configuration: it proves the connector works, not that your app registration and consent are correct.

9. Ongoing controls

Revoke all access: In Entra ID → Enterprise applications, find the application and delete it — this invalidates its tokens immediately. Deleting the app registration has the same effect.

Revoke one site (under Sites.Selected): Remove-MgSitePermission for that site. Everything else the app was granted is unaffected.

Rotate the secret: Create a second client secret in Azure, update the one Entra ID credential in Enprivacy (Estate → Credentials) with the new value and expiry, confirm the sources’ health checks still report ready, then delete the old secret in Azure. Every source follows the credential, so this is one edit however many drives you have connected.

Audit what it read: Microsoft Purview Audit (Standard/Premium) records FileAccessed events in SharePoint and OneDrive with the application identity as the actor, so you can review exactly which files this registration has read. Entra ID Sign-in logs → Service principal sign-ins shows each token acquisition.

10. Security checklist

Questions about this configuration can be directed to Enprivacy support at <<INSERT SUPPORT CONTACT>>.