TigerGate scans your Azure subscription with read-only access via an Azure AD App Registration (service principal). A short az CLI script sets it up.
The service principal only needs the built-in Reader + Security Reader roles — both read-only. TigerGate can never create, modify, or delete resources in your subscription.

Before you start

In TigerGate, open Integrations → Cloud Providers and start a new Microsoft Azure connection. You’ll fill in four values once the service principal exists:
ValueWhat it is
Subscription IDThe Azure subscription TigerGate scans.
Tenant IDYour Azure AD tenant ID.
Client IDThe App Registration’s application (client) ID.
Client SecretA secret generated for the App Registration.

1. Create the service principal

1

Create the App Registration + service principal

az ad sp create-for-rbac \
  --name "tigergate-cspm-scan" \
  --role "Reader" \
  --scopes "/subscriptions/<YOUR_SUBSCRIPTION_ID>" \
  --years 1
The output includes appId (Client ID), password (Client Secret, shown once — save it now), and tenant (Tenant ID). This already assigns Reader; the next step adds Security Reader.
2

Add the Security Reader role

az role assignment create \
  --assignee <APP_ID_FROM_STEP_1> \
  --role "Security Reader" \
  --scope "/subscriptions/<YOUR_SUBSCRIPTION_ID>"
3

Note the Subscription ID

az account show --query id -o tsv
--years 1 sets the client secret to expire in a year. Rotate it before then — generate a new one with az ad app credential reset --id <APP_ID> and update the connection in TigerGate, or the schedule’s next preflight check will fail with an authentication error.

2. Connect it in TigerGate

1

Paste the four values

In Integrations → Cloud Providers, add a Microsoft Azure connection and enter Subscription ID, Tenant ID, Client ID, and Client Secret from step 1.
2

Test

Click Test. TigerGate mints a token from the service principal and does a live Azure Resource Manager subscriptions.get call to confirm the connection works — or tells you the exact Azure AD reason (bad secret, wrong tenant, role not assigned) so you can fix it before saving.
3

Scan or schedule

Run an on-demand scan, or add a Schedule. Schedule creation re-validates the credentials, so a broken secret or a missing role assignment can’t be scheduled.

Multiple subscriptions (Management Group)

To scan every subscription under a Management Group instead of one, scope both role assignments to the Management Group rather than a single subscription:
az role assignment create \
  --assignee <APP_ID> \
  --role "Reader" \
  --scope "/providers/Microsoft.Management/managementGroups/<YOUR_MG_ID>"

az role assignment create \
  --assignee <APP_ID> \
  --role "Security Reader" \
  --scope "/providers/Microsoft.Management/managementGroups/<YOUR_MG_ID>"
The SaaS connection form collects a single Subscription ID. To scan an entire Management Group instead, contact support to set the management group on the account — the scanner then enumerates and scans every subscription under it.

Optional: identity details from Microsoft Graph

The Identities page can show each user’s name, email, job title, department, office location, country, account status, creation date, and last password change. These come from Microsoft Graph and need two application permissions on the same app registration:
PermissionWhat TigerGate reads
User.Read.AllUsers named in role assignments: profile, account status, creation date, last password change
Application.Read.AllService principals and managed identities named in role assignments: name and account status
Both permissions are read-only. Without them, scans run as before and those identities are shown by object ID.
az ad app permission add \
  --id <APP_ID> \
  --api 00000003-0000-0000-c000-000000000000 \
  --api-permissions df021288-bdef-4463-88db-98f22de89214=Role 9a5d68dd-52b0-4cc2-bd40-abcf44ac3a30=Role

az ad app permission admin-consent --id <APP_ID>
00000003-0000-0000-c000-000000000000 is Microsoft Graph; the two =Role IDs are the User.Read.All and Application.Read.All application permissions. In the portal, the same is App registrations → your app → API permissions → Add a permission → Microsoft Graph → Application permissions, then Grant admin consent. Granting consent to application permissions needs an administrator role such as Global Administrator or Privileged Role Administrator.

Alternative auth modes

Self-hosted deployments can use managed identity, Azure CLI (az login) session auth, or interactive browser auth instead of a stored client secret. These paths aren’t exposed in the SaaS dashboard form (service-principal secret is the only supported SaaS path); contact support if you’re running TigerGate on-prem and want to use one of them.

Troubleshooting

Scan/Test errorCauseFix
AADSTS700016 — application not foundWrong Client ID, or app registration deletedRe-check the Client ID; recreate the app registration if it was deleted
AADSTS700038 — invalid client identifierClient ID doesn’t match the tenant, or is malformedRe-check Tenant ID + Client ID are from the same app registration
AADSTS7000215 invalid client secretThe Secret ID (a GUID, shown in the “Secret ID” column) was pasted instead of the Value column — the actual secret string. The Value is only shown once, right after creationGo to Certificates & secrets, generate a new secret, and copy the Value column this time (not Secret ID) — update the connection
AADSTS7000222 invalid/expired client secretThe 1-year expiry passedGenerate a new secret (az ad app credential reset) and update the connection
AuthorizationFailed on the ARM checkReader / Security Reader not assigned at the right scopeRe-run the az role assignment create commands against the exact subscription (or Management Group) ID
Scan runs but few findingsOnly Reader assigned, not Security ReaderAssign both roles (step 2 above)
Identities show object IDs instead of namesThe Microsoft Graph permissions are not granted, or not admin-consentedGrant them as in identity details from Microsoft Graph