Customer Onboarding — Identity Risk Assessments

Option A — Portal (point & click)

1

Register the app. Go to entra.microsoft.com → Applications → App registrations → New registration. Name it identityassess, supported account type: single tenant. Leave redirect URI blank. Register.

2

Add permissions. In the app → API permissions → Add permission → Microsoft Graph → Application permissions → add the 11 permissions in the table below → Add permissions.

3

Grant admin consent. Click Grant admin consent for [your organization] → Yes.

4

Create a secret. Certificates & secrets → New client secret (12 months recommended) → copy the Value immediately — shown once.

5

Collect the IDs. Tenant ID (Entra Overview) and Application (client) ID (app Overview). Send the three values to the platform team over a secure channel.

Option B — CLI automation (recommended)

Requires the Azure CLI.

# Log in (opens a browser)
az login

# Run the automated setup
.\scripts\setup-entra-app.ps1 -AppName "identityassess" -SecretYears 1

The script creates the app, adds all permissions, grants admin consent, creates the secret, and saves the three values to entra-credentials.txt (file locked to your user).

⚠️ The consent step needs Global Administrator or Privileged Role Administrator. If your account lacks it, the script prints the exact command for an admin to run.

Manual CLI (reference)

GRAPH="00000003-0000-0000-c000-000000000000"   # Microsoft Graph resource id

APP_ID=$(az ad app create --display-name "identityassess" --sign-in-audience AzureADMyOrg --query appId -o tsv)

az ad app permission add --id "$APP_ID" --api "$GRAPH" --api-permissions \
  "User.Read.All=Role" "Reports.Read.All=Role" "AuditLog.Read.All=Role" \
  "IdentityRiskyUser.Read.All=Role" "IdentityRiskyServicePrincipal.Read.All=Role" \
  "Policy.Read.All=Role" "Policy.Read.PermissionGrant=Role" \
  "RoleManagement.Read.Directory=Role" "Application.Read.All=Role" \
  "Device.Read.All=Role" "Directory.Read.All=Role"

az ad app permission admin-consent --id "$APP_ID"

SECRET=$(az ad app credential reset --id "$APP_ID" --display-name "identityassess" --years 1 --query password -o tsv)

echo "ENTRA_TENANT_ID=$(az account show --query tenantId -o tsv)"
echo "ENTRA_CLIENT_ID=$APP_ID"
echo "ENTRA_CLIENT_SECRET=$SECRET"

Permissions (all read-only)

Permission	What it enables
`User.Read.All`	User inventory, dormant-account detection
`Reports.Read.All`	MFA / authentication-method coverage
`AuditLog.Read.All`	Sign-in logs, admin activity, MFA registration
`IdentityRiskyUser.Read.All`	Risky users (P2/E5)
`IdentityRiskyServicePrincipal.Read.All`	Risky sign-ins / service principals (P2/E5)
`Policy.Read.All`	Conditional Access, security defaults
`Policy.Read.PermissionGrant`	User-consent policies
`RoleManagement.Read.Directory`	Privileged roles, PIM
`Application.Read.All`	Service principals, app owners, grants
`Device.Read.All`	Device compliance
`Directory.Read.All`	Tenant & directory data

Licenses: risk signals (risky users/sign-ins/service principals) and PIM require Entra ID P2 / E5; dormant-account detection requires P1 or P2. The connector degrades gracefully on free/cloud-only tenants.

Send these back to the platform team

ENTRA_TENANT_ID=<tenant-id>
ENTRA_CLIENT_ID=<client-id>
ENTRA_CLIENT_SECRET=<secret-value>

Security notes

Least privilege: permissions are read-only. Policy.Read.PermissionGrant and IdentityRiskyServicePrincipal.Read.All can be omitted to minimize further (fewer signals).
Rotate secrets at least annually; update the value in the console — no re-registration needed.
Monitor: see connector activity in Entra → Monitoring → Sign-in logs (service principal sign-ins).
Revoke: delete the app registration (or its secret) in Entra to disconnect immediately.