azure ad pim assignment type

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Assign Microsoft Entra roles in Privileged Identity Management

• 17 contributors

With Microsoft Entra ID, a Global administrator can make permanent Microsoft Entra admin role assignments. These role assignments can be created using the Microsoft Entra admin center or using PowerShell commands .

The Microsoft Entra Privileged Identity Management (PIM) service also allows Privileged role administrators to make permanent admin role assignments. Additionally, Privileged role administrators can make users eligible for Microsoft Entra admin roles. An eligible administrator can activate the role when they need it, and then their permissions expire once they're done.

Privileged Identity Management support both built-in and custom Microsoft Entra roles. For more information on Microsoft Entra custom roles, see Role-based access control in Microsoft Entra ID .

When a role is assigned, the assignment:

• Can't be assigned for a duration of less than five minutes
• Can't be removed within five minutes of it being assigned

Assign a role

Follow these steps to make a user eligible for a Microsoft Entra admin role.

Sign in to the Microsoft Entra admin center as at least a Privileged Role Administrator .

Browse to Identity governance > Privileged Identity Management > Microsoft Entra roles .

Select Roles to see the list of roles for Microsoft Entra permissions.

Select Add assignments to open the Add assignments page.

Select Select a role to open the Select a role page.

Select a role you want to assign, select a member to whom you want to assign to the role, and then select Next .

If you assign a Microsoft Entra built-in role to a guest user, the guest user will be elevated to have the same permissions as a member user. For information about member and guest user default permissions, see What are the default user permissions in Microsoft Entra ID?

In the Assignment type list on the Membership settings pane, select Eligible or Active .

Eligible assignments require the member of the role to perform an action to use the role. Actions might include performing a multifactor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Active assignments don't require the member to perform any action to use the role. Members assigned as active have the privileges assigned to the role at all times.

To specify a specific assignment duration, add a start and end date and time boxes. When finished, select Assign to create the new role assignment.

Permanent assignments have no expiration date. Use this option for permanent workers who frequently need the role permissions.

Time-bound assignments will expire at the end of a specified period. Use this option with temporary or contract workers, for example, whose project end date and time are known.

After the role is assigned, an assignment status notification is displayed.

Assign a role with restricted scope

For certain roles, the scope of the granted permissions can be restricted to a single admin unit, service principal, or application. This procedure is an example if assigning a role that has the scope of an administrative unit. For a list of roles that support scope via administrative unit, see Assign scoped roles to an administrative unit . This feature is currently being rolled out to Microsoft Entra organizations.

Browse to Identity > Roles & admins > Roles & admins .

Select the User Administrator .

​Select Add assignments .

On the Add assignments page, you can:

• Select a user or group to be assigned to the role
• Select the role scope (in this case, administrative units)
• Select an administrative unit for the scope

For more information about creating administrative units, see Add and remove administrative units .

Assign a role using Microsoft Graph API

For more information about Microsoft Graph APIs for PIM, see Overview of role management through the privileged identity management (PIM) API .

For permissions required to use the PIM API, see Understand the Privileged Identity Management APIs .

Eligible with no end date

The following is a sample HTTP request to create an eligible assignment with no end date. For details on the API commands including request samples in languages such as C# and JavaScript, see Create roleEligibilityScheduleRequests .

HTTP request

Http response.

The following is an example of the response. The response object shown here might be shortened for readability.

Active and time-bound

The following is a sample HTTP request to create an active assignment that's time-bound. For details on the API commands including request samples in languages such as C# and JavaScript, see Create roleAssignmentScheduleRequests .

Update or remove an existing role assignment

Follow these steps to update or remove an existing role assignment. Microsoft Entra ID P2 or Microsoft Entra ID Governance licensed customers only : Don't assign a group as Active to a role through both Microsoft Entra ID and Privileged Identity Management (PIM). For a detailed explanation, see Known issues .

Select Roles to see the list of roles for Microsoft Entra ID.

Select the role that you want to update or remove.

Find the role assignment on the Eligible roles or Active roles tabs.

Select Update or Remove to update or remove the role assignment.

Remove eligible assignment via Microsoft Graph API

The following is a sample HTTP request to revoke an eligible assignment to a role from a principal. For details on the API commands including request samples in languages such as C# and JavaScript, see Create roleEligibilityScheduleRequests .

• Configure Microsoft Entra admin role settings in Privileged Identity Management

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Nathan Nellans

Online Blog & Portfolio

• Oct 30, 2021

All about Azure Privileged Identity Management (PIM)

Updated: Aug 23, 2022

Introduction

Pim assignments.

- Eligible Assignments

- Active Assignments

What can PIM manage?

- Azure AD Roles

- Azure AD Groups

- RBAC Roles on Azure Resources

Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organization.

PIM can manage access to 3 different types of resources:

Azure AD roles

Azure AD groups

RBAC roles on Azure Resources

To keep this blog post from getting too big, I will only be covering the above features. PIM includes many more features that I will possibly cover in future blog posts.

Some examples of things you could do with PIM:

You hired a contractor for a 3 month contract. They need access to Azure AD in order to do their job. You could use PIM to assign the contractor to the Azure AD "Global Administrator" role, and you could have the assignment end on the exact date that the contract ends.

You created a special group in Azure AD and then gave that group access to a multitude of things in your environment. You could use PIM to control who is a member of that group. You could even use PIM to allow certain people the ability to request 'just-in-time' (JIT) access to that group.

PIM is very powerful and these are just a couple of examples of what it can do.

Unfortunately, PIM is not free. Azure AD Premium P2 licensing is required for all users who will be managed by PIM.

When using PIM to control access to resources, it essentially all boils down to making PIM "Assignments." PIM supports two different types of assignments: Eligible and Active.

Eligible Assignments

You can add Users or Groups to an Eligible Assignment.

Eligible Assignments require the user to take action. Users must manually activate the Assignment before it goes into effect.

Depending on the settings that are configured, there may be other requirements as well, such as requiring the user to type in a reason why they need the role, or requiring the user to authenticate with MFA.

