Planning Privileged Identity Management

In the modern landscape of cybersecurity, the traditional perimeter has evaporated. We no longer rely solely on firewalls to protect our data because our users, devices, and applications live everywhere. In this world, identity is the new control plane. However, having identity as a control plane introduces a significant risk: if an attacker gains control of a highly privileged identity, they effectively own the entire environment. This is where Privileged Identity Management (PIM) becomes a critical component of your security strategy.

Privileged Identity Management is a service that allows you to manage, control, and monitor access to important resources within your organization. These resources include access to Microsoft Entra ID (formerly Azure AD), Azure resources, and other Microsoft Online Services like Microsoft 365 or Microsoft Intune. The goal of PIM is to move away from "standing access"—where a user has administrative rights 24/7—and move toward "just-in-time" access. By ensuring that users only have the permissions they need, exactly when they need them, and for a limited duration, you drastically reduce the attack surface of your organization.

In this lesson, we will explore the intricacies of planning a PIM implementation. We will look at the technical requirements, the governance strategies, and the practical steps needed to transition an organization from a state of permanent administrative over-privilege to a secure, audited, and time-bound access model.

The Problem with Standing Access

To understand why PIM is necessary, we must first look at the risks associated with permanent administrative privileges, often referred to as standing access. In many traditional IT environments, an administrator is granted a role, such as "Global Administrator" or "Domain Admin," and they keep that role indefinitely. Their account always possesses the power to change configurations, delete data, or create new users.

If that administrator’s account is compromised—perhaps through a sophisticated phishing attack or a password spray—the attacker immediately inherits those 24/7 privileges. The attacker doesn't need to wait for a specific window of time; they can begin exfiltrating data or installing ransomware at 2:00 AM on a Sunday when no one is watching. Furthermore, standing access often leads to "privilege creep," where users accumulate more and more permissions over years of moving between different projects or departments, and those permissions are never revoked.

Callout: Standing Access vs. Just-In-Time (JIT) Access

Standing Access: A user is assigned a role permanently. They have administrative rights at all times, regardless of whether they are performing administrative tasks. This increases the risk of accidental configuration changes and provides a permanent target for attackers.

Just-In-Time (JIT) Access: A user is "eligible" for a role but does not have the permissions active by default. When they need to perform a task, they request activation. If approved, the permissions are granted for a specific window (e.g., 4 hours) and then automatically revoked.

Core Concepts of Privileged Identity Management

Before diving into the planning phase, it is essential to understand the terminology and mechanisms that make PIM function. PIM operates on the principle of "Eligible" assignments versus "Active" assignments.

Eligible Assignments

When you make a user "eligible" for a role, it means they do not have the role's permissions yet. Instead, the role is sitting in their "Eligible roles" list. To actually use the permissions, the user must perform an activation step. During this step, you can require them to provide a business justification, solve a Multi-Factor Authentication (MFA) prompt, or wait for an approval from a designated manager.

Active Assignments

An "active" assignment is what we traditionally think of as a role assignment. The user has the permissions right now. In a PIM environment, we try to minimize permanent active assignments. However, active assignments in PIM can also be time-bound. For example, you might grant a contractor active "Owner" rights on a specific Azure subscription, but configure PIM so that the assignment automatically expires in six months.

Just-In-Time (JIT) Activation

This is the process of moving from eligible to active. When a user activates a role, the system grants them the permissions for a pre-configured duration. Once that duration expires, PIM automatically removes the assignment. This ensures that even if a user forgets to "sign out" of their administrative session, the system closes the door for them.

Access Reviews

Access reviews are a governance feature within PIM that allows administrators or managers to periodically review who has access to sensitive roles. Instead of permissions lasting forever, the system asks, "Does Sarah still need to be an Exchange Administrator?" If the reviewer says no, or if they don't respond within the window, the access can be automatically revoked.

Planning Your PIM Implementation

Planning for PIM is not just a technical exercise; it is a cultural shift for your IT and security teams. Administrators who are used to having permanent rights may initially resist the extra steps required to activate a role. Therefore, a successful plan must balance security with usability.

