TATER 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:
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. |
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.AllDeviceManagementManagedDevices.Read.AllDeviceManagementServiceConfig.Read.All
Intune management (Ops → Intune, and the MCP tools)
The scanning permissions above are not sufficient for the Intune management surface — reading an app's detection rules, changing them, listing or changing its assignments, and creating or assigning Proactive Remediations and Platform Scripts. Those sit behind different Graph scopes, and a tenant consented for one is not consented for the other.
| Permission | Needed for | Write? |
|---|---|---|
DeviceManagementApps.Read.All |
list_intune_apps, get_intune_app,
get_intune_app_status, list_intune_app_assignments.
(DeviceManagementConfiguration.Read.All also satisfies the read side.) |
No |
DeviceManagementApps.ReadWrite.All |
update_intune_app_rules, set_intune_app_assignment
— correcting a detection rule, and adding / re-intenting / removing an
app assignment (i.e. stopping a failing deployment). |
Yes |
DeviceManagementScripts.Read.All |
list_intune_remediations, get_intune_remediation,
list_intune_platform_scripts, get_intune_platform_script,
get_intune_assignments. |
No |
DeviceManagementScripts.ReadWrite.All |
create_intune_remediation, assign_intune_remediation,
create_intune_platform_script, assign_intune_platform_script,
create_intune_mac_script, assign_intune_mac_script. |
Yes |
DeviceManagementApps.ReadWrite.All allows creating and modifying Win32
app deployment definitions — including install command lines —
and targeting them at devices. DeviceManagementScripts.ReadWrite.All allows
creating and assigning PowerShell that runs as SYSTEM. In practice each is
code execution across every managed endpoint in the tenant. TATER's own
NHI classifier flags both as high-privilege for exactly that reason, so grant them
deliberately, and only to a tenant where you intend to manage Intune rather
than only audit it.
Neither is part of the read-only audit profile, and neither should be granted for an advisory engagement — see Read-only audit.
The Intune tools authenticate as the organization's general-purpose tenant
credential — the Client ID stored under Settings → Tenant IDs
for the target tenant (Cosmos document tcred-<targetTenantId>). That is the
same scanner app registration the M365 scan uses.
It is not a purpose-scoped credential. Departure Watch deliberately uses a
separate, dedicated registration (tcred-<targetTenantId>-departure-watch) so an
Exchange ApplicationAccessPolicy can fence it — an AAP scopes the whole application, so it
is only a control on a single-purpose app. The Intune tools do not use that resolver, so adding
an Intune permission to the Departure Watch app has no effect.
Do NOT add these to the TATER sign-in app. TATER-SecurityCompliance
(45afb90d-c5de-439d-8b09-8fbfed28b321) is the multi-tenant app your users
authenticate with — it is the JWT audience the API validates, and it declares only
User.Read and User.Read.All. Adding a scanner or Intune permission
there would put it into the consent prompt every tenant sees to enable login, and
would still grant scanning nothing, because scanning authenticates as the per-tenant
credential instead. The two app registrations are not interchangeable.
To confirm which Client ID a tenant is actually using, open Settings → Tenants and use the Permissions check — it reads the stored credential's granted application permissions live.
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 |
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.AllAuditLog.Read.All,Reports.Read.All,User.Read.All,Group.Read.All,Organization.Read.AllUserAuthenticationMethod.Read.All,IdentityRiskyUser.Read.All,IdentityRiskyServicePrincipal.Read.AllPrivilegedAccess.Read.AzureAD,PrivilegedAccess.Read.AzureADGroup,SecurityEvents.Read.AllInformationProtectionPolicy.Read.All,IdentityProvider.Read.All,AccessReview.Read.All,TeamsAppInstallation.ReadForUser.AllDeviceManagementConfiguration.Read.All,DeviceManagementManagedDevices.Read.All,DeviceManagementServiceConfig.Read.All,DeviceManagementApps.Read.All
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
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.