An Eligible Assignment may also be configured for approval first, so before the assignment takes effect an administrator will first need to approve it.

Eligible Assignments can be:

Permanent, meaning the user will always be able to activate it when they need it.

For a fixed time frame, meaning the user can only activate it during a specific start date and end date.

Active Assignments

You can add Users, Groups, or Service Principals to Active Assignments.

Active Assignments do not require any action from the user.

Active Assignments can be:

Permanently assigned, meaning the user has the role forever.

For a fixed time frame, meaning the user has the role only during a specific start and end date.

1. Azure AD Roles

PIM can help you manage access to Azure AD roles.

You can control both built-in Azure AD roles and custom Azure AD roles.

You can assign Users, Groups, or Service Principals to an Azure AD role.

Note: You can only assign groups that were originally created with this option enabled: " AzureAD roles can be assigned to the group ."

Note: Service Principals only support Active Assignments, they do not support Eligible Assignments.

Depending on the Azure AD role that you select, you may or may not be able to pick a particular Scope. A majority of the roles are scoped to Directory and there is no way to change that. However, some roles allow you to pick from multiple different Scopes. For example, the User Administrator role allows you to choose a Scope of Directory or Administrative Unit . Likewise, the Application Administrator role allows you to choose a Scope of Directory , Application , or Service Principal .

2. Azure AD Groups

PIM can help you manage access to Groups in Azure AD.

This feature is still in Preview, so be warned!

In the Portal this is called Privileged Access Groups .

You can control Security or Microsoft 365 groups. You can NOT control synced groups.

The group you want to control must have been originally created with this option enabled: " AzureAD roles can be assigned to the group ."

You can assign Users, Groups, or Service Principals to an Azure AD Group.

Note: Microsoft does NOT recommend assigning a group to a group with PIM (nesting groups), however, it is technically possible to do so.

For the Scope of the group in question, you can assign objects to be a Member of the group, or you can assign objects to be an Owner of the group.

3. RBAC Roles on Azure Resources

PIM can help you manage who is assigned to RBAC Roles on your Azure Resources.

In the portal this is simply called Azure Resources .

You can control RBAC roles on 4 different types of resources: Management Groups, Subscriptions, Resource Groups, or individual Resources. You can use both built-in RBAC roles or custom RBAC roles.

You can assign Users, Groups, or Service Principals to a particular RBAC role on a particular Resource.

There is a lot more to PIM that I could write about. I may eventually do a part 2 of this article, including topics such as automating PIM through PowerShell, how to enable and configure PIM settings on the 3 different types of resources, as well as how to create Assignments for the 3 different types of resources. So, be on the look out!

References:

- Plan a PIM deployment

- License requirements to use PIM

Such a nice article! I wonder if you have your part 2 having more info on Automation part?

Abou Conde's Blog

Cloud and infra security, assigning azure resource roles in privileged identity management (pim).

• by Abou Conde
• Posted on July 12, 2019 July 11, 2019

Azure Active Directory (Azure AD) Privileged Identity Management (PIM) can manage the built-in Azure resource roles, as well as custom roles, including (but not limited to):

• User Access Administrator
• Contributor
• Security Admin
• Security Manager, and more

Assign a role 

Sign in to Azure portal with a user that is a member of the Privileged Role Administrator role.

Open Azure AD Privileged Identity Management .

If you haven’t started PIM in the Azure portal yet, go to Enabling Azure AD Privileged Identity Management (PIM) .

Click Azure resources .

Use the Resource filter to filter the list of managed resources.

Click the resource you want to manage, such as a subscription or management group.

Under Manage, click Roles to see the list of roles for Azure resources.

Click Add member to open the New assignment pane .

Click Select a role to open the Select a role pane, Click a role you want to assign and then click Select .

The Select a member or group pane opens.

Click a member or group you want to assign to the role and then click Select .

The Membership settings pane opens.

In the Assignment type list, select Active and click ok

PIM for Azure resources provides two distinct assignment types:

• Active assignments don’t require the member to perform any action to use the role. Members assigned as active have the privileges assigned to the role at all times.
• Eligible assignments require the member of the role to perform an action to use the role. Actions might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Verify that the User is listed as the member of the Active roles.

Share this:

One thought on “ assigning azure resource roles in privileged identity management (pim) ”.

Hi, I was trying to do something where I needed a subscription ID but I don’t have/see one. Would that mean I don’t have the role associated with that subscription? Is that how it works? Thank you for your time.

Leave a comment Cancel reply

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

Assign Azure Privileged Identity Management Roles using Bicep

Azure Privileged Identity Management (PIM) is a tool that allows you to provide Just In Time (JIT) access to Azure RBAC roles. Using PIM, you can create a role assignment to make a user or group eligible for a role. This assignment doesn’t mean that the user or group has the role, but instead that they can request the role when they need it. When this occurs, the user can trigger an elevation request to be granted the role for a short period (usually hours, but definable). Rules can then be applied to their request, such as requiring approval, requiring a ticket number and so on, and then the rights are granted. PIM is a great tool for removing many permanent access rights to users, but it does require an Azure AD P2 licence for each user.

PIM is an Azure AD feature, so I assumed it wouldn’t be possible to create PIM assignments using Bicep (or ARM), but it is possible. PIM roles are often application or service-specific, so being able to create them as part of your Infrastructure as Code is quite helpful.

Creating PIM Assignments

To create a PIM assignment, we are going to use the Microsoft.Authorization/roleEligibilityScheduleRequests , the full API sec for this can be found here . This object can be used for more than just creating an assignment, it can, in theory, be used to activate an assignment, remove assignments and more. We’ll focus on creating and updating assignments.

To be able to use this, we are going to need a couple of pieces of information:

The object ID of the user or group you want to assign the role to. This can be found by looking at the user or group in AAD. You’re looking for the object ID field

The complete ID of the role you want to assign. This is usually in the format:

