Configuring PIM Settings and Assignments

Welcome to this in-depth exploration of Microsoft Entra Privileged Identity Management (PIM). In the world of modern cybersecurity, identity is the new perimeter. However, simply having an identity isn't enough; how we manage the elevated permissions associated with those identities determines the overall security posture of an organization. This lesson focuses on the granular configuration of PIM settings and the strategic assignment of roles to ensure that your most sensitive administrative powers are never left exposed.

Introduction to Privileged Identity Management (PIM)

At its core, Privileged Identity Management (PIM) is a service within Microsoft Entra ID that allows you to manage, control, and monitor access to important resources. These resources include roles in Entra ID, Azure resources (via RBAC), and even Microsoft 365 services like Exchange or SharePoint. The fundamental philosophy behind PIM is "Zero Standing Access." In a traditional environment, an administrator might have "Global Administrator" rights 24/7. This is known as standing access. If that account is compromised at 3:00 AM on a Sunday, the attacker immediately has full control over the entire tenant.

PIM changes this dynamic by introducing "Just-In-Time" (JIT) access. Instead of having permanent rights, users are made "eligible" for a role. When they need to perform an administrative task, they must "activate" that role, often providing a justification, performing Multi-Factor Authentication (MFA), or waiting for an approver to grant permission. Once the task is done or the time limit expires, the permissions are automatically revoked. This significantly reduces the attack surface of your organization because, for the vast majority of the time, no one actually has active administrative privileges.

Understanding how to configure these settings and manage these assignments is the difference between a tool that provides real security and a tool that simply adds friction to an administrator's day. We will look at how to strike the right balance between strict security controls and operational efficiency.

Callout: Zero Standing Access vs. Least Privilege While "Least Privilege" focuses on giving a user only the specific permissions they need to do a job, "Zero Standing Access" focuses on when they have those permissions. You should use both. A user should only be eligible for the specific role they need (Least Privilege), and they should only have that role active when they are actually working (Zero Standing Access).

Understanding PIM Role Settings

Before you assign roles to users, you must define the "rules of engagement" for those roles. In PIM, these are called Role Settings. Every role—whether it is an Entra ID role like "User Administrator" or an Azure Resource role like "Owner"—has its own set of configurable policies. These policies dictate what a user must do to activate the role and what happens once they do.

Activation Max Duration

The activation duration is the maximum amount of time a role stays active after a user requests it. By default, this is often set to 8 hours. However, you should evaluate this based on the specific role. For a Helpdesk Administrator, 8 hours might be appropriate for a full shift. For a Global Administrator, you might want to limit this to 2 or 4 hours to ensure that highly sensitive permissions are returned as quickly as possible.

Requirements on Activation

This is where the "Security" in PIM really happens. You can enforce several requirements:

• MFA Requirement: You should almost always require Multi-Factor Authentication upon activation. Even if the user is already signed in with MFA, PIM can force a fresh MFA prompt to ensure the person requesting the elevation is truly the authorized user.
• Justification: Requiring a text-based justification creates an audit trail. It forces the admin to state why they are elevating their privileges (e.g., "Updating DNS records for the new marketing site").
• Ticket Information: Many organizations use ticketing systems like ServiceNow or Jira. You can require a ticket number during activation, which allows auditors to cross-reference administrative actions with approved change requests.
• Approval Requirement: For the most sensitive roles, you should require manual approval. When a user tries to activate the role, a notification is sent to a designated set of approvers. The role is not granted until an approver clicks "Approve."

Notifications

PIM can send emails when roles are assigned, when they are activated, or when activation requests are pending. While it is tempting to turn on all notifications, "alert fatigue" is a real risk. Best practice suggests sending activation alerts for highly sensitive roles (like Global Admin or Billing Admin) to a security operations center (SOC) or a shared mailbox monitored by a security team.

Step-by-Step: Configuring Role Settings

Let’s walk through the process of configuring settings for a specific role in Microsoft Entra ID.

