Entra ID Security & Identity

Entra ID Security & Identity

Integration Context Contract

• Canonical contract: docs/integration-context.md

* Use sovereign cloud values from the canonical contract when applicable.

Fail fast before Graph calls when required context is missing or invalid. Redact tenant/object identifiers in all outputs.

Shared Workflow Routing

• Use the shared workflow spec for deterministic multi-plugin routing: workflows/multi-plugin-workflows.md.
• Apply the trigger phrases, handoff contracts, auth prerequisites, validation checkpoints, and stop conditions before escalating to the next plugin.

Microsoft Entra ID Overview

Microsoft Entra ID (formerly Azure Active Directory) is the identity and access management service at the center of the Microsoft cloud ecosystem. It handles authentication, authorization, single sign-on, conditional access, and identity governance for Microsoft 365, Azure, and thousands of SaaS applications.

Key concepts:

• Tenant: A dedicated Entra ID instance for an organization, identified by a tenant ID (GUID) and one or more verified domains.
• Users: Human identities (employees, guests, B2B collaborators).
• Groups: Security groups and Microsoft 365 groups for access management.
• App Registrations: Define applications that use Entra ID for authentication.
• Service Principals: The local representation of an app registration in a tenant. Created automatically when an app is consented to.
• Managed Identities: System-assigned or user-assigned identities for Azure resources (VMs, App Services, Functions) — no credentials to manage.

Microsoft Graph API — Identity Endpoints

Base URL: https://graph.microsoft.com/v1.0

App Registrations

Create app registration body:

{
  "displayName": "My API Backend",
  "signInAudience": "AzureADMyOrg",
  "requiredResourceAccess": [
    {
      "resourceAppId": "00000003-0000-0000-c000-000000000000",
      "resourceAccess": [
        {
          "id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
          "type": "Scope"
        }
      ]
    }
  ],
  "web": {
    "redirectUris": ["https://myapp.com/auth/callback"],
    "implicitGrantSettings": {
      "enableIdTokenIssuance": false,
      "enableAccessTokenIssuance": false
    }
  }
}

Sign-in audiences: AzureADMyOrg (single tenant), AzureADMultipleOrgs (multi-tenant), AzureADandPersonalMicrosoftAccount (multi-tenant + consumer), PersonalMicrosoftAccount (consumer only).

Service Principals

Conditional Access Policies

Conditional access policies enforce access controls based on conditions like user, location, device, and risk level.

Create conditional access policy body:

{
  "displayName": "Require MFA for all users",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "clientAppTypes": ["browser", "mobileAppsAndDesktopClients"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Policy states: enabled, disabled, enabledForReportingButNotEnforced (report-only mode — always start here).

Common grant controls: mfa, compliantDevice, domainJoinedDevice, passwordChange, approvedApplication.

Session controls: Sign-in frequency, persistent browser sessions, app-enforced restrictions, continuous access evaluation.

Sign-In Logs

Useful filters:

GET /auditLogs/signIns?$filter=createdDateTime ge 2026-02-01T00:00:00Z
  and status/errorCode ne 0
  &$top=50
  &$orderby=createdDateTime desc

Key sign-in log fields: userPrincipalName, appDisplayName, ipAddress, location, status.errorCode, status.failureReason, conditionalAccessStatus, riskDetail, riskLevelAggregated.

Risk Detection

Risk levels: none, low, medium, high, hidden.

Risk detection types: anonymizedIPAddress, maliciousIPAddress, unfamiliarFeatures, malwareInfectedIPAddress, suspiciousIPAddress, leakedCredentials, passwordSpray, impossibleTravel.

OAuth2 Permission Grants

Audit and manage delegated permission grants (admin consent and user consent):

Directory Audit Logs

GET /auditLogs/directoryAudits?$filter=activityDisplayName eq 'Add application'
  and activityDateTime ge 2026-02-01T00:00:00Z

Track changes to apps, users, groups, policies, and roles.

Authentication & Scopes

Most of these require application permissions with admin consent for automation scenarios.

Security Best Practices

• App registrations: Prefer certificate credentials over client secrets. Rotate secrets before expiry. Never grant Directory.ReadWrite.All unless absolutely necessary.
• Conditional access: Always deploy new policies in report-only mode first. Use named locations for trusted networks. Require MFA for all admin roles.
• Service principals: Follow least-privilege — grant only the specific API permissions needed. Audit appRoleAssignments regularly.
• Sign-in monitoring: Set up alerts for sign-ins from unusual locations, failed MFA attempts, and legacy auth protocol usage.
• Risk remediation: Configure automatic remediation policies (require MFA or password change) for medium and high risk users.
• Permission audits: Regularly review oauth2PermissionGrants to identify over-permissioned applications and revoke unnecessary grants.

Reference Files

Example Files

Knowledge references

• references/operational-knowledge.md — compact API surface map, prerequisite matrix, deterministic failure remediation, limits/quotas and pagination/throttling guidance, and safe-default read-first/apply-second pattern.

Progressive Disclosure — Reference Files