Configuring Entra ID PIM for Just-in-Time Admin Access

#Operational requirement

Standing admin roles are the most common finding in every identity security review KBY has run over the past three years. A Global Administrator or Exchange Administrator role sitting permanently active on a user account is a 24/7 attack surface. It does not matter how strong the password policy is if the account never has to prove it needs that privilege today. Microsoft Entra ID Privileged Identity Management (PIM) removes standing privilege by making roles eligible rather than active. A user requests activation, satisfies a control such as MFA, justification, or manager approval, receives the role for a fixed window, and the role expires automatically when that window closes. Get this wrong and the consequences are immediate: administrators locked out of Exchange Online mid-incident, or a supposedly temporary eligible assignment quietly converted into a permanent active one because nobody understood the difference between an eligibility schedule and an assignment schedule. This runbook walks a newly hired junior engineer through provisioning a PIM-eligible role correctly, with evidence you can hand to an auditor without apology.

The deliverable for this exercise is one Entra ID role — Exchange Administrator, used here as the working example — converted from a permanent active assignment to a time-bound eligible assignment with MFA-on-activation and manager approval enabled. You will finish with a documented activation test, a before-and-after policy record, and an audit log export proving the control actually works end to end, not just that a checkbox was ticked in the portal.

#Prerequisites and permissions

Confirm every item below before touching a production tenant. A missing licence or an incorrect delegated scope mid-change is the fastest way to turn a routine task into an unplanned outage.

#Step 1: Confirm current assignment state

Before changing anything, capture the existing state so you have a rollback baseline. Connect to Graph with the correct scopes.

1Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory","RoleManagementPolicy.ReadWrite.AzureADRoles","Directory.Read.All"
2
3Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Exchange Administrator'" |
4 Select-Object Id, DisplayName

Expected result: a single role definition object with an Id in GUID format, for example 29232cdf-9323-42fd-ade2-1d097af3e4de. Record this GUID; you will reuse it in every subsequent call.

Evidence to capture: an export of current active assignments for that role definition.

1Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '29232cdf-9323-42fd-ade2-1d097af3e4de'" |
2 Select-Object PrincipalId, RoleDefinitionId, DirectoryScopeId |
3 Export-Csv -Path .pim-baseline-exchange-admin.csv -NoTypeInformation

Do not proceed until this CSV is saved and attached to the change record. If the role already shows zero active assignments, note that explicitly — it changes your rollback plan later.

#Step 2: Configure the role management policy

PIM behaviour for a role is governed by a role management policy object, not by the assignment itself. This is the step most junior engineers skip, and it is why activations either sail through with no MFA prompt or sit stuck waiting for an approver nobody configured. Retrieve the policy assignment for the role.

1$policyAssignment = Get-MgPolicyRoleManagementPolicyAssignment -Filter "scopeId eq '/' and scopeType eq 'DirectoryRole' and roleDefinitionId eq '29232cdf-9323-42fd-ade2-1d097af3e4de'"
2$policyAssignment.PolicyId

Use the returned PolicyId to inspect and then update the rules that matter for a first rollout: the activation MFA requirement and the approval requirement.

1Get-MgPolicyRoleManagementPolicyRule -UnifiedRoleManagementPolicyId $policyAssignment.PolicyId |
2 Where-Object { $_.Id -like "Enablement_EndUser_Assignment" -or $_.Id -like "Approval_EndUser_Assignment" }

Expected result: the Enablement rule lists required enablement rules including MultiFactorAuthentication; the Approval rule shows isApprovalRequired. If MFA is absent from the enablement list, update the rule with Update-MgPolicyRoleManagementPolicyRule to add it, and set a maximum activation duration — eight hours is a sane starting point for admin roles, not the default twelve or twenty-four. Save the JSON body of both rules before and after the change to your change record. Then confirm the approver group referenced in the approval rule actually exists and has at least two members. An approval rule pointing at an empty or deleted group locks activation permanently — this is one of the most common self-inflicted outages in PIM rollouts.

#Step 3: Create the eligible assignment

Convert your test account to eligible using a role eligibility schedule request. Note the endpoint name carefully: eligibility, not assignment.

1$params = @{
2 Action = "AdminAssign"
3 PrincipalId = "5c2f8a3b-91e6-4a2e-8ab0-cc112d7e0f31"
4 RoleDefinitionId = "29232cdf-9323-42fd-ade2-1d097af3e4de"
5 DirectoryScopeId = "/"
6 ScheduleInfo = @{
7 StartDateTime = (Get-Date).ToUniversalTime().ToString("o")
8 Expiration = @{
9 Type = "AfterDuration"
10 Duration = "P180D"
11 }
12 }
13 Justification = "Graduate onboarding task GTIT-4471 - eligible assignment for time-bound Exchange admin access"
14}
15New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