Subscription ID is the ID of the subscription holding the role you want to assign. The role ID is the GUID of the role. You can find the GUID’s for all the built-in roles in the MS docs here , or you can also use the handy AzRoleAdvertizer site . If you’re applying the assignment at the management group rather than subscription or resource, you will replace this with the ID of the management group role.

With this information, we can create the Bicep code we need. First, we need to get the start date for the role in the correct format. The format is 2022-04-10T14:40:08.067566 but fortunately, the Bicep utcNow function gets this in the correct format, so we can use that. This function can only be used as a default value for a parameter, so we need to create a parameter in our template that we assign this to and won’t override in the future.

Now we have that we can create the actual resource:

A few things to note:

• The name needs to be a GUID, so I am using the guid function to generate one, passing the resource group and a string as a seed to ensure a consistent GUID generation should I run this again
• The request type is set to AdminUpdate. This will create a role if it doesn’t exist and update it if it does. You can use AdminCreate if you want only to create it.
• The schedule info section is setting that the user or group should be eligible to elevate for a year (the max allowed) before the role needs to be reviewed
• I have set the scope to be the resource group. This defines that the PIM role should be for this resource group only. If I wanted to assign rights to elevate over a whole subscription or management group, then I would adjust the scope

The whole template looks like this:

Once deployed, you should be able to go to the PIM UI in the portal and see that the designated user or group is now eligible to elevate to this role.

Creating an Intune Azure AD Device Admins group and assigning the Privileged Identity Management Role via Powershell

This post will cover how to create a new Azure PIM Eligible assignment and link it to an Azure AD group, but all done via Powershell.

For Azure AD joined devices, using Privileged Identity Management and the built-in Device Administrators role you can control who has access to be a machine admin and for how long, with full auditing in place. By linking this to a group, it takes the admin overhead away when dealing with staff changes etc.

As always, the script can be found on GitHub here

To start, we need to install the AzureAD Preview Powershell module (if it isn’t already installed):

This can run alongside the non-preview so we now need to import it, but making sure the non-preview isn’t running first:

Now connect to Azure AD:

Now that part is out of the way, we can start the fun bit!

First up, group creation. The important thing to note here is the -IsAssignabletoRole $True switch at the end. This is a fairly new feature which allows groups to be assigned to a PIM role (as I’m sure you had guessed)

Next up we need the AAD Tenant ID, you could hard-code, but I prefer re-usable scripts:

Now we need to find the PIM role for “Azure AD Joined Device Local Administrator”

The assignment will need a schedule. I’m setting it from the minute it’s run with no end-date:

The next part needs to query the Azure AD group and the script runs quite quickly so I’ve added a pause to let Azure catch up:

And finally, create the role using the AAD group ID, the Role ID and the schedule previously created

Just like magic, you have a PIM role configured.

One fairly big thing to note: PIM does require Azure AD P2 licensing, so make sure you have that in place!

Leave a Comment Cancel reply

Save my name, email, and website in this browser for the next time I comment.

Accessibility

visibility_off Disable flashes

title Mark headings

settings Background Color

zoom_out Zoom out

zoom_in Zoom in

remove_circle_outline Decrease font

add_circle_outline Increase font

spellcheck Readable font

brightness_high Bright contrast

brightness_low Dark contrast

format_underlined Underline links

font_download Mark links

Reset all options cached

AAD Support Notes

Random thoughts from an aad support engineer, automating azure privileged identity management (pim) with powershell.

On a recent support case we had a customer who was trying to automate Privileged Identity Management (PIM) role assignments for Azure Resources with PowerShell. We could not find any public end to end documentation on the syntax to make this work. After some trial and error we found the following syntax works.

NOTE: PIM can assign both Azure AD roles and Azure resource roles so both scenarios are shown below. Additionally, make sure you have the latest version of AzureADPreview module installed .

Assigning Azure AD roles

For this scenario there is a public doc explaining the syntax which can be found at PowerShell for Azure AD roles in Privileged Identity Management . For roleDefinitionID you can also look these IDs up on Azure AD built-in roles doc

PowerShell code example:

Assigning Azure Resource Roles

For Azure Resource roles I could not find any end to end public doc examples but after trial and error the below steps were confirmed to work.

NOTE: The additional cmds compared to Azure AD role scenario are to convert ARM subscription IDs and ARM role IDs into their PIM resource IDs. For roleDefinitionID you can also look up built-in role IDs on Azure built-in roles doc if you are using custom roles, you can look these up in Azure Portal -> Subscription blade -> Access Control -> Roles

Leave a Reply Cancel reply

You must be logged in to post a comment.

List Eligible Entra ID PIM Assignments

• Kaido Järvemets
• February 28, 2023

As organizations grow and adopt cloud services, managing role assignments in Entra ID  becomes critical. Role assignments are necessary to grant access to resources and to delegate administrative privileges. However, it’s important to ensure that only the right users have access to the right resources and that the access is properly monitored and audited. In this blog post, we’ll show you how to audit eligible Entra ID role assignments using PowerShell.

Entra ID offers a feature called  Privileged Identity Management (PIM) , which provides time-based and approval-based role activation, auditing, and reporting.  PIM  allows you to assign eligible roles to users and groups for a limited duration of time and review audit logs of role activations and deactivations. In this post, we’ll focus on auditing  eligible roles , which are roles that users or groups are eligible to activate but haven’t yet.

It’s important to periodically audit role assignments in  Entra ID  to ensure that only the necessary permissions are granted to the right users, groups, or applications. In this blog post, we will show you how to use PowerShell and  Microsoft Graph  API to audit only the eligible Entra ID role assignments.

You can read my previous post Audit Entra ID Privileged Identity Management Role Settings – Kaido Järvemets (kaidojarvemets.com)

Prerequisites:

• Entra ID Global Administrator
• Latest Microsoft Graph PowerShell module
• PowerShell 7.x
• Visual Studio Code

Step 1: Install Microsoft.Graph PowerShell Module

First we need to install the Microsoft Graph PowerShell module:

Step 2: Define the desired permission scopes

We need to define the permission scopes required to access role management information in Entra ID. The following scopes are required to retrieve information about eligible role assignments:

