AZ-500 Objective 1.2: Manage Microsoft Entra Application Access

 • 42 min read • Microsoft Azure Security Technologies

Share:

AZ-500 Exam Focus: This objective covers Microsoft Entra ID (Azure AD) application access management including enterprise applications with OAuth permission grants, app registrations defining application identity and API permissions, permission scopes (delegated vs application permissions), consent management (admin consent vs user consent), service principals providing application identity with client secrets or certificates, and managed identities eliminating credential management for Azure resources. Understanding OAuth 2.0 flows and when to use managed identities vs service principals is essential for the exam.

Understanding Application Identity in Microsoft Entra ID

Modern applications rarely operate in isolation—they integrate with cloud services, access APIs, call other applications, and manage user data across platforms. This interconnected ecosystem requires robust identity and access management not just for users but for applications themselves. Microsoft Entra ID (formerly Azure Active Directory) provides comprehensive application identity management enabling secure integration while maintaining control over what applications can access. Application identity in Entra ID operates through several interrelated concepts: app registrations defining what applications are and what they can do, enterprise applications representing application instances in your tenant, service principals providing actual identity for authentication, and permissions governing access to resources and APIs.

Security challenges in application access include credential management for applications accessing resources (storing secrets securely, rotating regularly, preventing exposure in code), permission management (granting appropriate access without over-privileging, obtaining user consent for personal data, providing admin oversight for sensitive permissions), and compliance requirements (auditing application access, controlling third-party applications, ensuring data residency compliance). Microsoft Entra ID addresses these challenges through OAuth 2.0 and OpenID Connect standard protocols, granular permission scopes enabling fine-grained access control, managed identities eliminating credentials entirely for Azure resources, admin consent providing organizational oversight, and comprehensive auditing tracking all application access. This objective explores these capabilities enabling you to securely manage application access while following principles of least privilege and zero trust security.

Enterprise Applications and OAuth Permissions

Understanding Enterprise Applications

Enterprise applications in Microsoft Entra ID represent all applications that can authenticate and access resources in your tenant. This includes applications you develop and register in your tenant, third-party SaaS applications like Salesforce or ServiceNow that integrate with your directory, Microsoft applications like Office 365 and Dynamics 365, and multi-tenant applications created by other organizations that users in your tenant access. When you navigate to Azure Active Directory → Enterprise applications, you see complete inventory of applications with access to your tenant's resources. Each enterprise application is actually a service principal—the local instance of an application in your tenant containing tenant-specific configuration like assigned users and groups, granted permissions, single sign-on configuration, provisioning settings, and activity logs.

Enterprise applications differ from app registrations—app registration is blueprint defining application's identity and capabilities existing in home tenant where application was created; enterprise application is instance of that application in any tenant where it's used. For single-tenant applications you develop, app registration and enterprise application exist in same tenant. For multi-tenant applications, app registration exists in publisher's tenant while enterprise applications are created in each customer tenant when first user or admin consents. Managing enterprise applications involves assigning users and groups controlling who can access application, configuring single sign-on enabling passwordless authentication, managing consented permissions reviewing what access has been granted, setting up provisioning automating user account creation, reviewing sign-in activity monitoring who accesses application, and configuring app proxy enabling secure remote access to on-premises applications.

OAuth 2.0 Permission Grants

OAuth 2.0 is authorization framework enabling applications to access resources on behalf of users without exposing passwords. Microsoft Entra ID implements OAuth 2.0 as authorization server issuing access tokens to applications after successful authentication and authorization. OAuth permission grants record consent given to application for accessing resources. When user or admin consents to application, permission grant is created in directory recording user who consented, application that received permissions, resources being accessed (like Microsoft Graph), and specific permissions granted (like User.Read, Mail.Send). View permission grants under Enterprise applications → [Your app] → Permissions showing user consent and admin consent separately.

OAuth 2.0 flows (grant types) determine how applications obtain access tokens: Authorization code flow used by web applications—user authenticates at Azure AD, receives authorization code, application exchanges code for access token using client secret, access token used to call APIs; most secure flow separating user authentication from token acquisition. Implicit flow (legacy, deprecated) used by single-page applications—tokens returned directly to browser; less secure, replaced by authorization code with PKCE. Client credentials flow used by background services—application authenticates with secret or certificate, receives token without user interaction; uses application permissions. Device code flow used by devices without web browsers—shows code to user, user enters code on another device, device receives tokens. Authorization code with PKCE (Proof Key for Code Exchange) used by mobile and native apps—adds protection against code interception; required for public clients. Understanding these flows critical for selecting appropriate authentication pattern for your application type and security requirements.

App Registrations and Configuration

Creating and Configuring App Registrations

App registration establishes application's identity in Microsoft Entra ID serving as blueprint for application. Create through Azure portal: Azure Active Directory → App registrations → New registration. Provide Name (displayed to users in consent prompts and sign-in pages), Supported account types determining who can use application—single tenant (your organization only), multi-tenant (any Azure AD tenant), multi-tenant plus personal Microsoft accounts, personal Microsoft accounts only. Choose based on application's intended audience: line-of-business apps typically single tenant, commercial SaaS applications multi-tenant, consumer applications include personal accounts. Configure Redirect URI where Azure AD sends authentication responses—web apps use https:// URLs, mobile/native apps use platform-specific URIs, SPAs use http://localhost for development.

After registration, configure application through several sections: Authentication settings including redirect URIs, logout URL, implicit grant settings (only if legacy app requires), ID token inclusion preferences, supported account types (can be changed), and API permissions for OAuth 2.0. Certificates & secrets containing client secrets (passwords) and certificate public keys for authentication. Token configuration customizing claims included in tokens, adding optional claims, accepting mapped claims. API permissions (covered in detail below) defining what resources application can access. Expose an API (if building API) defining scopes for other applications to request. App roles defining application-specific roles for users and applications. Manifest containing JSON representation of application object enabling advanced configurations. Branding customizing logo, terms of service, and privacy statement shown to users. Application object properties include Application (client) ID (unique identifier for your app), Directory (tenant) ID (your Azure AD tenant identifier), Object ID (unique identifier for application object), and API Application ID URI (identifier for API if exposing). These values used in code for authentication and authorization.

Managing App Registration Lifecycle