Step 1: Identify High-Risk Roles

Not every role needs to be managed by PIM immediately. You should start with the "keys to the kingdom." In Entra ID, these are roles that have the power to impact the entire tenant.

• Global Administrator: Can manage all aspects of Entra ID and Microsoft services.
• Privileged Role Administrator: Can manage role assignments in PIM itself.
• Security Administrator: Can read security reports and manage security policies.
• Billing Administrator: Can make purchases and manage subscriptions.
• User Administrator: Can reset passwords for users (a high-risk activity for account takeover).

In addition to Entra ID roles, identify sensitive Azure Resource roles. Roles like "Owner" or "User Access Administrator" at the Management Group or Subscription level should almost always be managed via PIM.

Step 2: Define Activation Policies

For each role, you need to decide what the "hurdles" for activation will be. A standard policy might look like this:

• MFA Requirement: Always require MFA for activating any privileged role. This ensures that even if a password is stolen, the attacker cannot activate the administrative rights.
• Maximum Duration: How long does a typical task take? For a Helpdesk Administrator, 8 hours might be appropriate. For a Global Admin performing a specific configuration change, 2 hours might be safer.
• Justification: Require users to enter a ticket number or a description of the work they are doing. This is invaluable for later audits.
• Approvals: For the most sensitive roles (like Global Admin), require a second person to approve the activation request.

Step 3: Licensing and Technical Requirements

PIM requires specific licensing. As of the current standards, you generally need Microsoft Entra ID P2 or Microsoft 365 E5/G5 licenses. It is important to note that you need licenses for the users who will be performing the activations, the users who will be approving them, and the users who will be performing access reviews.

Note: Always verify current licensing requirements with your Microsoft representative, as these can change. Generally, any user who "benefits" from the PIM service (by being eligible for a role) needs to be covered by a P2 license.

Technical Configuration: Setting Up a Role

Let's look at how we actually configure a role for PIM. While this is often done through the Entra portal, understanding the logic behind the configuration is key.

Example: Configuring the "Exchange Administrator" Role

Suppose we want to protect the Exchange Administrator role. We want to ensure that any admin who needs to change mail flow rules must provide a reason and use MFA.

1. Navigate to PIM: Open the Entra portal and search for "Privileged Identity Management."
2. Select Entra ID Roles: Go to "Manage" and then "Roles."
3. Find the Role: Search for "Exchange Administrator."
4. Edit Settings: Click on "Settings" in the top bar. Here you define the rules of engagement.
   • Activation maximum duration: Set to 4 hours.
   • On activation, require: Check "Azure MFA."
   • Require justification: Set to "Yes."
   • Require ticket information: Set to "Yes" (this adds a field for a ticket ID).
   • Require approval to activate: Set to "Yes" and select a group of Senior Admins as the approvers.

Role Setting Comparison Table

Automation and Scripting with Microsoft Graph

For organizations with many roles or multiple tenants, configuring PIM through the GUI is inefficient and prone to human error. We can use the Microsoft Graph API or PowerShell to manage PIM assignments and settings.

Using the Microsoft.Graph PowerShell module, we can interact with role definitions and assignments. Below is an example of how you might check which users are currently eligible for a specific role.

# Connect to Microsoft Graph with the necessary scopes
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory", "RoleManagement.Read.Directory"

# Get the Role Definition ID for 'Global Administrator'
$roleDefinition = Get-MgDirectoryRoleDefinition -Filter "DisplayName eq 'Global Administrator'"

# List all eligible role assignments for this specific role
Get-MgRoleManagementDirectoryRoleEligibilitySchedule -Filter "RoleId eq '$($roleDefinition.Id)'" | Select-Object Id, PrincipalId, Status

Explanation of the code:

1. Connect-MgGraph: We need specific permissions to read role management data. "RoleManagement.ReadWrite.Directory" allows us to see and modify these settings.
2. Get-MgDirectoryRoleDefinition: We search for the internal ID of the "Global Administrator" role. In Entra ID, everything is referenced by a GUID (Globally Unique Identifier), not just the name.
3. Get-MgRoleManagementDirectoryRoleEligibilitySchedule: This command retrieves the list of users who are "Eligible" (not necessarily active) for the role. This is useful for auditing who could potentially become an admin.

