Register Your Own Azure AD App

Connecting a tenant with your own app registration means your security team can see and revoke exactly what BYOVault can access, independent of BYOVault's own app configuration. This is a real Microsoft security boundary — it can't be automated by a link click, since creating a new app registration always requires your admin's own authenticated session.

1. Register the application

  1. Go to the Azure Portal → search App registrations → click + New registration.
  2. Name it anything (e.g. BYOVault) — this can be changed later.
  3. Under Supported account types, choose Single tenant (accounts in this organizational directory only).
  4. Leave Redirect URI completely blank. This app only ever authenticates itself directly (a client-credentials flow) — no user signs into it, so no redirect is needed.
  5. Click Register.

2. Copy the two IDs you'll need

On the app's Overview page, copy:

  • the Application (client) ID
  • the Directory (tenant) ID

You’ll paste both of these into BYOVault’s connect-tenant form later.

3. Add the required API permissions

  1. Left sidebar → API permissionsAdd a permissionMicrosoft Graph.
  2. Choose Application permissions — not Delegated. Delegated permissions require a signed-in user; this app never has one.
  3. Search for and check each of the following, then click Add permissions:
PermissionWhy BYOVault needs it
Sites.Read.AllList SharePoint sites and drives for backup.
Files.Read.AllRead file content from SharePoint/OneDrive for backup.
Files.ReadWrite.AllWrite a file back to its original location when you restore it.
Mail.ReadRead mailbox messages for backup.
Mail.ReadWriteRestore an email back into a mailbox.
User.Read.AllEnumerate mailboxes and users in the tenant.
Write access is real, and it's an application-level grant
The two ReadWrite permissions genuinely allow writing to files and mail across this entire tenant — Microsoft has no way to scope an application permission to “only during a restore.” In practice, BYOVault’s code only calls a write endpoint when an operator explicitly starts a restore for one specific file — it’s never touched during normal backup — but the grant itself is broader than that. Your security team should review this app’s access with that in mind.

4. Grant admin consent

Still on the API permissions page, click Grant admin consent for [your organization] and confirm. Without this step, every permission shows as “Not granted” and nothing will work — this is the step that actually activates them.

5. Generate a client secret

  1. Left sidebar → Certificates & secretsClient secrets tab → New client secret.
  2. Give it a description and an expiry (24 months is reasonable).
  3. Click Add, then immediately copy the Value column. Azure only shows this once — if you navigate away first, you’ll need to generate a new secret.

6. Enter it into BYOVault

Back in BYOVault, on the connect-tenant screen, choose Your Own App Registration and enter your Directory (tenant) ID, Application (client) ID, and the client secret value from above. BYOVault verifies these against Microsoft before creating the tenant — a mistyped value is rejected here, not discovered later at your first backup.