Azure Identity

Azure identity trips people up in a way AWS doesn’t, and the reason is structural: there are two permission systems, they govern different things, and reasoning about one while forgetting the other is the source of most Azure identity findings.

The two-plane confusion

Azure has two distinct authorization planes:

• Entra ID roles govern the directory — managing users, groups, applications, and the tenant itself. Global Administrator lives here.
• Azure RBAC governs resources — VMs, storage, databases, the things inside subscriptions. Owner and Contributor live here.

They are separate systems with separate role definitions and separate assignments, and the confusion is bidirectional and dangerous. A user with Owner on a subscription (Azure RBAC) controls the resources but not the directory — until you notice that controlling the resources includes controlling identities attached to them. And a directory role can grant paths into resources. The two planes meet in ways that create escalation, and reasoning about only one plane is how the escalation gets missed.

The single most useful Azure identity habit: for any principal, ask both “what can it do in the directory” and “what can it do to resources,” because the interesting privesc lives in the gap between the two answers.

Entra objects

• Users — human identities.
• Groups — collections, and an assignment target. Dynamic groups (membership by rule) are a subtle risk: control an attribute the rule reads and you control membership.
• Service principals — the identity of an application in the tenant. The Azure equivalent of “what a workload runs as,” and where a large share of over-privilege accumulates.
• Managed identities — a service principal Azure manages the credentials for. No secret to leak, which is the point — and the risk, below.
• App registrations — the definition of an application, which stale ones become forgotten trust relationships.

Managed identity is what an attacker inherits

A managed identity means a resource — a VM, a Function, an App Service — is a directory principal, and Azure handles its credentials. Excellent hygiene, because there’s no secret to steal. But it changes what compromise means: compromise the resource and you are its managed identity, with whatever that identity can do.

So an over-privileged managed identity on an internet-facing resource is a direct path: reach the resource, inherit the identity, use its permissions. This is the Azure analogue of AWS metadata credential theft, and the fix is the same principle — least privilege on the identity, so inheriting it is worth as little as possible.

The misconfigurations that matter

• Over-privileged service principals. The most common serious finding. Applications granted far more than they use, often Owner or a powerful Graph permission “to make it work.”
• Dangerous Graph permissions. RoleManagement.ReadWrite.Directory is directory takeover; AppRoleAssignment.ReadWrite.All lets a principal grant itself more. Application permissions on Graph deserve the scrutiny of admin role assignments, because that’s what they are.
• Consent grant abuse. A phishing path: trick a user into consenting to a malicious app’s Graph access, and the app has the user’s data without ever touching a password. It defeats MFA because it’s not authentication — it’s authorization the user granted.
• Stale app registrations. Forgotten applications with live credentials and standing permissions — trust relationships nobody remembers, which is exactly what makes them useful.
• Unscoped Owner assignments. Owner at the subscription or management-group level where a narrower role at a resource-group scope would do.

The cloud-to-on-prem bridge

The finding class unique to Azure’s common hybrid deployments: the connection back to on-premise Active Directory. Entra Connect and its sync account are highly privileged by necessity, and compromising the sync server or its account can bridge from cloud into the on-prem directory — or the reverse. In hybrid environments this is frequently the highest- impact identity target, because it collapses the boundary between two directories that were supposed to be separately defended.

Solutions

• PIM (Privileged Identity Management) — just-in-time elevation. Standing privileged access becomes on-request, time-boxed, and audited, which shrinks the window in which a compromised privileged account is actually privileged.
• Access Reviews — periodic recertification of who has what, the mechanism that catches the over-privileged service principal and the stale assignment before an attacker does.
• Conditional Access — the policy engine: require MFA, compliant devices, or trusted locations per app and per risk level. This is Azure’s Zero Trust policy enforcement point, and its design is where a lot of real-world identity security is won.
• Workload identity federation — the OIDC pattern for Azure, so external workloads authenticate without a stored secret.

Where this connects

The two-plane structure and managed-identity abuse are what cloud pentesting enumerates in Azure. Conditional Access is Zero Trust enforcement, and the architectural guardrails — management-group policy, scoped assignments — are cloud security. The contrast with AWS identity is instructive: same problems, different failure surfaces.