To programmatically assign a user as eligible for a role, you would use a JSON payload sent via a POST request to the Graph API. This is how "Infrastructure as Code" (IaC) tools like Terraform or Bicep manage identity.

// Example JSON payload for creating a role eligibility schedule
{
  "action": "AdminAssign",
  "justification": "Assigning eligibility for project migration",
  "roleDefinitionId": "fe930be5-b33e-4054-87f3-21c35038ef79",
  "directoryScopeId": "/",
  "principalId": "00000000-0000-0000-0000-000000000000",
  "scheduleInfo": {
    "startDateTime": "2023-10-01T00:00:00Z",
    "expiration": {
      "type": "afterDuration",
      "duration": "P365D"
    }
  }
}

In this JSON snippet, we define the principalId (the user's ID) and the roleDefinitionId. The scheduleInfo tells PIM that this eligibility should last for 365 days (P365D), after which the user will no longer be able to request activation unless they are re-assigned.

Planning for Emergency Access (Break-Glass Accounts)

One of the most common pitfalls in a PIM implementation is "locking the door so well that even you can't get in." If Entra ID experiences an MFA service outage, or if your PIM configuration has a logic error that prevents anyone from activating the Global Admin role, you could be locked out of your own tenant.

To prevent this, you must plan for Emergency Access Accounts, often called "Break-Glass" accounts.

1. Exempt from PIM: These accounts should have a permanent, standing assignment of the Global Administrator role.
2. Exempt from MFA: These accounts should not rely on the same MFA provider as the rest of your users. Ideally, use a very long, complex password stored in a physical safe.
3. Cloud-Only: Do not sync these accounts from an on-premises Active Directory. They must live entirely in the cloud to ensure they work even if your local network or sync tools are down.
4. Monitored: Create an alert in Microsoft Sentinel or Entra ID that triggers whenever someone logs into a break-glass account. Since these accounts should never be used under normal circumstances, any login is a major event.

Warning: Never delete your break-glass accounts or subject them to the same PIM activation policies as your regular admins. If the PIM service itself is unreachable, these accounts are your only way to recover.

Implementation Strategy: The Phased Rollout

Changing how admins work can be disruptive. A phased rollout is highly recommended to ensure that business operations are not hindered while security is tightened.

Phase 1: The Pilot Group

Start with your own IT security team. Since you are the ones implementing the tool, you are best equipped to handle any initial friction. Move all security team members from permanent "Security Administrator" roles to eligible roles.

Phase 2: High-Privilege Roles

Once the pilot is successful, move the Global Administrators to PIM. This is usually a small group of people (ideally 2-4 people). Ensure they understand the process of requesting activation and that they have the necessary MFA methods registered.

Phase 3: Broad IT Roles

Expand to the rest of the IT department: Exchange Admins, SharePoint Admins, Intune Admins, and Helpdesk. This is where you will likely encounter the most feedback regarding the "extra steps." Use this phase to fine-tune the activation duration. If Helpdesk admins find they have to re-activate three times a day, consider extending their duration from 4 hours to 8 hours.

Phase 4: Azure Resource Owners

Finally, bring Azure resource management under PIM. This involves working with application owners and developers. Because Azure RBAC (Role-Based Access Control) can be very granular, this phase often takes the longest to plan.

Callout: PIM for Groups

A relatively new and powerful feature is "PIM for Groups." Instead of making a user eligible for a role directly, you make them eligible for membership in a security group. When they activate their "membership," they inherit all the roles and permissions assigned to that group. This is much easier to manage at scale than individual role assignments.

Monitoring and Governance

Once PIM is running, the work isn't over. You must monitor its use to ensure it's effective and that admins aren't finding ways to bypass security.

Audit Logs

PIM keeps a detailed history of every action. You can see:

• Who requested a role activation.
• The justification they provided.
• Who approved the request (if applicable).
• When the activation expired.

These logs should be exported to a Log Analytics workspace or a SIEM (like Microsoft Sentinel) for long-term retention and analysis. If you see a user activating a role every single day at the same time, you might want to investigate if they actually need a more streamlined process or if there is an automated task they should be using a Service Principal for instead.

Access Reviews

Access reviews are the "cleanup" mechanism. You should schedule quarterly access reviews for all privileged roles. During a review, PIM sends an email to the reviewer (usually a manager) listing all users who are currently eligible for a role.

If a reviewer sees a user who has left the department but still has eligibility for "Billing Administrator," they can deny the access. PIM will then automatically remove that user's eligibility. This prevents the "privilege creep" mentioned earlier.

Common Pitfalls and How to Avoid Them

Even with a great plan, there are common mistakes that organizations make when deploying PIM.

1. Requiring Approval for Everything

If you require a manager's approval for every single helpdesk password reset, you will create a bottleneck. Managers will eventually start "rubber-stamping" every request without looking at it just to clear their inbox.

• Solution: Only require approval for the most sensitive roles. For lower-tier roles, rely on MFA and business justification.

2. Ignoring "Active" Assignments

Sometimes, admins will grant "Active" assignments in PIM because they are in a rush, effectively bypassing the JIT mechanism.

• Solution: Periodically run a report to find any "Permanent Active" assignments. Unless it's a break-glass account, these should be converted to "Eligible."

3. Not Testing the "Approver" Workflow

If the only person who can approve a Global Admin activation is the CIO, and the CIO is on a plane without Wi-Fi, the IT team is stuck.

• Solution: Always define "Approval Groups" rather than individual approvers. Ensure there are at least 2 or 3 people who can approve requests for any given role.

4. Forgetting About Service Principals

PIM is designed for human identities. It does not manage Service Principals (applications) in the same way. If an application has permanent "Contributor" rights to a subscription, PIM won't stop an attacker who steals that application's secret.

• Solution: Use Workload Identity Premium features to manage and review application permissions, or use Managed Identities whenever possible.

Best Practices Summary

To wrap up our planning guide, let's look at the industry recommendations for a "Gold Standard" PIM implementation.

• Follow the Rule of Two: For critical roles, always require at least two people to be involved (one requester, one approver).
• Enforce MFA: Never allow a privileged role activation without a strong MFA check. This is your strongest defense against compromised credentials.
• Use Descriptive Justifications: Train your staff to provide meaningful justifications. "Fixing a bug" is poor; "Resolving ticket #12345 - modifying NSG rules for web server" is excellent.
• Automate Access Reviews: Set up recurring reviews so that you don't have to remember to do them manually. Let the system handle the reminders.
• Integrate with Ticketing: If your organization uses a tool like ServiceNow or Jira, try to integrate your PIM justifications with your ticket numbers for easier cross-referencing during audits.
• Keep it Simple: Don't create 50 different PIM policies. Group roles with similar risk profiles into the same policy settings to keep the environment maintainable.

Key Takeaways

1. Identity is the Perimeter: In a cloud-first world, protecting privileged identities is the most effective way to prevent large-scale data breaches and environment takeovers.
2. Eliminate Standing Access: The primary goal of PIM is to move from 24/7 administrative rights to Just-In-Time (JIT) access, where permissions are granted only when needed and for a limited time.
3. Eligible vs. Active: Understand that PIM works by making users "eligible" for roles. They must then "activate" those roles, satisfying security requirements like MFA and justification in the process.
4. Governance through Access Reviews: PIM isn't just about granting access; it's about removing it. Regular access reviews ensure that users don't retain permissions they no longer need for their job functions.
5. Emergency Access is Non-Negotiable: Always maintain "break-glass" accounts that are exempt from PIM and MFA to ensure you can recover your environment in the event of a service outage or configuration error.
6. Phased Rollout Strategy: Avoid "big bang" deployments. Start with a pilot group, then move to high-risk roles, and gradually expand to the rest of the IT organization to ensure a smooth transition.
7. Audit Everything: Use the detailed logs provided by PIM to monitor for unusual patterns of behavior and to provide a clear paper trail for compliance and security audits.