Application lifecycle management ensures security and compliance throughout application's existence. Registration phase: document application purpose and owner, assign appropriate account type (single vs multi-tenant), configure minimal necessary redirect URIs, and obtain security team approval for sensitive permissions. Development phase: use separate app registrations for dev/test/production, rotate secrets regularly during development, test consent flow with real users, and implement proper error handling for authorization failures. Production deployment: remove development redirect URIs, ensure secrets stored in Key Vault, configure certificate authentication for higher security, document application dependencies, and implement monitoring for application health and security. Ongoing maintenance: Review and rotate credentials before expiration (secrets every 90 days, certificates annually), audit permissions removing unused access, monitor application sign-ins identifying anomalies, respond to security advisories affecting dependencies, and maintain up-to-date documentation. Decommissioning: Remove all credentials preventing further access, delete app registration if no longer needed, document decommissioning for compliance, and notify users about application end-of-life. Security considerations: Secrets must never be in source code or configuration files, use environment variables or Key Vault, implement credential rotation procedures, monitor app registration changes with Azure AD audit logs, and restrict who can register applications using Azure AD policies.

Permission Scopes and Consent

Delegated vs Application Permissions

Microsoft Entra ID uses two permission types: delegated and application. Delegated permissions used when application acts on behalf of signed-in user—application accesses resources as the user, constrained by intersection of user's permissions and app's permissions. If user can't read email, app with Mail.Read permission still can't read that user's email. Delegated permissions require user to be present and signed in. Common scenarios: web application displaying user's calendar, mobile app sending email on user's behalf, SPA reading user's OneDrive files. User or admin must consent to delegated permissions. Examples: User.Read (read signed-in user profile), Mail.Send (send mail as user), Files.ReadWrite (access user's files), Calendars.ReadWrite (manage user's calendar). Delegated permissions appropriate when application augments user's capabilities or accesses user's personal data with user's knowledge and consent.