If you are unsure how to define the permissions scope for a particular command, you can try using the   Find-MgGraphCommand   cmdlet. While this command may no t provide all the information you need, it can still give you some helpful hints.

Step 3: Connect to Microsoft Graph API

To connect to the  Microsoft Graph API  run the following command:

Step 4: Get eligible role assignments

We can use the  Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance  cmdlet to retrieve eligible role assignments. Eligible role assignments are those that meet the following conditions:

• The role is a privileged role
• The role is assigned to a user or group with an active role assignment
• The user or group has a P2 license assigned

Here’s the  PowerShell  script to retrieve eligible role assignments:

Complete Script

Auditing Entra ID PIM roles is a critical task to ensure proper access controls and maintain a secure environment. By using PowerShell and the Microsoft Graph API, you can quickly and easily retrieve information about role assignments.

If you haven’t yet performed an assessment of your Entra ID environment, now is the time to do so. Regular assessments can help you identify potential security risks and implement appropriate controls to mitigate them. So, take action today and conduct an Entra ID assessment to ensure the security of your organization’s digital assets.

Leave a Reply Cancel reply

You must be logged in to post a comment.

Table of Contents

Accelerator Workshop: Defender for SQL Implementation

• YOU CAN CHOOSE

Modernize Hybrid-Cloud Management Accelerator Workshop

• May 16, 2024

One-Day Training on Azure Arc for Servers Implementation

You might also like....

KQL Query – Who deleted my Azure Arc-enabled Server

Simplifying Cyber Defense: How to Configure Attack Surface Reduction Rules with PowerShell

Navigating the Transition from Configuration Manager to Azure Update Manager

Ready to get started.

© 2023

FOLLOW ME ON

Assigning groups to Azure AD roles and Privileged access groups, a first look!

On August 13th 2020, Alex Simons (Microsoft Identity PM) announced that assigning groups to Azure AD roles in now in public preview . This feature is one of the most requested features to be found in the Azure AD feedback forum .

I have been following this feature request for a while now, and up until recently Microsoft stated that implementing Azure AD role assignment for Azure AD groups wasn’t the issue, the issue was more related to who is able to manage those groups. For example, if enabled how can we circumvent that someone with the “User Administrator” role (capable of adding users to groups) is capable of adding someone to the group used to assign Global Administrator rights. When implemented incorrectly, this new “feature” could then introduce a new security risk in your environment.

Assigning groups to Azure AD roles requires an Azure AD Premium P1 license at minimum, for the Privileged Identity Functionality an Azure AD Premium P2 license is needed.

Disclaimer:  This post reflects the status of assigning groups to Azure AD roles as of August 20, 2020. Functionality may change, even right after this post has been published.

So, let’s walk through on what was announced and see..

So, up until now when you wanted to assign a user an Azure AD role, you had to include the user account directly in the role. Verifying which account has what privileges is therefore hard, especially if you don’t have Azure AD Privileged Identity Management (PIM) licensed.

For a more in depth overview of what Azure AD Privileged Identity Management (PIM) is, please see another blogpost I wrote on this subject here: Lessons learned while implementing Azure AD Privileged Identity Management (PIM)

Changed behaviour while adding members to Azure AD Roles

On the topic of PIM, I also noticed some changed functionality when adding users when you have PIM enabled in your environment. If you don’t have PIM enabled you can assign a user to a role, but if you have PIM enabled there is another experience where when you want to assign an Azure AD role you are actually redirected to the Privileged Identity Management blade, where you can directly create an Eligible (must be activated) or Active (always active) assignment.

Adding users to Azure AD roles via Group membership

In order to add users to Azure AD roles via Group membership you first have to create a new group, so it’s not possible to repurpose an existing group for this.

New groups have the option to set the “Azure AD roles can be assigned to the group (Preview)” option which can be set to either “No” or “Yes”. When you switch this setting to ‘Yes’ the group’s eligibility for role assignment is permanent. Besides that you can only have a membership type of Assigned, so using Dynamic Groups is not supported, and within the wizard you can only add users as member and not groups (group nesting). Interestingly, you can assign multiple Azure AD roles to the group.

If you want to create the Group with the “Azure AD roles can be assigned to the group (Preview)” option enabled you will get an extra confirmation screen:

The option “Azure AD roles can be assigned to the group (Preview)” is only visible if you are member of either the Global Administrator or Privileged Role Administrator role.

Privileged access groups

Once a group with the option to enable Azure AD role assignments is created and you have PIM enabled, a new option becomes available called “Privileged access (Preview)”.

Enabling this option gives us the following options:

Define Eligible or Active assignments to the group

On the group you can assign members or owners using the capabilities provided by PIM. So for example, while adding our user as a member of the group permanently earlier in this article, I now have the option to make the membership Eligible. Also notice that this assignment type is time bound, with a maximum of 1 year.

It’s also interesting to notice that if you want to update an Active Assignment you will not be allowed to Permanently assign an Active role by default. And that assigning an Active role has a maximum allowed assignment duration of 6 months. Once the group is enabled for Privileged Access and you want to add a member, then you don’t have the option “Permanently assigned” available. Also notice that providing a justification is mandatory.

The default options described above are configurable though, trough the settings, so you are able to configure these depending on your requirements.

Activating your Azure AD role while using Privileged access groups

It’s interesting to see that once a user is set to Eligible for the privileged access group, that the Azure AD role doesn’t show up under Eligible Assignments when the user browses to My Roles in PIM. In order to active the Azure AD role in this scenario, the user must go to Privileged access groups (Preview) and active the role from there.

Once the role is activated via the group, it will show up under Active assignments, and what’s interesting to see is that at this time it’s still displayed as being permanent. But I expect that to be fixed while the functionality is still in preview.

Within the PIM settings of the group you can also specify that any Activation request for the group must be approved. This works similar to approval in PIM as we already know it. You define that approval is mandatory and specify who can approve. This can either be a user or a group.

If the user now requests to activate the privileged access group, he will receive the message that the request is pending for approval

