Microsoft Entra ID and Azure RBAC: Identities and Access

Identity Types

Microsoft Entra ID authenticates people and applications, while Azure RBAC authorizes actions on Azure resources.

Users and groups represent workforce access. Service principals identify applications, and managed identities let supported Azure resources obtain tokens without storing credentials.

An Azure role assignment combines a security principal, role definition, and scope. Inherited assignments can make access broader than a resource-level view suggests.

Use users and groups for people, service principals for external automation, and managed identities for supported Azure workloads. System-assigned identities follow one resource; user-assigned identities can be shared deliberately.

Avoid shared user accounts.
Prefer workload identity federation or managed identity over client secrets.
Review ownership of app registrations and enterprise applications.

Role, Principal, and Scope

Built-in roles describe permitted actions. Scope can be a management group, subscription, resource group, or resource, with assignments inherited by child scopes.

Use Reader, Contributor, and Owner only when their full permissions are intended.
Create custom roles when built-in roles are consistently too broad.
Assign access through groups where possible.

Management Plane and Data Access

A Contributor may manage a storage account without being able to read blobs. Data access requires an appropriate data role such as Storage Blob Data Reader or a service-specific authorization path.

Test the actual data operation, not only portal visibility.
Avoid account keys when Entra authorization is supported.
Treat Key Vault access model and role scope as separate design decisions.

Review and Troubleshoot Access

When access fails, capture the caller object ID, tenant, action, resource ID, and scope. Then inspect inherited assignments, deny assignments, conditional access, and service-specific restrictions.

Use Privileged Identity Management for time-limited privileged roles where available.
Remove stale role assignments and unused credentials.
Validate one expected success and one expected denial.

Directory Objects and Tokens

A user, group, service principal, or managed identity has an object in a tenant. An app registration defines an application identity blueprint, while an enterprise application is the service principal instance in a tenant. Authentication proves the caller and obtains a token; authorization at the target decides whether the token may perform the operation.

Tokens have an audience, tenant issuer, subject or application identity, scopes or roles, and lifetime. An API must validate signature, issuer, audience, time, and its authorization claims rather than merely decoding the payload. A token issued for Microsoft Graph is not automatically valid for Azure Resource Manager or a custom API.

Use groups for workforce assignment, but account for group ownership, nested behavior, token claim limits, and delayed membership propagation in sensitive workflows. Keep directory object IDs as stable references; display names and email-style identifiers can change or collide.

Distinguish app registration from tenant service principal.
Validate token audience and issuer at every API.
Use object IDs for durable authorization references.
Govern group ownership and membership changes.

Managed Identity and Federation

A system-assigned managed identity is tied to one Azure resource and is removed with that resource. A user-assigned managed identity has its own lifecycle and can be attached to several supported resources. Choose system-assigned for simple one-resource ownership and user-assigned when preauthorization, shared identity, or independent lifecycle is a deliberate requirement.

Workloads obtain managed-identity tokens from the Azure platform and SDK credential chain without storing a client secret. Restrict access to local metadata endpoints and do not let untrusted code request arbitrary resource audiences. The identity still requires a data or management role at the target scope; creating it grants no resource access by itself.

Workload identity federation lets an external CI system, Kubernetes workload, or other trusted issuer exchange a signed external assertion for an Entra token without a stored Azure secret. Bind issuer, subject, and audience narrowly, protect the source repository or cluster identity, and test that another branch or service account is denied.

Choose identity lifecycle deliberately.
Grant only target roles the workload needs.
Protect metadata and token endpoints from untrusted code.
Narrow federated credentials to the exact external subject.

Azure RBAC Evaluation

An Azure role definition contains management-plane `Actions` and `NotActions` plus data-plane `DataActions` and `NotDataActions` where supported. A role assignment binds the definition to a principal at management-group, subscription, resource-group, or resource scope. Child resources inherit assignments from parent scopes.

`NotActions` removes actions from a wildcard permission; it is not an explicit deny against permissions granted by another assignment. Deny assignments are separate and are commonly managed by Azure features rather than ordinary administrators. Policy can deny resource configuration but does not replace RBAC authorization for a caller.

Start with a built-in role whose full permission set is appropriate. Create a custom role when the repeated job requires a stable narrower action set, keep assignable scopes controlled, and version it. Avoid Owner and User Access Administrator at broad scope because role-assignment authority can become privilege escalation.

Review Actions and DataActions separately.
Inspect inherited assignments at every parent scope.
Do not treat NotActions as a deny.
Protect role-assignment permission as high privilege.

