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 rides on authorization the user granted, not on the authentication path.
• 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.

The other half of that bridge — the directory itself, its tiering model, and the Kerberos and certificate-services attack surface an attacker lands in — is Active Directory & Hybrid Identity.

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.

How it looks in practice

The observable state of a tenant that has internalized this page:

• Global Administrator has zero permanent members. Every privileged role is PIM-eligible, and the count of standing assignments is a tracked metric — the two exceptions are break-glass accounts, excluded from Conditional Access by design and alarmed so loudly that any sign-in pages a human.
• Users cannot consent their way into a breach. User consent is limited to verified publishers and low-risk permissions, with an admin-consent workflow for the rest — the consent-grant path becomes a reviewed request instead of a phishing outcome.
• Service principals sit inside access reviews, not just people — Graph application permissions get recertified with the same seriousness as admin roles, because that is what they are.
• Conditional Access has a named baseline — phishing-resistant MFA for privileged roles, compliant device for admin portals — and new policies ship in report-only mode first, so the tenant learns what would break before it breaks.

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.