The approver doesn’t see the request under Privileged Identity Management | Approve requests but has to go to Privileged Identity Management | Privileged access groups (Preview) and select the group, from there the Approve Requests functionality is providing the ability to approve the request.

I hope this walkthrough gave you an idea on the new possibilities as announced in the public preview. And there is much more to cover actually when it comes to PIM, like more in depth information about auditing and access reviews.

Microsoft has addressed its own concerns by only allowing Global Administrators and Privileged Role Administrators to create the groups enabled for Azure AD role assignment. And having this functionality combined with Privileged Identity Management (PIM) makes the solution even better. Another reason to buy an Azure AD Premium P2 license for your administrative accounts at least.

A winning feature is that by using Privileged access with Azure AD Groups is that you can enable multiple Azure AD roles at once, this could save you creation of a custom role in some cases when using PIM.

While there are still some little fixes which must be applied, for now this looks like a welcome addition for any Azure AD tenant using Premium functionality.

Assigning groups to Azure AD roles is now in public preview!

Use cloud groups to manage role assignments in Azure Active Directory (preview)

Management capabilities for privileged access Azure AD groups (preview)

2 thoughts on “ Assigning groups to Azure AD roles and Privileged access groups, a first look! ”

• Pingback: Active Directory Identity Governance – Privileged Identity Management - JanBakker.tech

make the Security Admin Role a member Privilege Role Admin in Privilege Identity Management in Azure AD is this possible??

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Privacy Overview

Assignment Types

At a time when security breaches seem to be an everyday occurrence, it’s become more and more important to protect resources with more than just a username and password. It’s even more important to protect resources from INTERNAL threats. By implementing Azure AD Privileged Identity Management, organizations can protect their resources with improved security features, and even keep an eye on what legitimate administrators are doing.

In this lesson, you’ll learn how to implement Azure AD Privileged Identity Management. We’ll start the lesson by touching on an overview of what Azure AD Privileged Identity Management is and what it offers. We will then work through the deployment of PIM and how it works with multi-factor authentication. As we work through some demos, you will learn how to enable PIM and how to navigate tasks in PIM.

We’ll then cover the activation of roles and the assignment of those roles, including permanent roles and just-in-time roles. We’ll also cover the concepts of updating and removing role assignments, reinforcing these concepts through demonstrations.

We’ll round out the lesson with supported management scenarios, configuring PIM management access, and how to process requests. 

Learning Objectives

• Activate a PIM role
• Configure just-in-time resource access
• Configure permanent access to resources
• Configure PIM management access
• Configure time-bound resource access
• Create a Delegated Approver account
• Process pending approval requests

Intended Audience

• People who want to become Azure cloud architects
• People who are preparing to take Microsoft’s AZ-101 exam

Prerequisites

• Moderate knowledge of Azure Active Directory

 To see the full range of Microsoft Azure Content, visit the  Azure Training Library .

Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions. In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs. In his spare time, Tom enjoys camping, fishing, and playing poker.

Building a comprehensive report on Azure AD admin role assignments in Powershell

Keeping an eye on azure ad administrative role assignments is crucial for tenant security and compliance. forget about the built-in pim report in the azure ad portal - take reporting to the next level and build your own report with graph, kql and powershell..

Unassigning inactive roles, verifying that all role holders have registered MFA and are active users, auditing service principals, role-assignable groups and guests with roles, move users from active to eligible roles in PIM ( Privileged Identity Management ), and making sure that no synchronized users have privileged roles are just a few ideas for why you should be reporting on this topic.

In this blogpost I will showcase how to gather data from various sources and compile it all into an actionable status report. Since different tenants have different needs and ways of working, I’m providing examples so that you can write your own custom-tailored script.

The report will list the following records:

• Users with eligible or active Azure AD admin roles - including details on last role activation date, role assignment and expiration dates, MFA status and last sign-in date, admin owner account status etc.
• Service Principals / Applications and Managed Identities with active Azure AD admin roles - including details on last authentication date, tenant ownership, etc.
• Role-assignable groups with eligible or active Azure AD admin roles

Note : Role-assignable groups granted one or more Azure AD admin roles will be listed in the report but users with active or eligible membership to such groups will currently not be listed.

See the Report examples chapter for details.

Prerequisites

Connecting to graph and log analytics, mfa registration details, role assignments, principal last sign-in date, eligible role last activation date, default mfa method and capability, admin account owner, service principal owner organization, report examples, example script.

These Powershell modules are required:

• Graph Powershell SDK
• Azure Powershell

Other prerequisites:

• Global Reader role (or other AAD roles granting enough read-access)
• Admin consent to any required non-consented Graph scopes (read-only) in Graph Powershell SDK.
• Reader-role on the Log Analytics workspace where the Azure AD Sign-in and Audit logs are exported.

Connect to Graph with the Graph Powershell SDK using the required read-only scopes, and select the beta endpoint as required by some of the cmdlets:

Then connect to Azure with the Azure Powershell module, for running KQL queries on the Log Analytics workspace data. Read my Query Azure AD logs with KQL from Powershell blogpost for more information on running KQL queries in Powershell. Update the various parameters according to your environment.

Extracting data

We need to extract data from various sources using Microsoft Graph and KQL queries in Log Analytics.

To report on MFA registration details for Azure AD admin role holders it is likely most efficient to extract all registration details and create a hashtable for quick lookup, depending on the number of users in the tenant.

Assigned roles are active role assignments. This query will also return eligible role assignments which are currently activated through PIM, so we’ll filter those out as they will just be duplicates in the report as they are also listed as eligible roles.

Eligible roles are role assignments requiring activation in PIM.

Then we combine the two assignment types into one array. Use the Select-Object cmdlet to pick out a few records while developing and testing the script.

Now we have all the assignment objects we need in the $allRoleAssignments array, and will process each of those objects in a foreach loop to fetch other necessary data. In the following examples I’ve populated the $roleObject variable with one object from the $allRoleAssignments array.

