Azure Registered Apps

Configure Entra ID app registrations for Graph API-based compliance scanning. Required for both server-side scans and Azure Automation runbooks.

Overview

TATER requires an Entra ID app registration to authenticate to Microsoft Graph API and other M365 services. The app registration provides the identity that runbooks and the API use to scan your tenant.

Creating the App Registration

Navigate to Entra ID

Go to the Microsoft Entra admin center and select Applications > App registrations > New registration.

Configure registration

Name: "TATER Compliance Scanner". Supported account types: "Accounts in this organizational directory only". No redirect URI needed for app-only auth.

Note the IDs

Record the Application (client) ID and Directory (tenant) ID from the Overview page. You will need these for TATER configuration.

Create a certificate or secret

Under Certificates & secrets, upload a certificate (recommended) or create a client secret. Store securely in Azure Key Vault.

Microsoft Graph API Permissions

Add the following Application permissions (not delegated) under API permissions:

Validated against real scan data

The full permission list below has been validated against a live M365 tenant scan. All permissions are required for complete coverage. Missing any of these will cause controls to error rather than return a result.

Permission	Purpose
`User.Read.All`	Read user profiles and settings
`Group.Read.All`	Read group memberships
`Directory.Read.All`	Read directory data
`Policy.Read.All`	Read security and compliance policies
`Reports.Read.All`	Read usage and compliance reports
`AuditLog.Read.All`	Read audit log data
`RoleManagement.Read.Directory`	Read directory role assignments
`RoleManagement.Read.All`	Read PIM role settings and eligibility schedules
`PrivilegedAccess.Read.AzureAD`	Read PIM eligible role assignments
`PrivilegedAccess.Read.AzureADGroup`	Read PIM group assignment schedules
`IdentityRiskyUser.Read.All`	Read users flagged as at risk
`IdentityRiskyServicePrincipal.Read.All`	Read risky service principal information
`UserAuthenticationMethod.Read.All`	Read MFA/FIDO2/Authenticator registration status
`SecurityEvents.Read.All`	Read security alerts and incidents
`InformationProtectionPolicy.Read.All`	Read sensitivity labels and DLP policies
`IdentityProvider.Read.All`	Read identity providers configuration
`TeamsAppInstallation.ReadForUser.All`	Read Teams app installation policies
`Organization.Read.All`	Read organization settings
`AttackSimulation.Read.All`	Read Microsoft Attack Simulation Training (phishing) results — required for the Training page Sync M365 Phishing reader (Defender for Office 365 P2 / Microsoft 365 E5). Optional; only needed if you use that feature.

Admin consent required

After adding permissions, click Grant admin consent for your organization. This requires Global Administrator or Privileged Role Administrator.

Intune Permissions

For endpoint scanning via Intune, add these Application permissions:

DeviceManagementConfiguration.Read.All
DeviceManagementManagedDevices.Read.All
DeviceManagementServiceConfig.Read.All

Defender for Endpoint Permissions

For the Scan-Endpoints runbook, add permissions under the WindowsDefenderATP API:

Permission	Purpose
`Machine.Read.All`	Device inventory
`Vulnerability.Read.All`	CVE data
`Software.Read.All`	Software inventory

Separate token

MDE uses a separate API endpoint (api.securitycenter.microsoft.com) requiring its own OAuth token. The Graph API token cannot be reused for MDE.

Exchange Online Permissions

The Exchange.ManageAsApp permission cannot be assigned via the Entra portal UI. Use PowerShell:

# Connect to Exchange Online
Connect-ExchangeOnline

# Assign Exchange.ManageAsApp to the app's service principal
$appId = "your-client-id"
$sp = Get-ServicePrincipal -Identity $appId
New-ManagementRoleAssignment -App $sp.ObjectId -Role "Exchange Administrator"

Read-Only Audit Mode (Least-Privilege)

For advisory / consultant engagements where you audit a client tenant but must never hold write access, grant only the read-only subset. This is the full scanner permission set minus the two write-capable roles — Sites.FullControl.All (SharePoint admin) and Exchange.ManageAsApp — leaving every pure *.Read.* Microsoft Graph scope:

Directory.Read.All, Policy.Read.All, RoleManagement.Read.Directory, RoleManagement.Read.All
AuditLog.Read.All, Reports.Read.All, User.Read.All, Group.Read.All, Organization.Read.All
UserAuthenticationMethod.Read.All, IdentityRiskyUser.Read.All, IdentityRiskyServicePrincipal.Read.All
PrivilegedAccess.Read.AzureAD, PrivilegedAccess.Read.AzureADGroup, SecurityEvents.Read.All
InformationProtectionPolicy.Read.All, IdentityProvider.Read.All, AccessReview.Read.All, TeamsAppInstallation.ReadForUser.All
DeviceManagementConfiguration.Read.All, DeviceManagementManagedDevices.Read.All, DeviceManagementServiceConfig.Read.All, DeviceManagementApps.Read.All

How to grant it

Consent to only the scopes above (omit the two write-capable roles), then in TATER → Settings → Remediation enable Read-only audit mode for the engagement's organization. TATER then hides every remediation control and the API rejects any remediation trigger — so even a stale client or a direct API call cannot make a change. You can validate exactly which scopes are granted via the live Permissions check (see below), or fetch the machine-readable read-only set from GET /api/scanner-permissions?profile=read-only-audit.

Scanning is inherently read-only, and every control fails safe to Manual when a permission is missing — so a read-only grant still produces a complete findings report for everything reachable through Graph reads. Controls that require the omitted SharePoint-admin or app-only Exchange roles (deep SPO/EXO configuration) simply report Manual rather than a false pass or fail.

Certificate Authentication

Certificate-based authentication is recommended for production:

Generate a self-signed certificate or obtain one from your CA
Upload the public key (.cer) to the app registration under Certificates & secrets
Store the private key (.pfx) in Azure Key Vault
Configure the Automation Account to retrieve the certificate at runtime

Key Vault

Install the certificate into CurrentUser\My store with UserKeySet + PersistKeySet + Exportable storage flags for services that use CertificateThumbprint.

Validating & Updating Permissions (Existing Tenants)

When TATER adds a capability that needs a new Microsoft 365 permission (for example DeviceManagementApps.Read.All for the Intune app-protection checks), already-connected tenants can fall behind. In TATER Security → Settings → Tenants, click Permissions on any connected tenant to validate it live: TATER uses the stored app credentials to read the scanner app's actually-granted application permissions and shows, per permission, whether it is ✓ granted or ✗ missing against the current required set — grouped by API, with newly-added permissions flagged NEW.

Add a missing permission — the modal links straight to the app registration's API permissions page in the Azure portal. Add the permission (Application type) and click Grant admin consent, or use the provided consent link, then re-check.
Remove a permission — revoke it on that same Azure portal page. TATER reads your app registration but never modifies it, so removals stay under your control (least privilege).

Live validation requires the tenant's scanner Client ID & Secret to be stored in TATER (Edit → Directory Search Credentials). Tenants connected only via multi-tenant sign-in consent have no stored secret to read with — add credentials to validate.