Directory Roles and Privileged Activation

Microsoft Entra directory roles govern directory resources such as users, groups, applications, and tenant settings. Azure RBAC governs Azure resources through Resource Manager and service data planes. A Global Administrator is not automatically the correct subscription operator, and a subscription Owner should not automatically administer the directory.

Privileged Identity Management can make supported roles eligible rather than permanently active, require justification, approval, MFA, bounded duration, and access review. Design emergency paths separately and alert on activation. Time-limited privilege reduces standing exposure but still needs least-privilege role definitions and monitoring.

Conditional Access evaluates sign-in context such as user, application, authentication strength, device, location, and risk according to policy. It complements authorization rather than granting resource permissions. Test policies with report-only or controlled groups and exclude only documented emergency identities from dependencies that could block recovery.

Keep directory and resource administration separate.
Use eligible activation for routine privileged roles.
Require approval for sensitive role activation where justified.
Test Conditional Access before broad enforcement.

Application Consent and Credentials

An application may request delegated permissions to act with a signed-in user or application permissions to act as itself. Application permission can be powerful because no user context limits it. Review publisher, owner, redirect URI, requested permission, tenant consent, and business purpose before granting administrator consent.

Prefer managed identity for applications on Azure and workload identity federation for supported external automation. When a certificate or client secret is unavoidable, store it in an approved vault, use the shortest practical lifetime, rotate before expiry, monitor use, and remove obsolete credentials. A secret copied into a pipeline variable remains a long-lived credential even when the variable is masked in logs.

Review enterprise applications, consent grants, credential expiry, sign-in activity, app owners, and federated credential subjects on a schedule. Remove abandoned registrations and service principals carefully after confirming no token, automation, or downstream trust still depends on them.

Distinguish delegated and application permission.
Review tenant-wide administrator consent carefully.
Prefer secretless workload authentication.
Give every application identity an accountable owner.

Authorization Diagnosis

Capture tenant ID, principal object ID, token audience, action, resource ID, scope, timestamp, correlation ID, and exact error. Confirm the selected subscription and the actual credential in use before changing role assignments. Recently changed membership or assignments can take time to appear in cached tokens and service authorization data.

Inspect inherited and direct role assignments, role Actions or DataActions, deny assignments, Policy effects, resource locks, service firewall or private endpoint rules, and service-specific authorization. A request can be correctly authorized by RBAC and still fail at the network or application layer. Conversely, portal resource visibility does not prove data access.

Correct the narrow cause, obtain a fresh token when required, and test both the allowed operation and a nearby denied operation. Do not assign Owner as a diagnostic shortcut. Record the final principal-role-scope and network contract in deployment tests so future changes reveal unintended privilege or denial.

Reproduce with the exact principal and resource ID.
Check token audience before RBAC changes.
Separate authorization from network reachability.
Retest expected denial after the fix.

Access Propagation

Role assignments, group membership, managed-identity authorization, and token caches can propagate on different schedules. Plan deployments so a newly created identity is authorized before application traffic depends on it, refresh tokens after confirmed assignment, and avoid repeated broad role changes while propagation is still in progress.

Assign lifecycle work to a named owner.
Verify the replacement before the deadline.

Identity and RBAC Examples

Azure managed identity storage access example

Give the app a managed identity and grant it only blob-read access on the target storage account instead of storing credentials in app settings.

Azure managed identity storage access example

az webapp identity assign --name app-orders-prod --resource-group rg-app-prod
principalId=$(az webapp identity show --name app-orders-prod --resource-group rg-app-prod --query principalId -o tsv)
az role assignment create \
  --assignee-object-id "$principalId" \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-data-prod/providers/Microsoft.Storage/storageAccounts/stordersprod

Managed identity is preferred over stored keys.
Scope the role assignment to the exact storage account, not the whole subscription.

Explain an RBAC Denial

A managed identity can read a storage account resource but cannot read blob data.

Explain an RBAC Denial

Constraints: Management-plane Reader does not grant data-plane access; group and deny assignments may affect the result.
Decision: Trace principal, token audience, role definition, assignment scope, propagation, and any deny assignment.
Verification: The identity gains only Storage Blob Data Reader at the container scope and reads the intended blob.
Failure test: Request a blob from a sibling container and confirm it remains denied.

Output

Expected evidence: The identity gains only Storage Blob Data Reader at the container scope and reads the intended blob.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on