Application permissions used when application runs without signed-in user, acting with its own identity. Application has permissions regardless of who triggered action or whether any user is signed-in. Application permissions typically more powerful and broad, always require admin consent. Common scenarios: Background service synchronizing data between systems, daemon process monitoring and alerting, scheduled job processing overnight, server-to-server integration without user context. Examples: User.Read.All (read all users in directory), Mail.Read.All (read all mailboxes), Sites.ReadWrite.All (manage all SharePoint sites), Directory.ReadWrite.All (read/write directory data). Application permissions appropriate for automated operations, administrative tasks, and system integrations. Security implications significant—compromised app with Mail.Read.All can access all organizational email. Best practices: Use delegated when possible preserving user context, request application permissions only when truly needed, document justification for each application permission, implement additional authorization in application code (don't rely solely on Azure AD permissions), audit usage of application permissions regularly, and consider using managed identities eliminating credential exposure for Azure resource access.

User Consent vs Admin Consent

Consent is process where user or administrator grants permissions to application. User consent occurs when individual user approves permissions for themselves—user signs into application, sees consent prompt listing requested permissions, approves or denies, consent applies only to that user. User consent appropriate for low-risk delegated permissions accessing only user's own data (User.Read, User.ReadBasic.All, Mail.Send). Organizations can disable user consent requiring admin approval for all applications. Admin consent grants permissions on behalf of entire organization—administrator reviews and approves permissions, all users can access application without seeing consent prompt, admin consent required for all application permissions and high-privilege delegated permissions. Admin consent prompt appears when administrator signs in to application or when admin explicitly grants consent through portal.

Grant admin consent through Azure portal: App registrations → API permissions → Grant admin consent for [tenant]; or Enterprise applications → Permissions → Review permissions and consent. After admin consent, Enterprise application shows consented permissions with "Granted for [tenant]" indicator. Consent policies control what users can consent to: Configure through Azure AD → Enterprise applications → Consent and permissions → User consent settings. Options include Do not allow user consent (require admin for everything), Allow user consent for apps from verified publishers for selected permissions (balanced approach), Allow user consent for all apps (highest risk). Implement app consent policies defining conditions for user consent—can restrict based on publisher verification, risk-based assessment, and permission sensitivity. Best practices: Enable user consent only for verified publishers reducing risk, define clear consent policies aligned with security requirements, educate users about reviewing permission requests, implement audit process for admin consent decisions, document why each permission needed for compliance, and regularly review consented permissions removing unused access.

Service Principals

Service Principal Types and Usage

Service principal is security identity used by applications and services to access specific Azure resources and APIs. Three types exist: Application service principal created when you register application in your tenant—represents your application enabling it to authenticate and access resources. Managed identity service principal created automatically when you enable managed identity on Azure resource—Azure handles credential lifecycle completely. Legacy service principal for older applications created before app registrations model. Application service principals most common—every app registration automatically creates corresponding service principal in home tenant. Service principal contains Application ID referencing app registration, Tenant ID where service principal exists, Object ID unique within tenant, Service principal names for identification, Credentials (secrets or certificates) for authentication, and Permissions through role assignments and API permissions.

Create service principals using Azure portal (automatic with app registration), PowerShell (New-AzADServicePrincipal), Azure CLI (az ad sp create-for-rbac creates service principal with role assignment), or Microsoft Graph API. Common use cases: CI/CD pipelines authenticating to deploy Azure resources, applications accessing Key Vault to retrieve secrets, automation scripts managing Azure resources, third-party applications integrating with your environment, and service-to-service authentication in microservices. Authentication methods: Client secret (password)—simple but must be rotated, can expire (max 2 years), stored in Key Vault not code. Certificate—more secure, supports hardware security modules, preferred for production. Federated credentials—no stored secret, external identity provider issues token, app exchanges for Azure AD token, ideal for GitHub Actions, AWS, Google Cloud integration.

Service Principal Security

Service principal security critical since they often have elevated permissions. Credential management: Store secrets in Azure Key Vault with access policies restricting retrieval, rotate secrets every 90 days using automation, set secret expiration dates forcing rotation, monitor approaching expirations with Azure Monitor alerts, and test new secrets before removing old. Prefer certificates over secrets for production—store private keys in Key Vault, use RSA 2048-bit minimum, enable certificate auto-rotation where supported, and maintain certificate inventory for renewal tracking. Federated credentials ideal when possible—GitHub Actions can authenticate without storing secrets by trusting OIDC tokens from GitHub, AWS workloads authenticate using OIDC federation, no credential storage or rotation needed. Permission management: Assign least-privilege roles using Azure RBAC, scope permissions appropriately (resource group vs subscription), separate service principals by environment, document permission justification, and audit permissions quarterly.

Monitoring and auditing: Review service principal sign-in logs identifying unusual patterns, monitor API calls tracking resource access, alert on failed authentication attempts indicating attack or misconfiguration, audit permission changes tracking grants and revocations, and implement Conditional Access for workload identities (now supported) requiring specific locations or conditions. Service principal lifecycle: Create with minimal permissions initially, document purpose and owner maintaining inventory, assign permissions incrementally as needed, remove when application decommissioned, and maintain backup credentials for emergency access. Security hardening: Restrict service principal creation to authorized admins using Azure AD policies, require approval for high-privilege service principals through governance process, implement separation of duties where no single person has full control, use privileged access workstations for credential management, and conduct regular security reviews identifying over-privileged or unused service principals. Incident response: Document procedure for compromised credentials, maintain emergency contact list, test credential rotation procedures, and prepare communication plan for affected applications.

Managed Identities

System-Assigned vs User-Assigned Managed Identities

Managed identities eliminate credential management providing Azure services with automatically managed identity in Azure AD. System-assigned managed identity tied to single Azure resource—lifecycle bound to resource (identity created when you enable it, deleted when resource deleted), unique per resource, cannot be shared across resources. Use when identity purpose-built for single resource: VM accessing Key Vault, App Service connecting to SQL Database, Function App reading from Storage. Enable through resource properties (portal, CLI, PowerShell, ARM template), Azure creates service principal automatically, assign permissions through Azure RBAC or API permissions, resource authenticates automatically using Azure Instance Metadata Service (IMDS). Benefits: Simple setup with one-click enablement, automatic cleanup when resource deleted, no credential management, and dedicated identity per resource providing isolation.

User-assigned managed identity created as standalone Azure resource, can be assigned to multiple resources, persists independently of resource lifecycle, managed separately from compute resources. Use when multiple resources need same identity: Multiple VMs in scale set sharing access to resources, identity surviving resource replacement, complex permission management across resources. Create user-assigned identity as Azure resource in resource group, assign to one or more resources, grant permissions to identity, resources authenticate using that identity. Benefits: Share identity across resources reducing redundancy, identity persists through resource recreation, centralized permission management, and planned lifecycle independent of compute. Choose system-assigned when identity dedicated to single resource with matching lifecycle; choose user-assigned when sharing identity, when resource frequently recreated, or when managing identity lifecycle separately from compute.

Using Managed Identities

Implement managed identities in applications using Azure SDK. For .NET: var credential = new DefaultAzureCredential(); automatically uses managed identity when running on Azure. For Python: credential = DefaultAzureCredential(). For JavaScript: const credential = new DefaultAzureCredential();. DefaultAzureCredential automatically detects environment—uses managed identity on Azure resources, uses Azure CLI credentials locally for development, supports multiple authentication methods in priority order. Access Azure resources: Key Vault: var client = new SecretClient(vaultUri, credential);, Storage: var blobClient = new BlobClient(blobUri, credential);, SQL Database: Connection string with Authentication=Active Directory Managed Identity. Call Microsoft Graph: Obtain token for Graph API scope, use token in HTTP requests, or use Graph SDK with credential.

Grant permissions to managed identities: For Azure resources, assign Azure RBAC roles—navigate to resource, Access Control (IAM), Add role assignment, select Managed Identity principal, choose your managed identity. For Microsoft Graph API, use PowerShell (requires Microsoft.Graph module): Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All, get service principal: $sp = Get-MgServicePrincipal -Filter "displayName eq 'your-identity-name'", grant permission: New-MgServicePrincipalAppRoleAssignment. Supported scenarios: VMs and Scale Sets accessing Key Vault, Storage, SQL; App Service and Functions calling APIs; Azure Kubernetes Service with workload identity; Container Instances accessing resources; Logic Apps connecting to services; Data Factory accessing data sources. Best practices: Use managed identities instead of service principals whenever possible, prefer system-assigned for single-resource scenarios, use user-assigned for complex permission requirements, assign least-privilege permissions, document which identities access which resources, audit managed identity usage, and test managed identity locally using Azure CLI or Visual Studio authentication.

Real-World Application Access Scenarios

Scenario 1: Multi-Tenant SaaS Application

Business Requirement: Software company developing customer relationship management (CRM) SaaS application needs to enable customers to sign in with their organizational accounts (Azure AD), access their organizational data (email, calendar, contacts through Microsoft Graph), and synchronize data between CRM and Office 365 while maintaining security and compliance.

Azure Solution: Multi-Tenant App Registration with Delegated Permissions

  • App Registration: Create multi-tenant app registration in publisher tenant (Azure AD → App registrations → New registration → Accounts in any organizational directory). Configure redirect URIs for web application (https://app.company.com/signin-oidc). Define application ID URI (api://crm.company.com) for exposing API to future integrations. Upload company logo and configure branding for professional consent experience.
  • API Permissions: Add Microsoft Graph delegated permissions: User.Read (read user profile - low sensitivity, user consentable), Mail.Read (read user email - medium sensitivity, requires admin consent in many organizations), Calendars.ReadWrite (manage calendar - medium sensitivity), Contacts.ReadWrite (manage contacts - medium sensitivity), Presence.Read (read user availability for showing online status). Request only permissions needed avoiding over-privileging. Document each permission's purpose for customers reviewing access.
  • Consent Flow: First-time customer setup: Customer admin signs into application, Azure AD shows admin consent prompt listing all permissions with descriptions, admin reviews and grants consent for organization, consent creates service principal in customer tenant, all customer users can now sign in without individual consent prompts. If customer disables admin consent requirement, users see consent prompt on first sign-in approving permissions for themselves only (low-risk permissions only).
  • Authentication Implementation: Use authorization code flow with PKCE for security: User clicks sign-in button, app redirects to Azure AD authorization endpoint with client_id, redirect_uri, scope, state (CSRF protection), code_challenge (PKCE); Azure AD authenticates user showing consent if needed; Azure AD redirects to app with authorization code; App exchanges code for access token POST to token endpoint with code, redirect_uri, client_secret, code_verifier; App receives access token (for API calls) and refresh token (for obtaining new access tokens); App stores refresh token encrypted, uses access token to call Microsoft Graph.
  • Token Management: Access tokens short-lived (1 hour) reducing compromise risk, refresh tokens long-lived enabling background operations, implement token caching avoiding unnecessary roundtrips, handle token expiration gracefully refreshing automatically, validate tokens on server side (signature, expiration, audience, issuer), implement token revocation for logout, and use continuous access evaluation for real-time revocation when user or admin revokes access.
  • Admin Portal: Provide customer admin portal showing which permissions application has, which users accessed application, when application last accessed data, and option to revoke access. Enable customers to monitor application usage for compliance. Implement webhooks for change notifications enabling real-time sync without polling (reduces API calls and improves performance).
  • Security Measures: Store client secret in Azure Key Vault not in configuration, rotate secret before expiration with zero downtime using multiple active secrets, implement certificate authentication for higher security in production, log all authentication attempts and API calls for security monitoring, implement rate limiting preventing API abuse, validate all Microsoft Graph responses don't trust data implicitly, and use Microsoft Identity Web library simplifying secure implementation.
  • Compliance: Document data access in privacy policy explaining what data accessed and why, implement data residency ensuring data stays in customer region, support customer data export for GDPR compliance, enable application to be removed from customer tenant when contract ends, and maintain security certifications (SOC 2, ISO 27001) required by enterprise customers.

Outcome: Secure multi-tenant SaaS application enabling seamless single sign-on for customer users, controlled access to organizational data through granular permissions, professional consent experience building customer trust, and compliance with enterprise security requirements enabling sales to large organizations. Zero security incidents related to OAuth implementation in 18 months post-launch.

Scenario 2: CI/CD Pipeline with Service Principal

Business Requirement: DevOps team needs automated CI/CD pipeline deploying web applications and infrastructure to Azure from GitHub Actions without storing credentials in repository, with separate pipelines for dev, staging, and production environments having appropriate permissions for each.

Azure Solution: Federated Credentials with GitHub Actions

  • App Registration: Create app registration for CI/CD automation (name: "GitHub-Actions-CD"). Configure as single-tenant (no external access needed). No redirect URIs required (service-to-service only). Add federated credential instead of client secret: Credential scenario "GitHub Actions deploying Azure resources", Organization name, Repository name, Entity type "branch", Branch name "main", Credential name "production-deployment". Add separate federated credentials for dev and staging branches.
  • Service Principal Permissions: Create three resource groups: RG-Dev, RG-Staging, RG-Production. Create three service principals (one per environment or use branches with single service principal). Production: Assign Contributor role at RG-Production scope (can deploy resources but not modify permissions). Assign Reader role at subscription level (can check resource status). Staging: Contributor at RG-Staging. Dev: Contributor at RG-Dev plus ability to create new resource groups. Implement least privilege—production pipeline cannot modify dev/staging, dev pipeline cannot access production.
  • GitHub Actions Workflow: Configure GitHub repository with Azure credentials (client ID, tenant ID, subscription ID—no secrets!). Workflow authenticates using OIDC: GitHub Actions generates token proving workflow identity, workflow exchanges GitHub token for Azure AD access token using federated credential trust, access token used to deploy resources. Authentication code: az login --service-principal -u $CLIENT_ID --tenant $TENANT_ID --federated-token $GITHUB_TOKEN. No credentials stored in GitHub secrets, repository, or configuration.
  • Pipeline Stages: Build: Compile application, run tests, create artifacts. Dev deployment: Automatic on every commit to develop branch, deploys to RG-Dev, runs integration tests, sends Slack notification on failure. Staging deployment: Automatic on pull request to main, deploys to RG-Staging, runs smoke tests, requires QA approval before merge. Production deployment: Manual approval required after merge to main, deploys to RG-Production, implements blue-green deployment for zero downtime, runs production health checks, automatic rollback on failure.
  • Security Controls: Separate credentials per environment preventing cross-environment access, federated credentials tied to specific branches preventing unauthorized deployments, GitHub environment protection rules requiring approvals for production, audit logging all deployments to Azure Monitor, automated security scanning in pipeline detecting vulnerabilities before deployment, and secrets stored in Azure Key Vault referenced during deployment (never in source control).
  • Monitoring: Service principal sign-in logs showing all pipeline authentications, Azure Activity Log tracking all resource deployments and changes, GitHub Actions logs recording pipeline execution, Azure Monitor alerts on deployment failures, and weekly reports to engineering leadership on deployment frequency and success rate.
  • Credential Rotation: Federated credentials don't expire but trust relationship should be reviewed quarterly, document emergency procedure for revoking access if GitHub account compromised, maintain backup authentication method (certificate stored offline) for disaster recovery, and rotate subscription IDs and tenant IDs in GitHub secrets if they become exposed.

Outcome: Secure automated CI/CD pipeline with no stored credentials reducing compromise risk, appropriate separation of environment permissions following principle of least privilege, audit trail for compliance demonstrating who deployed what when, and 90% reduction in deployment-related security incidents compared to previous credential-based approach. Deployment frequency increased 300% due to automation and confidence in security controls.

Scenario 3: Microservices with Managed Identities

Business Requirement: E-commerce company with microservices architecture on Azure Kubernetes Service (AKS) needs services to access Azure resources (SQL Database, Key Vault, Storage, Service Bus) without managing credentials in code or configuration, with different services requiring different permissions.

Azure Solution: AKS Workload Identity with User-Assigned Managed Identities

  • Managed Identity Architecture: Create user-assigned managed identities for each microservice: "mi-order-service", "mi-payment-service", "mi-inventory-service", "mi-notification-service". User-assigned chosen because pods can be recreated frequently and identity should persist, multiple pods of same service share identity, and centralized permission management preferred. Create in resource group separate from AKS cluster for lifecycle management.
  • AKS Configuration: Enable workload identity on AKS cluster (preview feature requiring registration). Create Kubernetes service accounts for each microservice in appropriate namespaces. Establish federated identity credentials linking managed identities to service accounts: Azure managed identity trusts Kubernetes service account, pods using that service account can authenticate as managed identity, no credentials needed in pod specs or configuration.
  • Permission Assignment: Order Service: SQL Database Contributor role for order database, Storage Blob Data Contributor for order documents, Service Bus Sender for order events. Payment Service: SQL Database Contributor for payment database, Key Vault Secrets User for retrieving payment gateway credentials, Service Bus Sender for payment confirmations. Inventory Service: SQL Database Contributor for inventory database, Storage Queue Data Contributor for inventory updates. Notification Service: Service Bus Receiver for all queues, SendGrid API key from Key Vault (Secrets User). Each service has minimum necessary permissions, no service can access another's databases.
  • Application Code: Microservices use Azure SDK DefaultAzureCredential automatically detecting workload identity: SQL connection: var builder = new SqlConnectionStringBuilder { DataSource = "server.database.windows.net", InitialCatalog = "orderdb", Authentication = SqlAuthenticationMethod.ActiveDirectoryManagedIdentity }; Key Vault: var client = new SecretClient(new Uri("https://vault.vault.azure.net"), new DefaultAzureCredential()); Storage: var blobClient = new BlobClient(new Uri("https://storage.blob.core.windows.net/container/blob"), new DefaultAzureCredential()); No credentials in code, environment variables, or configuration files. Identical code runs locally (using Azure CLI identity for development) and in AKS (using managed identity).
  • Development Workflow: Local development: Developers authenticate using Azure CLI or Visual Studio, DefaultAzureCredential automatically uses those credentials, developers granted same permissions as managed identities in dev environment enabling local testing. CI/CD: Test environments use managed identities in test AKS cluster, production uses managed identities in production cluster, no credential management in pipelines, environment parity ensuring code works consistently.
  • Security Benefits: No credentials in source control (eliminated credential exposure risk), no credentials in pod specifications (reduced Kubernetes secret attack surface), automatic credential rotation by Azure (eliminated rotation operations and outage risk), compromised pod cannot access resources of other services (lateral movement prevention through permission isolation), and audit trail in Azure AD sign-in logs showing which pods accessed which resources.
  • Monitoring: Azure Monitor tracking managed identity sign-ins showing which services authenticated when, Azure SQL auditing logging database access by managed identities, Key Vault diagnostic logs recording secret retrievals, Application Insights distributed tracing correlating requests across services, and alerts on authentication failures indicating misconfiguration or attacks.
  • Operational Procedures: Document which managed identity used by which service maintaining inventory, implement permission review quarterly validating continued necessity, test disaster recovery verifying services can access resources after cluster rebuild, monitor for authentication errors indicating permission issues, and maintain runbooks for common operational scenarios.

Outcome: Zero credentials stored in application code, configuration, or Kubernetes secrets eliminating major attack vector and operational burden. 100% of service-to-resource authentication using managed identities. Credential rotation operations reduced from monthly (with client secrets) to zero. Zero authentication-related production incidents in 12 months. Developer satisfaction increased due to simplified local development without credential management. Security audit findings reduced from 15 to 0 related to credential storage.

Exam Preparation Tips

Key Concepts to Master

  • App registrations vs enterprise applications: Registration = blueprint (what app is), enterprise app = instance (who can use)
  • Delegated permissions: App acts on behalf of user, requires user present, permissions = intersection of user + app
  • Application permissions: App acts as itself without user, always requires admin consent, broader access
  • OAuth 2.0 flows: Authorization code (web apps), client credentials (background services), device code (browserless), auth code with PKCE (mobile/native)
  • Consent types: User consent (individual), admin consent (organization-wide), required for app permissions and high-privilege delegated
  • Service principals: Application identity, credentials (secret/certificate/federated), three types (application/managed/legacy)
  • Managed identities: System-assigned (tied to resource), user-assigned (shared/persistent), eliminates credentials, Azure handles lifecycle
  • Best practices: Managed identity >service principal > client secret; least privilege permissions; admin consent for sensitive access

Practice Questions

Sample AZ-500 Exam Questions:

  1. Question: What type of permissions should a background service use when accessing Microsoft Graph without a signed-in user?
    • A) Delegated permissions
    • B) Application permissions
    • C) User-assigned permissions
    • D) OAuth permissions

    Answer: B) Application permissions - Application permissions are used when application runs without signed-in user, acting with its own identity.

  2. Question: Which OAuth 2.0 flow should a single-page application (SPA) use for authentication?
    • A) Client credentials flow
    • B) Implicit flow
    • C) Authorization code flow with PKCE
    • D) Device code flow

    Answer: C) Authorization code flow with PKCE - SPAs should use authorization code flow with PKCE for security; implicit flow is deprecated.

  3. Question: What is required to grant an application permission to read all users in the directory?
    • A) User consent
    • B) Delegated permissions
    • C) Admin consent with application permissions
    • D) Service principal creation

    Answer: C) Admin consent with application permissions - Reading all users requires application permissions (User.Read.All) which always require admin consent.

  4. Question: Which type of managed identity should you use when multiple Azure VMs need to share the same identity?
    • A) System-assigned managed identity
    • B) User-assigned managed identity
    • C) Service principal
    • D) Application identity

    Answer: B) User-assigned managed identity - User-assigned managed identities can be assigned to multiple resources and persist independently.

  5. Question: What is the most secure credential type for service principal authentication?
    • A) Client secret with 2-year expiration
    • B) Certificate
    • C) Federated credential
    • D) Password

    Answer: C) Federated credential - Federated credentials don't require storing secrets, using trust relationships with external identity providers.

  6. Question: Where should you store service principal client secrets?
    • A) Application configuration files
    • B) Environment variables
    • C) Azure Key Vault
    • D) Source code

    Answer: C) Azure Key Vault - Secrets should always be stored in Key Vault with appropriate access controls, never in code or configuration.

  7. Question: What is the difference between app registration and enterprise application?
    • A) They are the same thing
    • B) App registration is the blueprint, enterprise application is the instance in a tenant
    • C) Enterprise applications are for external users only
    • D) App registrations cannot be multi-tenant

    Answer: B) App registration is the blueprint, enterprise application is the instance in a tenant - App registration defines the application; enterprise application is the service principal instance.

  8. Question: Which authentication method should Azure Functions use when accessing Azure Storage?
    • A) Connection strings
    • B) Shared access signatures
    • C) Managed identity
    • D) Service principal with client secret

    Answer: C) Managed identity - Managed identities are preferred for Azure resources accessing other Azure resources, eliminating credential management.