Expected result: a response with Status equal to Provisioned and an Id for the schedule request. If you instead see PendingApprovalProvisioning, your tenant has an approval gate on eligibility creation itself, separate from activation approval — check the policy before assuming a fault. Capture the full response as JSON, plus a portal screenshot from Identity Governance, PIM, Microsoft Entra roles, Assignments, Eligible assignments, showing the new row with a 180-day expiry. Verify it shows under Eligible, not Active. If it shows Active, you used the assignment schedule endpoint by mistake — this is the single most frequent configuration error in this workflow.

#Step 4: Test activation as the end user

Sign in as the test account, or supervise the account owner doing so, and go to My Access, Privileged Identity Management, My roles, Microsoft Entra roles. Select Exchange Administrator and click Activate. Supply a justification string and complete the MFA challenge when prompted. If approval is required, the request moves to Pending and the approver receives a notification; once approved, the role becomes Active for the configured duration with a visible countdown. Capture the activation request Id, the approver’s decision timestamp, and the underlying audit entry.

1Get-MgAuditLogDirectoryAudit -Filter "activityDisplayName eq 'Add member to role completed (PIM activation)'" -Top 5 |
2 Select-Object ActivityDateTime, InitiatedBy, TargetResources

#Step 5: Stage the rollout beyond the test account

Do not apply this pattern to the entire admin population in one change. Once the test account has activated, been approved, and expired correctly, repeat the eligibility assignment for one real administrator on a Friday afternoon with low change risk, not during a live incident window. Only after that second cycle produces the same clean evidence should you open a change request covering the remaining Exchange Administrator holders as a batch. A staged rollout catches approver-group and licensing gaps against a small blast radius instead of the whole administrative team.

#Verification

Retain the following as your closure pack for the change record: the pre-change CSV baseline from Step 1, the policy rule JSON before and after from Step 2, the eligibility schedule request response from Step 3, and the activation audit log entry from Step 4. Additionally, confirm the role auto-deprovisions by re-running the active-assignment query after the activation window elapses.

Get-MgRoleManagementDirectoryRoleAssignmentScheduleInstance -Filter "roleDefinitionId eq '29232cdf-9323-42fd-ade2-1d097af3e4de'"

An empty result after expiry is the proof that matters. It demonstrates the time-bound control actually worked, not merely that it was configured with good intentions in a portal blade.

#Monitoring and change control

Configure an alert on the AuditLogs workspace for PIM activation and eligibility events so security operations sees activity outside business hours without waiting for a quarterly access review. Every future change to the role management policy — a new approver group, a longer activation duration, a scope change — must go through the same change record discipline used here: baseline captured, JSON before and after saved, evidence attached. Treat the approver group membership as a governed asset in its own right; review it on the same cadence as the access review for the role itself, because an empty approver group is a silent denial of service against your own administrators.

#Failure Modes and Common Traps

#Rollback

If the eligible assignment causes an operational problem — for example an approver group misconfiguration blocking a genuine incident responder — reverse it precisely. Do not delete things ad hoc.

1. Identify the eligibility schedule request Id created in Step 3, then terminate it.
   Terminal

   1$revoke = @{
   2 Action = "AdminRemove"
   3 PrincipalId = "5c2f8a3b-91e6-4a2e-8ab0-cc112d7e0f31"
   4 RoleDefinitionId = "29232cdf-9323-42fd-ade2-1d097af3e4de"
   5 DirectoryScopeId = "/"
   6}
   7New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $revoke

2. Revert the role management policy rules to their pre-change values captured in Step 2’s JSON export, using Update-MgPolicyRoleManagementPolicyRule with the original payload.
3. If the baseline in Step 1 showed a permanent active assignment prior to this change, restore it explicitly rather than assuming the tenant default.
   Terminal

   1New-MgRoleManagementDirectoryRoleAssignment -BodyParameter @{
   2 PrincipalId = "5c2f8a3b-91e6-4a2e-8ab0-cc112d7e0f31"
   3 RoleDefinitionId = "29232cdf-9323-42fd-ade2-1d097af3e4de"
   4 DirectoryScopeId = "/"
   5}

4. Close the change record noting the rollback reason and attach the terminated schedule request Id as evidence.

#Operational Summary

PIM does not make a tenant secure by existing — it makes a tenant secure when the activation controls are configured, tested with a real sign-in, and proven to expire. The pattern here — baseline, configure policy, create eligibility, test activation, stage the rollout, verify expiry, document rollback — applies unchanged whether you are onboarding Exchange Administrator, Security Administrator, or a custom role scoped to a single administrative unit. Treat every PIM change as you would a firewall rule change: assume it is wrong until you have evidence it behaves as intended under a real activation, not just a portal checkbox. The junior engineer who can produce that evidence pack unprompted is the one who gets handed the next privileged-role rollout without supervision.