Managed identity problems cross four different boundaries
Managed identity replaces stored application credentials with an Azure-managed Microsoft Entra principal. It does not itself authorize a storage operation, fix a private DNS record or make an application token valid for the wrong service. When a virtual machine reports a 403 uploading a blob, find which layer failed before changing role assignments or network rules. Authentication, target authorization, token audience and reachability are separate tests.
Consider an invoice-import job that worked before a deployment but can no longer upload objects. Record the VM resource ID, enabled managed identity, selected principal ID, Blob account, requested action and request correlation details. An elevated human administrator’s successful portal experience is not proof the workload has the same identity or network path. Do not paste access tokens into a support ticket.
Prove which identity the workload uses
A system-assigned identity follows its resource’s lifecycle. A user-assigned identity is a separate Azure resource that can be attached to supported workloads. A VM or app may have more than one user-assigned identity; in that case, the SDK or configuration may need to select a specific client ID. Inspect the identity actually associated with the executing resource rather than matching by friendly name.
The identity’s client ID, Entra principal or object ID, tenant and Azure resource ID describe different things. A resource-role assignment must target the correct principal at the correct scope. After recreation of a system-assigned identity, the new principal may not match assignments granted to the old principal. Compare actual identifiers instead of assuming the old readable name still identifies the same security object.
Separate a missing token from a denied data operation
A client first obtains a token for a service audience or scope; the target then evaluates that token and the requested operation. Requesting an Azure Resource Manager token does not make it a Blob data-plane credential. If token acquisition fails, inspect runtime identity support, client library version, selected identity and requested audience before granting additional permissions.
Once token acquisition succeeds, authorization still depends on the destination service. Microsoft’s documentation for managed identities explains credential lifecycle and supported infrastructure. The current service SDK defines audience and token handling, so record its actual version and avoid hardcoding legacy endpoints as universal behavior.
Calculate resource scope and data actions
Azure RBAC for resource management and service-specific data actions are not interchangeable. A workload may read an account’s management properties but lack Blob data permissions. Find the exact requested operation, target container or account, role definition, inherited assignment scope and effective principal. An assignment granted to a similarly named application in another tenant cannot authorize this identity.
Analyze Azure RBAC by identifying the principal, assigned role and effective scope. Prefer the least-privileged data role at an appropriate boundary. A blanket subscription Owner grant is not a sound repair. If access was recently assigned, account for documented propagation and cached identity tokens before concluding that the assignment failed.
Confirm the path to a protected service
Storage account network restrictions remain effective even when a workload has a valid managed identity and appropriate data role. Check the deployed client’s DNS answer, public/private endpoint selection, routing, NSG constraints and account firewall. A token proves nothing about whether the client reaches the permitted endpoint. Compare the actual VM or app subnet rather than testing from an administrator’s laptop.
Private endpoint DNS determines whether clients select the intended private IP for the service. A private endpoint may exist while an enterprise resolver returns a public IP for the account. Fixing the resolver or link can restore the intended route without touching authorization. Network errors should be isolated from token rejection by testing each layer.
Handle propagation and lifecycle safely
A role change or identity attachment can take time to become visible to all components. Some token caches mean a running application continues using a previously issued token. Capture assignment time and runtime state, then retest under supported propagation expectations. Repeatedly deleting and recreating a managed identity is a poor diagnostic strategy and can introduce a new principal with new permissions.
Compare the effect of replacing a VM with the effect of moving a user-assigned identity between supported resources. Recheck resource-association state and target access after the change. Preserve the original identity and assignment details in the change record; do not introduce Shared Key credentials to hide a managed-identity integration failure.
Rehearse five failures without escalating privileges
Create a disposable workload with a known working identity and one permitted Blob action. Induce one fault at a time: identity disabled, wrong user-assigned identity chosen, token requested for the wrong audience, missing data role, and network access rejected by account rules. Record each resulting symptom, request layer, evidence, remediation and successful retest. A teaching lab that combines every fault at once is difficult to diagnose.
For a wrong client ID, the remedy is identity selection, not role broadening. For a missing data role, assign only the necessary action on the correct scope. For a private DNS or firewall problem, verify the endpoint and route instead of regenerating application credentials. These contrasting cases create a diagnostic decision tree rather than another general introduction to identity.
Turn the diagnosis into an Azure administrator runbook
Write a support worksheet with columns for principal, client ID, token audience, requested data action, RBAC scope, destination hostname, resolved IP, relevant policy, error code and owner. Start at the first failing layer and move forward. Securely redact tokens and secrets from captured requests; keep enough correlation information for audit without creating a new data exposure.
A managed identity can change during resource replacement: a system-assigned identity belongs to its resource, while a user-assigned identity is a distinct resource reusable by supported workloads. Microsoft AZ-104 objectives also cover role assignments, storage and networking. When access fails, isolate the actual principal, token audience, target permission and network path before making a broad access change.