AZ-500 Success Tip: Remember app registration defines the application blueprint while enterprise application is the service principal instance in a tenant. Delegated permissions act on behalf of signed-in user (user must be present); application permissions act as the app itself without user (always requires admin consent). OAuth flows: authorization code with PKCE for web/mobile/SPA, client credentials for background services. Always prefer managed identities over service principals for Azure resources. Store service principal secrets in Key Vault, preferably use certificates or federated credentials. Admin consent required for all application permissions and high-privilege delegated permissions.

Hands-On Practice Lab

Lab Objective

Configure enterprise application access, create and configure app registrations with API permissions, manage consent, create service principals with different credential types, and implement managed identities for Azure resources.

Lab Activities

Activity 1: Create App Registration with Delegated Permissions

  • Register app: Azure AD → App registrations → New registration → Name "Web App Lab", Single tenant, Redirect URI (Web): https://localhost:5001/signin-oidc
  • Add API permissions: API permissions → Add permission → Microsoft Graph → Delegated → User.Read, Mail.Read → Add permissions
  • Grant admin consent: Grant admin consent for [tenant] → Yes (for testing; production apps should follow approval process)
  • Review enterprise app: Azure AD → Enterprise applications → Search for "Web App Lab" → View permissions showing granted consents
  • Note values: Record Application (client) ID, Directory (tenant) ID for application configuration