Since the $allRoleAssignments array may contain both users and Service Principals with active or eligible role assignments, the $roleObject.Principal.AdditionalProperties.'@odata.type property will tell which principal type the current object is - either '#microsoft.graph.user or #microsoft.graph.servicePrincipal . And for Service Principals we can differentiate on types in the $roleObject.Principal.AdditionalProperties.servicePrincipalType property - which is either Application or ManagedIdentity .

The quickest way to get an Azure AD user’s last sign-in date is to query Graph for the user and selecting signInActivity .

For Service Principals we need to query the Azure AD logs in Log Analytics with KQL to fetch the date when the Service Principal last signed in.

KQL query for Service Principal of type Application :

KQL query for Service Principals of type ManagedIdentity :

We also need to fetch the latest date of eligible role activations for users. If $roleObject.AssignmentType equals null and the principal is a user, the following KQL query can help out:

Users with administrative roles and no registered MFA method can be a security risk, depending on tenant configuration and conditional access policies. It’s best to avoid it - while also report on the default type of MFA methods active role assignees have. We already have the $mfaRegistrationDetailsHashmap hashtable and can query it for each processed role where the principal is a user.

If you’re following Microsoft best-practises and separating normal user accounts from administrative roles, you should be having a separate admin account for each user who requires privileged roles and access.

When having separate admin accounts it’s also important to check account status of the admin account owners if possible - to make sure that all admin accounts of terminated employees have been disabled and/or deleted. This query will depend on how you identify admin account owners in your tenant, the following example extracts the owner’s accountName from the UPN and queries Graph for any user with that onPremisesSamAccountName + employeeId .

Service Principals of multi-tenant app registrations can be owned by other Azure AD tenants and consented to in your tenant. It’s important to know about these and understand why they have privileged roles.

If $roleObject.Principal.AdditionalProperties.appOwnerOrganizationId is not null , query Graph for the tenant properties of the owner organization.

$spOwnerOrg.displayName will contain the tenant organization name, and $spOwnerOrg.defaultDomainName the tenant’s default domain’, which can provide a better clue of what the Service Principal is used for and by whom.

Note : Know 100% what you’re doing before removing any privileged roles from Service Principals, especially from Microsoft-owned apps which likely have the roles for a very good reason.

That’s about it, we now have the data necessary to compile an actionable status report on all active and eligible Azure AD role assignments.

Compiling the report

We can now construct a PSCustomObject per role assignment with the collected data.

User with eligible role assignment:

User with active role assignment and owner account details:

Service Principal with role assignment:

Managed Identity with role assignment:

Role-assignable group with role assignment:

In case you need more tips on creating a reporting powershell script for this report, take a look at the example script I’ve published on GitHub .

Thanks for reading!

Be sure to provide any feedback on Twitter or LinkedIn .

• ← Previous Post
• Next Post →

Cloud Build

Microsoft azure, 365 and all things tech.

difference between eligible and active azure PIM

How to configure azure ad roles in privileged identity management (pim).

Privileged Identity Management (PIM) is a service in Azure Active Directory (Azure AD) that enables you to manage, control, and monitor access to important resources in your organisation.

Privileged Identity Management provides time based and approval based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management:

• Provide just-in-time privileged access to Azure AD and Azure resources
• Assign time-bound access to resources using start and end dates
• Require approval to activate privileged roles
• Enforce multi-factor authentication to activate any role
• Use justification to understand why users activate
• Get notifications when privileged roles are activated
• Conduct access reviews to ensure users still need roles
• Download audit history for internal or external audit

Privileged Identity Management licence requirements

• Azure AD Premium P2 or Enterprise Mobility + Security (EMS) E5

Ensure that your directory has at least as many Azure AD Premium P2 licenses as you have employees that will be performing the following tasks:

• Users assigned as eligible to Azure AD or Azure roles managed using PIM
• Users who are assigned as eligible members or owners of privileged access groups
• Users able to approve or reject activation requests in PIM
• Users assigned to an access review
• Users who perform access reviews

Azure AD Premium P2 licenses are  not  required for the following tasks:

• No licenses are required for users who set up PIM, configure policies, receive alerts, and set up access reviews.

It can become confusing when working out the number of Azure AD P2 licences required so Microsoft have provided examples at the following link: Azure PIM Example Licence Scenari os In this blog post I will go through the process of configuring Azure AD Roles in Privileged Identity Management (PIM). I will grant a user named Joe Bloggs eligible assignment for one of my Azure admin roles.

As mentioned above, to use PIM you must have an Azure AD P2 or Enterprise Mobility + Security (EMS) E5 licence. I currently have access to an E3 license which grants me access to an Azure AD P1 licence which is obviously not sufficient.

If you already have access to Azure AD P2, skip to the next section by scrolling down to section Configuring Azure Privileged Identity Management (PIM)

• Firstly, I will sign up to a free 90 day Enterprise Mobility + Security (EMS) E5 trial account. As you can see from the screenshot below my licence assignment is currently Azure AD Premium P1.

and if I attempt to access PIM, I receive the message below

Microsoft offer trials for a number of their products including Azure AD P2 which will allow you to test Azure PIM. I’ll start with activating a free trial which can be ready within minutes as you’ll find out shortly.

2. Access Azure AD, click Licenses , click All products and click the + Try / Buy button as highlighted below

3. Enterprise Mobility + Security E5 includes Azure AD P2 and Microsoft offer a 90 day trial so I selected this option. I’ll be going through further demo’s at a later date which require Enterprise Mobility + Security E5 so this licence will be useful.

4. Click Free Trial under the licence you wish to activate. In my case I clicked Free trial under Enterprise Mobility + Security E5

5. Click Activate

6. Wait for the product to activate which should take seconds

7. After activation my licence status still shows as Azure AD P1

8. Log out of the portal and back in and the correct version is now displayed

That’s the free trial sorted

Configuring Azure AD Roles – Azure Privileged Identity Management (PIM)

• Log into the Azure Portal (portal.azure.com)
• Search PIM and select Azure AD Privileged Identity Management

3. Click Azure AD roles

4. Click Assignments

5. I don’t have any assignments at the moment, click +Add Assignments

