Site icon Windows Active Directory

Using custom roles and pim in entra id

Arun Kumar

Least privilege that actually survives real life

Imagine you’re the person who gets paged when “someone needs admin access right now.” The request is always urgent. The blast radius is always unclear. And the only role that “just works” is usually global administrator.

That is the default failure mode of identity governance: not because people love risk, but because granularity is hard and operations are messy.

Using custom roles and pim in entra id is Microsoft’s most practical answer to that problem: you define exactly what an operator can do, then you gate it behind just-in-time activation, with mfa, justification, approvals, and time limits. PIM explicitly supports built-in and custom Microsoft Entra roles, so you can stop choosing between “too much access” and “no access.”

This article goes beyond the surface “click here, click there” tutorial. We’ll break down the mechanics, the hidden constraints that shape your design, and a technical “hero” section you can use as an implementation blueprint. We’ll also incorporate field learnings (the stuff that shows up in admin blogs, scripts, and forum threads when the portal UI isn’t enough).

what the simple explanation misses

At a high level, everyone explains it like this:

That’s correct. It’s also incomplete.

What’s missing is the why: why you should prefer custom roles over built-in roles in specific cases, and why PIM changes the operating model of administration (not just the assignment model).

The superficial view treats roles as static “permission bundles.” The deeper view is:

a role is an interface to a control plane. pim turns that interface into a time-bound, audited transaction.

Once you see it this way, design decisions become clearer:

That difference is where mature tenants separate from chaotic tenants.

Basically,

1) least privilege is not a role; it’s a boundary

“Least privilege” is only meaningful if you can draw a boundary around actions. In Entra ID, boundaries typically align to:

Custom roles in Entra can be created for directory scope or app registration resource scope (and there are custom-role patterns for enterprise app management as well).

Implication: If you can’t scope a role to the boundary you want, you can’t claim least privilege—you can only claim “less privilege than global admin.”

2) pim’s real value is “transactional privilege”

PIM isn’t just “temporary admin.” It enforces friction and traceability:

Implication: PIM is a control mechanism. Custom roles are a precision mechanism. You want both.

3) operations always route around controls unless the controls are usable

This is the part you see repeatedly in practitioner write-ups and scripts:

Implication: If you don’t design for the ops reality (automation, approvals, monitoring), users will push for permanent broad roles again.

where custom roles are worth it (and where they aren’t)

Custom roles shine when you have:

Microsoft’s role-based access control overview makes the key point: built-in and custom roles exist to grant granular permissions aligned to least privilege.

Custom roles are not worth it when:

When you hit limitations outside Entra directory roles (for example, certain service-specific RBAC models), many practitioners shift to PIM for Groups as a workaround pattern for JIT access across workloads. (Microsoft Learn)

The real design patterns that work in mature tenants

pattern 1: “operator roles” mapped to runbooks

You create roles that match how work is done:

Then you attach:

This makes the role auditable and teachable.

pattern 2: split “configuration” from “execution”

A classic failure: one role allows both configuring security policy and executing privileged actions. Split them:

Then PIM each separately. In an incident, you can grant execution without granting policy mutation.

pattern 3: group-based eligibility for scale

Even when assigning Entra roles, many orgs prefer controlling “who can become eligible” via group membership that is itself governed. PIM for Groups exists specifically to grant JIT membership/ownership of groups used across multiple access-control systems.

pattern 4: treat role definitions like code

This is where advanced teams go:

Even if you don’t fully “IaC” it on day one, you can design toward it.

Implementation blueprint (custom role + pim)

This is the straight-through, implementation-focused core. The goal is to produce a custom Entra role that is eligible via PIM, with activation controls and auditability, and to do it in a way that survives production constraints.

prerequisites and control-plane access

  1. licensing
  1. who can do what
  1. define the scope boundary first
    Before you create anything, decide:

Microsoft’s role assignment guidance explicitly highlights tenant, application registration, and administrative unit scopes in Entra role assignments.

step 1: design the custom role as a “minimal action set”

Start from tasks, not permissions. Example task: “App assignment operator can assign users/groups to enterprise apps, but cannot modify conditional access or create app registrations.”

Microsoft provides a custom-role path specifically for managing enterprise app assignments. That’s a strong baseline pattern because it’s narrowly scoped to a common operational need.

Practical method:

If you’re creating a directory-level custom role in Entra, Microsoft documents that it can be assigned at directory-level scope or app registration resource scope only.

Key rule: if the permission model cannot express your boundary, do not pretend it does. Use a different governance approach (often: role-assignable groups + PIM for Groups, or workload-native RBAC).

step 2: create the custom role in Entra

In the Microsoft Entra admin center:

Operational tip: use naming conventions that encode intent and scope, for example:

This matters later when you have dozens of custom roles and multiple approval workflows.

step 3: onboard the custom role into pim (eligible assignment)

PIM supports built-in and custom Entra roles, and the assignment workflow is the same:

Hard edge: role assignments in PIM have timing constraints (for example, Microsoft notes minimum assignment duration and a short window where removal isn’t allowed). These are small, but they matter in automation and emergency response runbooks.

step 4: configure role settings (the real governance)

This is where most implementations become “real” instead of “checkbox secure.”

For the custom role, configure:

  1. activation requirements
  1. approval workflow
  1. duration
  1. notifications

Microsoft’s role settings documentation explicitly enumerates these controls (mfa, approval, duration limits, notifications) and clarifies they are defined per role.

Design guidance from first principles:

step 5: validate end-to-end with a “task-based” test

Do not validate by “the role activates.”

Validate by running the exact tasks the role exists for:

Also validate the user experience:

Microsoft documents the activation flow for eligible admins: eligible users must activate when needed, then permissions expire after.

step 6: automate reporting and governance (what mature teams actually do)

Portal views are fine until you have:

This is where admin blogs and scripts show up: teams report on Entra role assignments including PIM eligibility and activations using Graph-based PowerShell.

A practical approach:

If you’re automating assignments, be careful about the common confusion: Entra directory role assignment and Azure subscription RBAC are different, and automation identities need the correct Entra-side privileges. This shows up repeatedly in Q&A threads when cmdlets fail unexpectedly. (Stack Overflow)

step 7: handle the “break glass” reality without destroying your model

Every serious tenant needs emergency access. But “emergency” is the easiest excuse for permanent global admin.

A strong pattern:

PIM’s value is strongest when emergency operations still produce a tight audit trail with explicit activation windows.

where forum reality changes the strategy: pim for groups as the “universal jit adapter”

In practice, admins often face workloads where directory roles aren’t the right control plane, or where custom roles don’t map well. That’s why PIM for Groups matters: it enables just-in-time membership/ownership for groups that control access to many systems, including Entra roles, Azure roles, Intune, and third-party apps.

Many “how do I use PIM with X” posts converge on the same idea:

This is the pragmatic, cross-service approach. It’s not “pure” directory roles—but it’s often the only model that scales across Microsoft 365 workloads.

Key takeaways that will still be true a year from now

Exit mobile version