1. Navigate to the Microsoft Entra admin center.
2. In the left-hand menu, expand Identity Governance and select Privileged Identity Management.
3. Under the "Manage" section, select Microsoft Entra roles.
4. In the left-hand sidebar, click on Settings. This will show you a list of all available roles.
5. Search for a role, such as Helpdesk Administrator, and click on the role name.
6. Click Edit at the top of the page.
7. Activation Tab: Set the "Activation maximum duration" (e.g., 4 hours). Check the box for "On activation, require Azure MFA."
8. Requirement Tab: Choose whether to require justification or ticket information. If you want to require approval, toggle "Require approval to activate" to Yes and select specific users or groups as approvers.
9. Assignment Tab: Here you can decide if "Permanent" assignments are allowed. In a high-security environment, you should uncheck "Allow permanent eligible assignment" to force a yearly or half-yearly review of who has access.
10. Notification Tab: Review which roles receive emails for different actions. Ensure the "Admin" notifications are going to a monitored security mailbox rather than just the individual user.
11. Click Update to save your changes.

Note: Changes to PIM settings are not retroactive. If a user is already active in a role, the new settings (like a shorter duration) will only apply the next time they attempt to activate the role.

Managing Role Assignments

Once the settings are configured, you can begin assigning roles to users. In PIM, there are two primary types of assignments: Eligible and Active. Understanding the difference is vital for a successful implementation.

Eligible Assignments

An eligible assignment means the user has the "potential" to use the role. They do not have the permissions yet. They must go through the activation process we defined in the settings (MFA, justification, etc.) to actually gain the permissions. This is the preferred method for almost all administrative tasks.

Active Assignments

An active assignment means the user has the permissions immediately and permanently (or for a set duration) without needing to perform any activation steps. You should use active assignments very sparingly. One common use case is for "Service Principals" or "Managed Identities" that need to perform automated tasks and cannot perform MFA or provide justifications. For human users, active assignments should generally be avoided except for "Break-glass" accounts (which we will discuss later).

Assignment Scopes

Assignments can be scoped at different levels:

• Directory Level: The user has the role across the entire Entra ID tenant.
• Resource Level: For Azure resources, you can assign a role (like "Virtual Machine Contributor") at the Subscription level, the Resource Group level, or even for a single specific Resource.

Time-Bound Assignments

When making an assignment, you can choose between "Permanent" and "Time-bound." Even for an "Eligible" assignment, it is a best practice to make it time-bound. For example, you might grant a contractor "Eligible" access to the "Application Developer" role for only three months. After three months, the assignment expires automatically, and they can no longer activate the role.

Callout: PIM for Groups (Privileged Access Groups) A relatively newer feature is the ability to manage group memberships via PIM. Instead of making a user eligible for a role, you make them eligible for membership in a group. If that group is then assigned to multiple roles or applications, the user gains access to everything the group can do just by activating their group membership. This is much easier to manage at scale than individual role assignments.

Practical Example: Automating PIM Assignments with PowerShell

While the UI is great for small changes, large organizations often need to automate PIM assignments. We can use the Microsoft Graph PowerShell module to manage these assignments.

The following script demonstrates how to create a new "Eligible" assignment for a user to the "User Administrator" role.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory", "Directory.Read.All"

# Define variables
$userId = "user-object-id-here"
$roleDefinitionId = "fe930be7-5e62-47db-91af-98c3a49a38b1" # ID for User Administrator
$directoryScopeId = "/" # Root scope for the directory

# Create the schedule for the assignment (e.g., starts now, lasts for 1 year)
$schedule = @{
    StartDateTime = Get-Date
    Expiration = @{
        Type = "AfterDuration"
        Duration = "P365D"
    }
}