6. Select a role and member

For the purpose of this demo, I have selected the role Global Administrator and selected an existing user named Joe Bloggs from my directory. Click Next

7. For the purpose of this demo, I will select Eligible and leave the default at permanently eligible. Eligible A role assignment that requires a user to perform one or more actions to use the role. If a user has been made eligible for a role, that means they can activate the role when they need to perform privileged tasks. There’s no difference in the access given to someone with a permanent versus an eligible role assignment. An eligible administrator can activate the role when they need it, and then their permissions expire at a set time, until the next time the role is activated. The only difference is that some people don’t need that access all the time. So in my case, Joe Bloggs will be eligible which means he will request access each time he requires access to the Global Administrator role (Default limit for 8 hours and his permissions will be removed until he activates again). Permanently eligible which means he will be allowed to continue to activate the role when he needs to perform privileged tasks. A permanently eligible end date can be configured, for example, users can activate access for 8 hours at a time for up to 1 year instead of being able to activate the role continuously without an end date. I’ll cover more on this as we move on.

Active: This is a role assignment that doesn’t require a user to perform any action to use the role. Users assigned as active have the privileges assigned to the role at all times but can be setup so access is removed at a certain date.

Continuing with Active Assignment, this options provides a user with permanent access or up to a date set by the administrator. See screenshot below. In this case, the user will have access to the role assigned permanently or by a set expiry date. A further text box appears as shown below requesting a justification on why the admin is granting the user with an active assignment.

8. For the purpose of this demo, I have selected eligible. Click Assign when ready

9. Now that Joe Bloggs has been granted an eligible assignment, I will log in as Joe Bloggs and demonstrate what Joe Bloggs will see.

10. When logging in as Joe Bloggs, I am prompted to enable MFA.

11. MFA configured, I can now move on to logging in as Joe Bloggs. Now that I am logged in, Joe Bloggs is still a basic user without global admin permissions, which is normal. He can’t create accounts within Azure AD or perform any other administrative tasks which require elevated permissions. Access is disabled.

12. Joe Bloggs will need to activate his eligible assignment within PIM. Whilst still logged in as Joe Bloggs, I search for PIM and click Azure AD Privileged Identity Management

13. Click My roles

14. The eligible assignment is displayed with an Activate link as shown below. Click Activate

If the user skipped MFA at the initial logon stage, as shown in the screenshot below, the user will be prompted to authorise via MFA which is enforced by a default enabled setting within PIM. I’ll explain where this option is found shortly. If you wish to disable the below 14 day reminder, you can have a read of the following link later – Disable Skip MFA prompt

15. After clicking activate, Joe Bloggs receives the below prompt

Duration: maximum of 8 hours access. After the 8 hours, Joe Bloggs access will be revoked and he will have to activate his assignment again. Joe Bloggs was allowed permanent eligibility which allows him to activate his eligible assignment when required.

Custom activation: If Joe Bloggs requires admin access in the future, he could select the option Custom activation start time and select a date and time he would like his 8 hours access to begin. In the example below, I have configured the time for a time in the past.

16. When ready, click activate

17. Activation has been scheduled

If I check access from my account, i’ll find that Joes Bloggs has been granted access without any further action required from me Location: Access PIM > Click Azure AD Roles > Pending Access

From here you could also cancel Joe Bloggs access by clicking the Cancel link

That’s the default settings but what if you wish to increase the default 8 hour access limit? Or you would like for the request to go to a team of approvers for review before Joe Bloggs is granted access? or you require 8 hours access for the Global Administrator role but 10 hours access for the Exchange Administrator role. Let’s move onto where these settings are configured.

Configuring Azure AD Privileged Identity Management Azure AD role settings

• Click Azure AD Privileged Identity Management

2. Click Azure AD roles

3. Click Settings

4. Here you can apply different configuration settings based on roles. For the purpose of this demo, I will be configuring the Global Administrator role.

5. After clicking the Global Administrator Role, you’ll find the below settings. Review and click Edit

6. The first windows displays a number of settings including the default 8 hour access. You can extend this to 24 hours if required

Azure MFA is enabled by default, which enforces MFA while activating the assignment.

Require justification: requests a reason why the user requires access

Require ticket information: you may have a process where the user requiring access needs to input a ticket or change number

Require approval to activate: this feature is an important one. Setting approvers adds an additional check before a users assignment is activated. The request goes into a pending approval list after the user activates the assignment which allows a approver to review access and deny or approve access accordingly. Note: each approver will need to be assigned an Azure AD P2 licence

To allow me to demo the approval process, I have enabled require approval to activate and added a single user as an approver.

Before I move on and demo the approval process, clicking the assignments button moves us onto the next screen below. You may wish to leave the defaults or set an expiry. For example, you could configure the below policy so that users will be eligible to elevate their account into the role assigned for one year instead of being eligible forever. The same applies for the active role.

Finally, the next screen is where you can configure email notifications

7. When ready, click the update button. Note the below fields which can be useful.

We can now move on and test the approval process.

Azure AD PIM Approval demo

• I granted Joe Bloggs an eligible assignment earlier. The new settings I configured above will apply to Joe on his next eligible assignment activation.
• I log in as Joe Bloggs
• Click Azure PIM
• Click My Roles
• Click Activate

6. Type in justification details and click activate

7. After clicking activate, Joe Bloggs is not granted access immediately. His request is pending approval as shown below

8. The admin allocated as a approver earlier must review the request and decide whether to approve or deny access. Back over to my account where I will review Joe Bloggs access. I will also receive an email to notify me that there is a request pending.

Access PIM > Azure AD Roles > Approve requests

9. Here is the pending request where I can review each case.

Note: Clicking approve or deny opens the window below allowing you review the details fully without having to expand the tabs above. A justification needs to be provided.

10. And Joes Bloggs access is approved. He will be granted access for 8 hours and does not need to take any further action to activate the role.

A complete audit of all actions carried out in PIM Azure AD Roles can also be located at: PIM > Azure AD Roles > Audit