Activity 2: Configure Application Permissions for Background Service

  • Create service app: App registrations → New registration → Name "Background Service", Single tenant, No redirect URI
  • Add application permissions: API permissions → Add → Microsoft Graph → Application permissions → User.Read.All → Add
  • Grant admin consent: Grant admin consent (required for application permissions)
  • Create client secret: Certificates & secrets → New client secret → Description "Lab secret", Expires 6 months → Add → Copy secret value immediately
  • Document credentials: Record Application ID, Tenant ID, Client Secret (store securely, shown once)

Activity 3: Create Service Principal with Certificate

  • Generate certificate: PowerShell: $cert = New-SelfSignedCertificate -Subject "CN=LabServicePrincipal" -CertStoreLocation "Cert:\CurrentUser\My" -KeySpec KeyExchange
  • Export certificate: Export public key: Export-Certificate -Cert $cert -FilePath "labcert.cer"
  • Upload to app: App registration → Certificates & secrets → Certificates → Upload certificate → Select labcert.cer
  • Assign Azure role: Subscription or resource group → IAM → Add role assignment → Reader → Select app → Assign
  • Test authentication: PowerShell: Connect-AzAccount -ServicePrincipal -CertificateThumbprint $cert.Thumbprint -ApplicationId [appId] -Tenant [tenantId]