# Create the role assignment request
New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -Action "AdminAssign" `
    -PrincipalId $userId `
    -RoleDefinitionId $roleDefinitionId `
    -DirectoryScopeId $directoryScopeId `
    -ScheduleInfo $schedule `
    -Justification "Assigning User Admin role for helpdesk duties via automation"

Write-Host "Role assignment successfully requested."

Explanation of the Code:

1. Connect-MgGraph: We use specific scopes that allow us to read and write directory role assignments.
2. RoleDefinitionId: Every Entra ID role has a unique, static GUID. You can find these in the Microsoft documentation. For example, fe930be7-5e62-47db-91af-98c3a49a38b1 always represents the "User Administrator" role.
3. ScheduleInfo: This is a crucial part of PIM. We aren't just giving the role; we are defining the schedule. In this case, we use P365D (ISO 8601 duration format) to indicate the eligibility lasts for 365 days.
4. New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest: This is the specific cmdlet for PIM. Unlike standard Entra ID roles, PIM uses "Schedule Requests" to manage the lifecycle of the assignment.

Best Practices for PIM Configuration

To get the most out of PIM, you should follow industry-standard best practices. Simply turning it on isn't enough; it must be configured strategically.

1. The Rule of Two (Approvers)

Never have a single person who can approve their own requests or be the only approver for a highly sensitive role. For roles like Global Administrator, ensure there is a pool of at least 3-5 potential approvers. This ensures that someone is always available to approve a legitimate request and that no single individual has unchecked power.

2. Use "Break-Glass" Accounts

While PIM is great, it relies on the Entra ID infrastructure and MFA services being operational. If there is a massive regional outage affecting MFA, your admins might not be able to activate their roles to fix the issue. You should maintain 2-3 "Emergency Access" or "Break-glass" accounts. These accounts should:

• Have the Global Administrator role assigned permanently (Active assignment).
• Use a very long, complex password stored in a physical safe.
• Exempt them from PIM and Conditional Access policies (including MFA).
• Be monitored with high-priority alerts so you know the moment someone logs into them.

3. Minimize the Number of Global Administrators

The Global Administrator role is the "God mode" of your tenant. You should aim for no more than 5 eligible Global Administrators. Most tasks can be performed with more granular roles like "Exchange Administrator," "Security Administrator," or "User Administrator." Use PIM to make these granular roles the default choice for your team.

4. Enable Access Reviews

PIM settings allow you to require periodic access reviews. This is a process where a manager or the users themselves must confirm they still need the role. If they don't respond or if the manager denies it, PIM automatically removes the assignment. This prevents "permission creep," where users accumulate roles over years as they move between different projects.

5. Require MFA for All Activations

Even if your users are in a "Trusted Location" (like the corporate office), you should still require MFA for PIM activation. This protects against an attacker who has gained physical access to an unlocked workstation or has compromised a device within the network.

Comparison: Entra ID Roles vs. Azure Resource Roles in PIM

It is important to understand that PIM handles Entra ID roles (Identity-focused) and Azure Resource roles (Infrastructure-focused) slightly differently.

Warning: To manage Azure Resources in PIM, you must first "discover" them. If you go to PIM > Azure Resources and don't see your subscription, you must click "Discover Resources," select the subscription, and click "Manage Resource." Only then can you configure PIM settings for that subscription's RBAC roles.

Common Pitfalls and How to Avoid Them

Even with the best intentions, PIM implementations can go wrong. Here are some common mistakes to watch out for.

Over-complicating the Approval Process

If every single role requires approval from a busy executive, admins will eventually find workarounds or simply stop using the tool correctly. For low-impact roles (like "Message Center Reader"), don't require approval. Save the manual approval steps for roles that can actually delete data or change security configurations.

Forgetting About Service Accounts

If you move all your Global Admin roles to PIM "Eligible" assignments, but you have an old PowerShell script running on a local server using a Global Admin account, that script will break. Service accounts cannot "activate" roles in the PIM UI. For these accounts, you must either use an "Active" assignment (and secure the account heavily) or, preferably, migrate the script to use a Managed Identity or Service Principal with only the specific permissions it needs.

Ignoring PIM Alerts

PIM generates a lot of data. If you aren't monitoring the "PIM Alerts" section, you might miss suspicious activity. For example, PIM will alert you if there are "too many global administrators" or if roles are being assigned outside of PIM. Regularly review these alerts and remediate the underlying issues.

License Requirements

PIM requires Microsoft Entra ID P2 or Microsoft 365 E5 licenses. A common mistake is assigning PIM roles to users who only have P1 or Basic licenses. While the UI might technically allow the assignment, you will be out of compliance with Microsoft's licensing terms, and certain features may fail to function as expected. Ensure every user who is "Eligible" for a role, every user who "Activates" a role, and every user who "Approves" a request has the appropriate license.

Troubleshooting PIM Activations

Sometimes users will report that they cannot activate their roles. Here is a quick checklist for troubleshooting:

1. Check the License: Does the user have an Entra ID P2 license?
2. MFA Status: Has the user registered for MFA? If the PIM setting requires MFA but the user hasn't set up a phone or authenticator app, the activation will fail.
3. Browser Issues: PIM relies heavily on cookies and session tokens. If a user is having trouble, ask them to try an InPrivate/Incognito window.
4. Pending Approvals: If a role requires approval, the user won't get the permissions until the approver acts. Check the "Pending Requests" tab in the PIM console.
5. Assignment Expiration: Check if the user's eligibility has expired. If they were granted access for 6 months and that time has passed, the role will no longer appear in their "My Roles" list.

Advanced Scenario: Using PIM for Just-In-Time VM Access

While PIM is usually discussed in the context of roles, it can also be integrated with other security features. For example, you can use PIM in conjunction with Azure Resource roles to provide JIT access to Virtual Machines.

Imagine a developer who needs to RDP into a production server to debug an issue.

1. The developer is "Eligible" for the Virtual Machine Contributor role on that specific VM's Resource Group.
2. The developer goes to PIM and activates the role for 2 hours.
3. Once the role is active, the developer can then use Azure Network Watcher or Microsoft Defender for Cloud to request JIT VM Access, which opens the RDP port (3389) on the Network Security Group for their specific IP address.

This "Defense in Depth" approach ensures that even if the developer has the RBAC role, the network port is still closed until they specifically request it. This combination of PIM (Identity) and JIT VM Access (Network) is a hallmark of a mature security environment.

Conclusion

Configuring PIM settings and assignments is not a "set it and forget it" task. It requires a deep understanding of your organization's administrative workflows and a commitment to the principle of least privilege. By moving away from standing access and toward a JIT model, you drastically reduce the window of opportunity for attackers.

Remember that PIM is as much about culture as it is about technology. Admins may initially resist the extra steps of MFA and justification. However, by explaining the "why"—protecting the organization and the admins themselves from the consequences of a compromised account—you can build a more secure and resilient identity infrastructure.

Key Takeaways

• Zero Standing Access: The goal of PIM is to ensure that no user has administrative privileges permanently. Access should be granted "Just-In-Time" and revoked automatically.
• Eligible vs. Active: Always prefer "Eligible" assignments for human users. "Active" assignments should be reserved for service accounts or emergency "Break-glass" accounts.
• MFA is Non-Negotiable: Every privileged role activation should require Multi-Factor Authentication, regardless of the user's current session state.
• Granular Settings: Don't apply the same settings to every role. Sensitive roles (Global Admin) should have shorter durations and require manual approval, while lower-impact roles can be more permissive.
• Automation and Governance: Use the Microsoft Graph API to manage PIM at scale, and use Access Reviews to ensure that permissions don't linger longer than they are needed.
• Scope Matters: Use Azure RBAC scopes (Subscription, Resource Group) to limit the impact of a role. Don't give someone "Owner" on a whole subscription if they only need to manage one Resource Group.
• Licensing and Compliance: Ensure all users interacting with PIM (requestors and approvers) are properly licensed with Entra ID P2/Microsoft 365 E5.