Using Azure Active Directory (Azure AD) Privileged Identity Management (PIM), you can also improve the protection of your Azure resources and as you can see below Privileged access groups which was in preview at the time of writing this post.

Azure PIM also offers Access Reviews. Access to privileged Azure resource roles for employees changes over time. To reduce the risk associated with stale role assignments, you should regularly review access. You can use Azure Active Directory (Azure AD) Privileged Identity Management (PIM) to create access reviews for privileged Azure resource roles. You can also configure recurring access reviews that occur automatically. I will cover these topics in a further post. Note: Azure AD P2 licences are required within your directory for users assigned to an access review and users who perform access reviews.

Feedback welcome, please comment below. It would also be great to hear about your experience using Azure PIM.

Subscribe to new tech posts. We will never send you spam email or forward your details to third parties.

This will close in 0 seconds

Privacy Overview

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Assign eligibility for a group in Privileged Identity Management

• 15 contributors

In Microsoft Entra ID, formerly known as Azure Active Directory, you can use Privileged Identity Management (PIM) to manage just-in-time membership in the group or just-in-time ownership of the group.

When a membership or ownership is assigned, the assignment:

• Can't be assigned for a duration of less than five minutes
• Can't be removed within five minutes of it being assigned

Every user who is eligible for membership in or ownership of a PIM for Groups must have a Microsoft Entra ID P2 or Microsoft Entra ID Governance license. For more information, see License requirements to use Privileged Identity Management .

Assign an owner or member of a group

Steps in this article might vary slightly based on the portal you start from.

Follow these steps to make a user eligible member or owner of a group. You'll need permissions to manage groups. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role-assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not administrative unit level).

Other roles with permissions to manage groups (such as Exchange Administrators for non-role-assignable M365 groups) and administrators with assignments scoped at administrative unit level can manage groups through Groups API/UX and override changes made in Microsoft Entra PIM.

Sign in to the Microsoft Entra admin center

Browse to Identity governance > Privileged Identity Management > Groups .

Here you can view groups that are already enabled for PIM for Groups.

Select the group you need to manage.

Select Assignments .

Use Eligible assignments and Active assignments blades to review existing membership or ownership assignments for selected group.

Select Add assignments .

Under Select role , choose between Member and Owner to assign membership or ownership.

Select the members or owners you want to make eligible for the group.

Select Next .

In the Assignment type list, select Eligible or Active. Privileged Identity Management provides two distinct assignment types:

• Eligible assignment requires member or owner to perform an activation to use the role. Activations may also require providing a multi-factor authentication (MFA), providing a business justification, or requesting approval from designated approvers.

For groups used for elevating into Microsoft Entra roles, Microsoft recommends that you require an approval process for eligible member assignments. Assignments that can be activated without approval can leave you vulnerable to a security risk from another administrator with permission to reset an eligible user's passwords.

• Active assignments don't require the member to perform any activations to use the role. Members or owners assigned as active have the privileges assigned to the role at all times.

If the assignment should be permanent (permanently eligible or permanently assigned), select the Permanently checkbox. Depending on the group's settings, the check box might not appear or might not be editable. For more information, check out the Configure PIM for Groups settings in Privileged Identity Management article.

Select Assign .

Update or remove an existing role assignment

Follow these steps to update or remove an existing role assignment. You'll need permissions to manage groups. For role-assignable groups, you need to have Global Administrator, Privileged Role Administrator role, or be an Owner of the group. For non-role-assignable groups, you need to have Global Administrator, Directory Writer, Groups Administrator, Identity Governance Administrator, User Administrator role, or be an Owner of the group. Role assignments for administrators should be scoped at directory level (not administrative unit level).

Sign in to the Microsoft Entra admin center as at least a Privileged Role Administrator .

Select Update or Remove to update or remove the membership or ownership assignment.

• Activate your group membership or ownership in Privileged Identity Management
• Approve activation requests for group members and owners

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Azure AD PIM Role Assignment Activated

Try in Splunk Security Cloud

Description

The following analytic identifies the assignment of the Azure AD PIM role. Privileged Identity Management (PIM) is a service within Azure Azure AD that enables administrators to manage, control, and monitor access to sensitive resources. PIM provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources. Once a user has been made eligible for an administrative role, she must activate this role assignment to perform the privileged actions. When a role is activated, Azure AD PIM temporarily adds active assignment for the role. While PIM can be leveraged as a powerful security control, it may also abused by adversaries to obtain privileged access. Security teams should monitor for the assignment and activation of PIM roles and validate their legitimacy.

Product : Splunk Enterprise, Splunk Enterprise Security, Splunk Cloud

• Last Updated : 2023-12-20
• Author : Mauricio Velazco, Splunk
• ID : 952e80d0-e343-439b-83f4-808c3e6fbf2e

Annotations

• Installation
• Exploitation

The SPL above uses the following Macros:

• azure_monitor_aad
• security_content_ctime

azure_ad_pim_role_assignment_activated_filter is a empty macro by default. It allows the user to filter out any results (false positives) without editing the SPL.

Required fields

List of fields required to use this analytic.

• operationName
• initiatedBy.user.userPrincipalName

How To Implement

You must install the latest version of Splunk Add-on for Microsoft Cloud Services from Splunkbase(https://splunkbase.splunk.com/app/3110/#/details). You must be ingesting Azure Active Directory events into your Splunk environment. This analytic was written to be used with the azure:monitor:aad sourcetype leveraging the AuditLog log category.

Known False Positives

As part of legitimate administrative behavior, users may activate PIM roles. Filter as needed

Associated Analytic Story

• Azure Active Directory Privilege Escalation
• Azure Active Directory Persistence

The Risk Score is calculated by the following formula: Risk Score = (Impact * Confidence/100). Initial Confidence and Impact is set by the analytic author.

• https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure
• https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-activate-role
• https://microsoft.github.io/Azure-Threat-Research-Matrix/PrivilegeEscalation/AZT401/AZT401/

Test Dataset

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI . Alternatively you can replay a dataset into a Splunk Attack Range

source | version : 3