Activity 4: Configure Managed Identity for VM

  • Create VM: Create test Windows or Linux VM in Azure Portal
  • Enable managed identity: VM → Identity → System assigned → Status: On → Save (creates managed identity automatically)
  • Assign permissions: Navigate to Key Vault → Access policies → Add access policy → Secret permissions: Get, List → Select principal: [VM name] → Add → Save
  • Verify identity: VM → Identity → Shows Object ID of managed identity, Azure role assignments tab shows current roles
  • Test access: From VM, PowerShell: $token = (Invoke-WebRequest -Uri 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net' -Headers @{Metadata="true"}).Content | ConvertFrom-Json

Activity 5: Create User-Assigned Managed Identity

  • Create identity: Resource groups → Create resource → Search "User Assigned Managed Identity" → Create → Name "mi-lab-shared" → Region → Review + create
  • Assign to resource: Navigate to App Service or VM → Identity → User assigned → Add → Select mi-lab-shared → Add
  • Grant permissions: Storage Account → IAM → Add role assignment → Storage Blob Data Reader → Managed identity → Select mi-lab-shared
  • View details: Managed identity resource → Azure role assignments shows where identity has permissions, Federated credentials if configured

Activity 6: Review and Audit Application Access

  • Review permissions: Enterprise applications → Your app → Permissions → Review granted permissions and consent type
  • Check sign-ins: Enterprise applications → Your app → Sign-ins → View authentication attempts and success/failure
  • Audit logs: Azure AD → Audit logs → Filter Activity: Add app role assignment, Grant consent → Review who granted permissions when
  • Access reviews: Identity Governance → Access reviews → Create review for app assignments (requires P2 license)
  • Monitor service principals: Use Azure AD PowerShell: Get-AzADServicePrincipal | Where-Object { $_.PasswordCredentials.EndDate -lt (Get-Date).AddDays(30) } to find expiring credentials

Lab Outcomes

After completing this lab, you'll have hands-on experience with Microsoft Entra application access management. You'll understand how to create app registrations with appropriate permission types, the difference between delegated and application permissions, admin consent process, service principal creation with multiple credential types (secret, certificate), managed identity configuration for Azure resources, and monitoring application access. These practical skills demonstrate application identity management capabilities tested in AZ-500 exam and provide foundation for implementing secure application access in production Azure environments.

Frequently Asked Questions

What is the difference between app registrations and enterprise applications in Microsoft Entra ID?

App registrations and enterprise applications represent different aspects of application identity in Microsoft Entra ID. App registration is the application definition in your home tenant where you register and configure the application, creating application identity and defining capabilities. When you register an application in Azure portal (Azure AD → App registrations → New registration), you define Name, supported account types (single tenant, multi-tenant, personal Microsoft accounts), redirect URIs, and application configuration. App registration is where you configure API permissions, authentication settings, certificates and secrets, token configuration, and expose APIs. Think of app registration as the blueprint or template for the application. Enterprise application is the service principal instance in a tenant representing that application. When app registration is created in tenant, or when users first consent to multi-tenant app, corresponding enterprise application (service principal) is created. Enterprise application is where you manage actual access and usage in tenant—assign users and groups, configure single sign-on, manage permissions granted to app, set up provisioning, and view sign-in logs. Enterprise applications (Azure AD → Enterprise applications) lists all applications that can be used in your tenant including apps you created, third-party SaaS apps (Salesforce, Office 365, ServiceNow), and multi-tenant apps other organizations created. Key distinction: App registration defines what the application is and what it can do; enterprise application determines who can use it and what permissions it has in specific tenant. For apps you develop, you work with both—register app defining capabilities, then manage enterprise application controlling access. For third-party apps, you typically only see enterprise application after admin or user consents to app.

What are delegated permissions vs application permissions in Azure AD?

Delegated permissions and application permissions represent two different ways applications access resources. Delegated permissions used when application acts on behalf of signed-in user, requiring user to be present. Application accesses resources as the user, constrained by both user's permissions and permissions granted to application (effective permissions are intersection). Examples: Read user's email, access user's OneDrive files, create calendar events for signed-in user. Delegated permissions require user consent or admin consent depending on permission sensitivity. Appropriate when application performs operations with user context—web apps where users sign in, mobile apps with user login, SPAs with user interaction. Common delegated permissions include User.Read (read signed-in user's profile), Mail.Read (read user's email), Files.ReadWrite (access user's files), Calendars.ReadWrite (manage user's calendar). Application permissions used when application runs without signed-in user, acting as itself rather than on behalf of user. Application has permissions regardless of user, typically more powerful and requiring admin consent. Examples: Read all users in directory, access all mailboxes, manage all SharePoint sites. Appropriate for background services, daemons, scheduled jobs, server-to-server scenarios where no interactive user. Common application permissions include User.Read.All (read all users), Mail.Read.All (read all mailboxes), Sites.ReadWrite.All (manage all SharePoint sites), Directory.ReadWrite.All (read/write directory data). Application permissions always require admin consent since they grant elevated access. Best practice: Use delegated permissions when possible following principle of least privilege; use application permissions only for automated scenarios without user context. Configure minimum necessary permissions—don't request Mail.ReadWrite.All if only need Mail.Read. Understand effective permissions—for delegated, app gets lesser of user's permissions and app's permissions; for application, app gets full permission regardless of who triggers action.

What is admin consent and when is it required?

Admin consent is approval by administrator granting permissions to application on behalf of entire organization, enabling all users to use application without individual consent prompts. Required in several scenarios: all application permissions require admin consent since they grant access without user context; certain high-privilege delegated permissions require admin consent (User.ReadWrite.All, Directory.Read.All, etc.); when organization disables user consent requiring admins to approve all applications; and for multi-tenant applications accessing another organization's resources. Admin consent process: Administrator navigates to app registration → API permissions → Grant admin consent for [tenant], or clicks consent prompt when application requests permissions. After admin grants consent, all users can access application without seeing consent prompt. Users see 'This app has been authorized by your organization' indicator. Admin consent appears in enterprise application showing 'Permissions and Consent' with admin-granted permissions. Benefits include improved user experience eliminating consent prompts for approved apps, centralized control ensuring only authorized apps access organizational data, and auditing tracking which admins granted consent when. Risks include admins may not fully understand requested permissions, blanket consent affects all users creating wide impact if app compromised, and applications can request additional permissions later requiring re-consent. Best practices: Review requested permissions carefully before consenting, understand what data application will access, verify application is from trusted publisher or organization, use least privileged permissions, implement app consent policies restricting which apps can be consented to, require admin approval for new permission requests, regularly audit granted permissions removing unnecessary access, and educate users about approved applications and how to report suspicious app behavior. Admin consent different from user consent where individual user approves permissions for themselves only, affecting only that user's data. Admin consent appropriate for line-of-business apps, approved SaaS applications, and company-wide tools; user consent appropriate for personal productivity apps affecting only user's data.

What are service principals and how are they used?

Service principal is identity for application or service to access Azure resources, similar to user identity but for applications. When you register application in Azure AD, two objects are created: application object (blueprint) in home tenant, and service principal (instance) in tenant where app is used. Service principal defines what application can do in specific tenant—permissions, role assignments, and access policies. Three types exist: Application service principal created when you register application in your tenant, representing your app; Managed identity service principal created automatically when you enable managed identity on Azure resource, managed by Azure; and Legacy service principal for apps created before app registrations existed. Use service principals for authentication and authorization—applications authenticate as service principal using client secret or certificate, gaining access to Azure resources and APIs based on permissions granted to service principal. Common scenarios include CI/CD pipelines authenticating to deploy resources, applications accessing Azure Storage or Key Vault, automated scripts managing Azure resources, and third-party applications integrating with your environment. Create service principal when registering app (automatic), via Azure CLI (az ad sp create-for-rbac), PowerShell (New-AzADServicePrincipal), or ARM template. Service principal has credentials—client secret (password, expires, must be rotated), certificate (more secure, can be stored in Key Vault), or federated credential (for workload identity federation, no stored secret). Assign permissions through Azure RBAC granting role assignments (Contributor, Reader, custom roles), and through API permissions granting access to Microsoft Graph, Azure AD Graph, or custom APIs. Best practices include rotating secrets regularly (90 days recommended), preferring certificates over secrets for production, using managed identities instead of service principals when possible eliminating credential management, following least privilege granting minimum permissions, documenting service principal purpose and ownership, monitoring service principal activity detecting anomalies, and removing unused service principals preventing orphaned access. Service principals appear in Enterprise applications in portal where you manage permissions, assignments, and activity. Audit service principal usage through sign-in logs, audit logs tracking permission grants and role changes, and Azure Monitor for operational monitoring.

What are managed identities and what are their benefits?

Managed identities provide Azure services with automatically managed identity in Azure AD, eliminating need to manage credentials. Azure handles credential lifecycle completely—creates identity, rotates credentials, deletes identity with resource. Two types: System-assigned managed identity created and tied to single Azure resource (VM, App Service, Function), lifecycle bound to resource (deleted when resource deleted), used when identity dedicated to single resource; and User-assigned managed identity created as standalone Azure resource, can be assigned to multiple resources, persists independently of resource lifecycle, used when multiple resources need same identity or when identity should survive resource deletion. Supported Azure services include Virtual Machines, Virtual Machine Scale Sets, App Service, Azure Functions, Azure Container Instances, Azure Kubernetes Service, Azure Logic Apps, Azure Data Factory, Azure API Management, Azure Container Apps, and many others. Benefits include no credential management—no passwords, secrets, or certificates to store or rotate; Azure handles everything automatically; automatic rotation reducing compromise risk; integration with Azure RBAC for resource access control; and integration with Azure AD for API access without explicit credentials. Use cases: VM accessing Azure Key Vault to retrieve secrets without storing credentials; App Service reading from Azure Storage without connection strings in configuration; Azure Function calling Microsoft Graph API without client secrets; Container accessing Azure SQL Database using managed identity authentication; Kubernetes workload accessing Key Vault through workload identity. Configuration: Enable managed identity on Azure resource (portal, CLI, PowerShell, ARM template); Assign permissions through Azure RBAC or API permissions; Access resources from application code using Azure SDK which automatically uses managed identity. Authentication automatic—Azure SDK checks for managed identity, obtains token from Azure Instance Metadata Service (IMDS), uses token to access resources. No credentials in code or configuration. Best practices: Prefer managed identities over service principals for Azure resources, use system-assigned when resource has dedicated purpose, use user-assigned when sharing identity across resources or preserving identity during resource replacement, assign least-privilege permissions, audit managed identity usage, and test managed identity functionality before production. Limitations include only works for Azure resources (can't be used for on-premises applications), requires Azure SDK support in application code, and some Azure services have limited managed identity support. For applications running outside Azure or services without managed identity support, use service principals with certificate authentication and Azure Key Vault for credential storage.

How do you configure API permissions and permission scopes for app registrations?

Configuring API permissions enables your application to access Microsoft APIs (Graph, Office 365) and custom APIs. In Azure portal, navigate to App registrations → Your app → API permissions. Add permission by selecting Microsoft Graph, Office 365 APIs, your organization's APIs, or APIs your organization uses. Choose delegated permissions (user context) or application permissions (app context), select specific permissions needed (e.g., User.Read, Mail.Send), and add permissions to app. After adding, admin consent may be required depending on permissions. Permission scopes define granularity of access—coarse-grained scopes grant broad access (User.ReadWrite.All reads/writes all users), fine-grained scopes grant specific access (User.Read reads only signed-in user). Always request minimal scopes necessary for functionality. Permission consent flow: User signs into application, app redirects to Azure AD requesting permissions with OAuth 2.0 authorization code flow, Azure AD shows consent prompt listing requested permissions, user or admin grants consent, Azure AD returns authorization code, app exchanges code for access token, app uses token to call APIs. Exposing API: If building API, define scopes under Expose an API in app registration. Add scope specifying name (like Order.Read), display name shown in consent prompt, description explaining what permission grants, admin/user consent setting, and state (enabled/disabled). Client applications request these custom scopes when accessing your API. Configure by defining Application ID URI identifying your API (api://your-app-id or custom domain), adding scopes with meaningful names and descriptions, defining app roles for role-based access, and setting authorized client applications. Best practices for permission configuration: Request minimum necessary permissions following least privilege, prefer delegated over application permissions when user context available, use fine-grained permissions avoiding overly broad access, document why each permission needed for compliance and auditing, test permissions with real users ensuring consent prompt is clear, handle permission denial gracefully with user-friendly messages, request additional permissions only when needed using incremental consent, separate admin-requiring and user-consentable permissions reducing admin burden, and regularly audit granted permissions removing unused access. Monitor API permission usage through sign-in logs showing which permissions apps are using, Azure AD audit logs tracking permission grants and changes, and Microsoft Cloud App Security identifying overprivileged applications. Security considerations: Validate all API responses don't trust data implicitly, implement rate limiting preventing abuse, log API access for security monitoring, and revoke compromised app permissions immediately.

What is OAuth 2.0 and how does it work in Azure AD?

OAuth 2.0 is industry-standard authorization framework enabling applications to obtain limited access to user resources without exposing credentials. Azure AD implements OAuth 2.0 as authorization server managing tokens and permissions. Key concepts: Resource owner (user) who owns data and grants access, client (application) requesting access to resources, authorization server (Azure AD) authenticating user and issuing tokens, resource server (API like Microsoft Graph) hosting protected resources, and access token proving authorization to access resources. OAuth flows (grant types) in Azure AD include: Authorization code flow (most common) for web apps—user signs in at Azure AD, AD returns authorization code to app, app exchanges code for access token with client secret, app uses access token to call APIs; provides best security separating user credentials from client credentials. Implicit flow (legacy, not recommended) where browser receives tokens directly, suitable for single-page applications but less secure; replaced by authorization code with PKCE. Client credentials flow for server-to-server scenarios—app authenticates with client secret or certificate, receives access token without user, uses application permissions; suitable for background services and daemons. Resource owner password credentials (ROPC) where app collects username and password directly—discouraged, only for legacy scenarios unable to use modern authentication. Device code flow for devices without web browsers—device shows code to user, user enters code on separate device with browser, device receives tokens; suitable for IoT devices and command-line tools. Authorization code with PKCE (Proof Key for Code Exchange) adds security to code flow preventing code interception, required for mobile and desktop apps. Tokens in OAuth: Access token grants access to resources, short-lived (typically 1 hour), contains claims about user and permissions; Refresh token (if requested) allows obtaining new access tokens without re-authentication, long-lived, must be stored securely; ID token (in OpenID Connect) contains user identity information, not for API access. Token validation: APIs must validate access token ensuring it's from Azure AD, hasn't expired, has expected audience (your API), has required permissions/roles, and hasn't been revoked. Azure AD libraries handle validation automatically. Security best practices: Use authorization code flow with PKCE for web, mobile, and desktop apps; never expose client secrets to browsers or mobile apps; validate all tokens on API side; use short-lived access tokens; store refresh tokens securely encrypted; implement proper redirect URI validation; use state parameter preventing CSRF attacks; enable token encryption for sensitive data; implement token revocation for compromised scenarios; and monitor token usage detecting anomalies. Scopes and permissions: Applications request scopes in authorization request (scope=User.Read Mail.Send), user or admin consents to scopes, access token includes consented scopes, API validates required scopes in token. Conditional Access and OAuth: Conditional Access policies evaluated during authentication affecting token issuance—may require MFA, compliant device, or specific location. Continuous Access Evaluation (CAE) enables real-time token revocation when security events occur.

How do you secure service principals and manage credential lifecycle?

Service principal security critical since they provide application access to resources often with elevated permissions. Credential management strategies: Client secrets are passwords with expiration (maximum 2 years), should be rotated regularly (90 days recommended), stored in Azure Key Vault never in code or configuration files, and monitored for approaching expiration. Create secrets through portal, PowerShell (New-AzADAppCredential), or CLI (az ad app credential reset). Certificates more secure than secrets—can be stored in Key Vault, harder to exfiltrate, support hardware security modules (HSMs), and recommended for production. Upload certificate to app registration, store private key in Key Vault, configure app to retrieve certificate from Key Vault at runtime. Federated credentials newest approach—no stored secrets, trust relationship with external identity provider (GitHub Actions, AWS, Google Cloud), identity provider issues token proving identity, app exchanges external token for Azure AD token. Best for CI/CD pipelines and workload identity federation. Credential lifecycle management: Monitor expiration using Azure AD audit logs, Azure Monitor alerts, PowerShell scripts checking expiration dates; Automate rotation using Azure Automation runbooks, PowerShell scripts, or third-party tools; Set up notifications alerting owners before expiration; Document which apps use which service principals maintaining inventory; and Implement emergency procedures for compromised credentials. Security best practices: Follow least privilege granting only necessary permissions; Use managed identities instead of service principals when possible; Separate service principals by environment (dev, test, production); Assign permissions at appropriate scope (resource group vs subscription); Enable sign-in risk policies for service principals; Monitor service principal activity reviewing sign-in logs, API call patterns, unusual resource access; Configure alert on failed authentication attempts indicating attack; Review permissions regularly removing unused access; Restrict who can create service principals using Azure AD policies; Require approval for high-privilege service principals; Document service principal purpose, owner, and permission justification; and Audit service principal changes tracking creation, deletion, permission modifications. Conditional Access for service principals: Azure AD now supports Conditional Access for workload identities—can require specific locations, trusted networks, or risk-based conditions. Implement for high-risk service principals accessing sensitive resources. Compliance considerations: Service principals should be in asset inventory for audit, need disaster recovery procedures for credential loss, require documented approval for privileged access, need regular access reviews validating continued need, and should have backup secrets or certificates for availability. Rotation process: Generate new credential before old expires, test new credential in non-production, update all services to use new credential, verify services functioning correctly, remove old credential after validation period, document rotation in change log. Tools for management: Azure Key Vault for secure storage, Azure Monitor for logging and alerting, Azure Automation for rotation automation, Microsoft Defender for Cloud for security recommendations, and Azure AD Workbook templates for service principal reporting.

Share:

Written by Joe De Coppi - Last Updated November 14, 2025

Previous: Objective 1.1 Manage Security Controls Identity Access

Next: Objective 2.1 Plan Implement Security Virtual Networks