temporary role assignment azure

This browser is no longer supported.

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

Assign Azure resource roles in Privileged Identity Management

• 20 contributors

With Microsoft Entra Privileged Identity Management (PIM), you can manage the built-in Azure resource roles, and custom roles, including (but not limited to):

• User Access Administrator
• Contributor
• Security Admin
• Security Manager

Users or members of a group assigned to the Owner or User Access Administrator subscription roles, and Microsoft Entra Global administrators that enable subscription management in Microsoft Entra ID have Resource administrator permissions by default. These administrators can assign roles, configure role settings, and review access using Privileged Identity Management for Azure resources. A user can't manage Privileged Identity Management for Resources without Resource administrator permissions. View the list of Azure built-in roles .

Privileged Identity Management support both built-in and custom Azure roles. For more information on Azure custom roles, see Azure custom roles .

Role assignment conditions

You can use the Azure attribute-based access control (Azure ABAC) to add conditions on eligible role assignments using Microsoft Entra PIM for Azure resources. With Microsoft Entra PIM, your end users must activate an eligible role assignment to get permission to perform certain actions. Using conditions in Microsoft Entra PIM enables you not only to limit a user's role permissions to a resource using fine-grained conditions, but also to use Microsoft Entra PIM to secure the role assignment with a time-bound setting, approval workflow, audit trail, and so on.

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

Currently, the following built-in roles can have conditions added:

• Storage Blob Data Contributor
• Storage Blob Data Owner
• Storage Blob Data Reader

For more information, see What is Azure attribute-based access control (Azure ABAC) .

Assign a role

Follow these steps to make a user eligible for an Azure resource role.

Sign in to the Microsoft Entra admin center as at least a User Access Administrator .

Browse to Identity governance > Privileged Identity Management > Azure resources .

Select the resource type you want to manage. Start at either the Management group dropdown or the Subscriptions dropdown, and then further select Resource groups or Resources as needed. Click the Select button for the resource you want to manage to open its overview page.

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

Select Add assignments to open the Add assignments pane.

Select a Role you want to assign.

Select No member selected link to open the Select a member or group pane.

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

On the Settings tab, in the Assignment type list, select Eligible or Active .

Microsoft Entra PIM for Azure resources provides two distinct assignment types:

Eligible assignments require the member to activate the role before using it. Administrator may require role member to perform certain actions before role activation, which might include performing a multi-factor authentication (MFA) check, providing a business justification, or requesting approval from designated approvers.

Active assignments don't require the member to activate the role before usage. Members assigned as active have the privileges assigned ready to use. This type of assignment is also available to customers that don't use Microsoft Entra PIM.

To specify a specific assignment duration, change the start and end dates and times.

If the role has been defined with actions that permit assignments to that role with conditions, then you can select Add condition to add a condition based on the principal user and resource attributes that are part of the assignment.

Conditions can be entered in the expression builder.

When finished, select Assign .

After the new role assignment is created, a status notification is displayed.

Assign a role using ARM API

Privileged Identity Management supports Azure Resource Manager (ARM) API commands to manage Azure resource roles, as documented in the PIM ARM API reference . For the permissions required to use the PIM API, see Understand the Privileged Identity Management APIs .

The following example is a sample HTTP request to create an eligible assignment for an Azure role.

Request body

Status code: 201

Update or remove an existing role assignment

Follow these steps to update or remove an existing role assignment.

Open Microsoft Entra Privileged Identity Management .

Select Azure resources .

Under Manage , select Roles to list the roles for Azure resources. The following screenshot lists the roles of an Azure Storage account. Select the role that you want to update or remove.

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

To add or update a condition to refine Azure resource access, select Add or View/Edit in the Condition column for the role assignment. Currently, the Storage Blob Data Owner, Storage Blob Data Reader, and Storage Blob Data Contributor roles in Microsoft Entra PIM are the only roles that can have conditions added.

Select Add expression or Delete to update the expression. You can also select Add condition to add a new condition to your role.

For information about extending a role assignment, see Extend or renew Azure resource roles in Privileged Identity Management .

• Configure Azure resource role settings in Privileged Identity Management
• Assign Microsoft Entra roles 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

• Privacy Policy

Select Page

Step-by-Step guide to setup temporally privilege access using Azure AD Privileged Identity Management

Posted by Dishan M. Francis | Sep 13, 2018 | Azure , Azure Active Directory | 1 |

Last Updated on September 26, 2018 by Dishan M. Francis

Just-in-Time Administrations protects high-privileged accounts been compromised. Administrators will have their privileges when they “ required ”. It minimizes the lateral movements of identity attack. Azure AD PIM allows to create time-based temporally admin accounts. In this demo I am going to demonstrate how to create time-based admin accounts in azure using PIM. If you are new to privilege identity management, I highly recommend to check my previous blog post about it. you can access it using https://www.rebeladmin.com/2016/07/step-step-guide-azure-ad-privileged-identity-management-part-1/ 

In my demo environment I have a user called Isaiah Langer from finance department. At the end of every month this user runs some reports which required admin privileges. I do not want to make this user a permanent global administrator. I like to give these privileges when “required”. Let’s see how we can configure it. 

1. Log in to Azure portal https://portal.azure.com as global admin.

2. Click on More Services from the left-hand panel and search for Azure AD PIM . 

3. In first window it asks me to verify my MFA before proceed. This is because I do not have MFA setup for my account. Click on verify my identity option. 

4. Then it goes through MFA setup process. Please complete sign up process to continue. 

5. Once process is completed it will load the PIM page again. Click on Consent to proceed. 

6. Then click on Yes to proceed. 

7. After service is initiated, click on Azure AD directory roles .

8. Then click on Sign up to proceed.

9. Click Yes to proceed

10. In new page, click on Admin View

11. Then under directory roles click on Global Administrator . 

12. According to this, Isaiah Langer is a permanent global admin at the moment. I need to change it to time based membership. To do that click on user and then click on Make eligible . 

13. Once it is completed, go back to Azure AD directory roles home page and click on Settings

14. Then click on Roles

15. From the roles list, click on Global Administrator

16. In new panel, set Maximum activation duration as 0.5 hours . Also click Enable under notification . Once settings in place, click on Save . 

17. Now we have settings in place. To test it, go to https://outlook.office365.com/ and login as user Isaiah Langer . In there I can see an email from Azure PIM. Click on Azure Portal link.

18. Then log in to portal as Isaiah Langer

19. After login go to More Services | Azure AD PIM

20. Then click on My Roles . If you do not have MFA activated for this account, you have to follow same steps to complete MFA sign up process. 

21. Now we can see Global Administrator role under eligible role . Click on Activate .

22. In next window it asks to use MFA to verify account before proceed. 

23. Once account verification is done, click on Activate

24. In next window, type reason for activation and click on Activate . If you need, using custom activation start time option we can set time to initiate the activation. 

25. Then go back to home page and click on My requests . there we can see the status of the request. In here the request was completed and user got global admin privileges for 30 minutes. 

26. Also, under My Roles | Active Roles now I can see the Global Administrator role. 

27. As expected, after 30 minutes no longer can see global admin role under active roles. 

28. If we log in to azure portal as global admin and navigate to PIM | Azure AD directory roles | Directory roles audit history we can see all the activity history for role activation.

This marks the end of this blog post. Hope now you have better understanding how enable time-based privilege access using Azure AD PIM. If you have any further questions feel free to contact me on [email protected] also follow me on twitter @rebeladm to get updates about new blog posts.

Related Posts

Step-by-step guide: manage group using azure active directory powershell for graph module.

June 16, 2019

Step-by-Step Guide to assign Reserved IP address to Azure VM

August 14, 2016

Step-by-Step guide to Azure AD Password protection

October 28, 2018

Step-by-Step Guide to Azure AD PIM and Conditional Access Integration (Public Preview)

March 23, 2023

How about if we needed the Just In Time access for half an hour on a daily basis? What setting needs to be configured?

Leave a reply Cancel reply

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

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

I am Dishan Francis. I’m a Cyber Security Consultant at Microsoft. I’m a dedicated and enthusiastic information technology expert who enjoys professional recognition and accreditation from several respected institutions. I am maintaining this blog for last 11 years. This includes more than 400 articles already. These are mainly about Microsoft Active Directory Service and Azure Active Directory Service. I also blog about different Azure services. If you need further help on subject matters, feel free to contact me on [email protected]. Also to get latest updates, follow me on twitter @rebeladm

Mastering Active Directory, Third Edition

I am glad to announce the release of my new book “ Mastering Active Directory – 3rd Edition ”. It is available for purchase worldwide now For more info….

Inside Track Blog

How Microsoft does IT

Using Azure AD Privileged Identity Management for elevated access

Sep 19, 2018   |   Inside Track – retired stories

This content has been archived, and while it was correct at time of publication, it may no longer be accurate or reflect the current situation at Microsoft.

Microsoft uses Azure Active Directory (AD) Privileged Identity Management (PIM) to manage elevated access for users who have privileged roles for Azure services. We manage privileged identities for on premises and Azure services—we process requests for elevated access and help mitigate risks that elevated access can introduce. With Azure AD PIM, we can implement just-in-time access for privileged roles in Azure and view audit logs. Before Azure AD PIM, privileged roles in Azure were always elevated.

Throughout Microsoft, there are employees who require elevated access to Microsoft Online Services, Microsoft Azure, and on-premises services that they own, manage, or support. At Microsoft Digital, we knew that we needed to manage any potential risks that elevated access can introduce, such as “pass the hash” or credential theft. We wanted to better manage privileged identities and monitor elevated access for cloud resources.

Microsoft doesn’t allow persistent elevated access, so we use the Azure Active Directory (Azure AD) Privileged Identity Management (PIM) feature of just-in-time role activation (JIT) to temporarily elevate the role-based access as needed for a defined time. Before the release of Azure AD PIM, our Azure Active Directory administrative roles had persistent elevated access, monitoring was limited, and we didn’t have a fully managed lifecycle.

Azure Active Directory uses administrative roles to control access to various features within the tenant. Recent changes introduced in Azure AD PIM have enabled a cloud-based, JIT tool for Azure Active Directory administrative roles as well as Azure administrative roles. Both Azure Active Directory administrative roles as well as Azure administrative roles can be assigned and remain inactive until needed. We configured Azure AD PIM, available with the Premium P2 edition of Azure AD, to help us manage and monitor our Azure AD administrative roles through the Azure portal.

Identity management at Microsoft

Identity management at Microsoft encompasses all process and tools used to manage the lifecycle of all identities for all our corporate employees. Of the roughly 285,000 identities that we currently manage at Microsoft, there are approximately 10,000 on-premises accounts and 400 Azure AD accounts of users who require elevated access to data and services. When we started using PIM, we did an attestation to reduce the number of individual users who might need individual assignments. Since then, we have reduced the number of users who are candidates for global administrator by 83 percent, and removed all persistent users (except for a break-glass account) from the global-administrator role. We regularly add more roles that require elevated access, so we’ve seen the number of managed users grow slowly but consistently.

Privileged Identity Management focuses on the tools and processes we use for a subset of users that have administrative—or elevated—access to on-premises and cloud-hosted data and services at Microsoft.

Reducing the attack surface

There are a couple of obvious ways we can look at reducing the risks, or attack surface, of elevated access—by reducing the number of accounts or the duration that an account has elevated access. We rationalize incoming requests for elevated access, but we can’t necessarily reduce the number of people that require it to do their jobs. We’ve adopted the strategy of reducing risks by giving employees just enough access to the resources that they need, for only as long as they need it. At Microsoft, the only people who are authorized to assign others to roles are Privileged Role Administrators. We monitor unauthorized assignment of roles, and the addition of users who are not authorized to be assigned to roles. If anyone else tries to assign a role, it is automatically flagged as a violation of role-assignment policy.

Typically, the more elevated access a privileged role has, the more rigorously we protect it. At the front end of the process, the review board spends more time evaluating requests for more privileged roles. The employee request process requires multiple levels of approvals. After the request is approved, we can require tighter controls, including multifactor authentication or physical credential, like smart cards. We also set shorter access durations through JIT access.

Azure AD PIM

By configuring Azure AD PIM to manage our elevated access roles in Azure AD, we now have JIT access for more than 28 configurable privileged roles. We can also monitor access, audit account elevations, and receive additional alerts through a management dashboard in the Azure portal.

Elevated access workflow

Elevated access includes job roles that need greater access, including support, resource administrators, resource owners, service administrators, and global administrators. We manage role-based access at the resource level. Because elevated access accounts could be misused if they’re compromised, we rationalize new requests for elevated access and perform regular re-attestation for elevated roles.

At Microsoft, when an individual joins a team or changes teams, they might need administrative rights for their new business role. For example, someone might join a team in which their user account will require Exchange Online Administrator privileged access rights in the future. That user makes a request, then their manager validates that user’s request, as does a service owner. With those approvals, Microsoft Digital administrators in the Privileged Role Administrator role are notified. A Microsoft Digital administrator uses Azure AD PIM via the Azure Portal to make that user eligible for that role. The user can then use Azure AD PIM to activate that role.

Figure 1 shows a diagram of the elevated access workflow.

The following table describes the processes we use for granting elevated access for both on-premises and cloud-hosted resources. We’re currently building a solution that will combine the on-premises and Azure AD elevated access workflows into a single workflow with a centralized management point. For more information, see the “Looking ahead: Expanding use of Azure AD PIM” section later in this article. Microsoft Digital and the product group are working together to automate the request-access process.

Table 1. Elevated access processes

Jit administrator access.

Historically, we could assign an employee to an administrative role through the Azure portal or through Windows PowerShell and that employee would be a permanent administrator; their elevated access would remain active in the assigned role.

Azure AD PIM introduced the concept of permanent and eligible administrators in Azure AD and Azure. Permanent administrators have persistent elevated role connections; whereas, eligible administrators have privileged access only when they need it. The eligible administrator role is inactive until the employee needs access, then they complete an activation process and become an active administrator for a set amount of time. We’ve stopped using permanent administrators for named individual accounts, although we do have some automated service accounts that still use the role.

Role activation in Azure Active Directory

Azure AD PIM uses administrative roles, such as tenant admin and global admin, to manage temporary access to various roles. With Azure AD PIM, you can manage the administrators by adding or removing permanent or eligible administrators to each role. Azure AD PIM includes a number of built-in Azure AD roles as well as Azure that we manage.

To activate a role, an eligible admin will initialize Azure AD PIM in the Azure portal and request a time-limited role activation. The activation is requested using the  Activate my role  option in Azure AD PIM. Users requesting activation must satisfy conditional access policies to ensure that they are coming from authorized devices and locations, and their identities must be verified through multi-factor authentication.

To help secure transactions while enabling mobility, we use Azure AD PIM to customize role activation variables in Azure, including the number of sign-in attempts, the length of time the role is activated after sign-in, and the type of credentials required (such as single sign-in or multifactor authentication).

Tracking the use of privileged roles using the dashboard

A dashboard through the Azure portal gives a centralized view of:

• Alerts that point out opportunities to improve security.
• The number of users who are assigned to each privileged role.
• The number of eligible and permanent admins.
• Ongoing access reviews.

We can track how employees and admins are using their privileged roles by viewing the audit history or by setting up a regular access review. Both options are available through the PIM dashboard in the Azure portal.

The PIM audit log tracks changes in privileged role assignments and role activation history. We use the audit log to view all user assignments and activations within a specified period. The audit history helps us determine, in real time, which accounts haven’t signed in recently, or if employees have changed roles.

Access reviews can be performed by an assigned reviewer, or employees can review themselves. This is an effective way to monitor who still needs access, and who can be removed.

We’re looking at the data that’s collected, and the monitoring team is assessing the best way to configure monitoring alerts to notify us about out-of-band changes—for example, if too many administrator roles are being created for an Azure resource. The information also helps us determine whether our current elevation time settings are appropriate for the various privileged admin roles.

Looking ahead: Expanding use of Azure AD PIM

Unified management point and automated end-to-end workflows.

We’re currently using similar processes but different methods and tools to manage privileged identities for Azure-based and on-premises assets or tenants.

We’re streamlining and operationalizing our process by customizing and deploying an application that will automate and provide a single management point for the entire workflow for both Azure AD and on-premises identity management. The application will integrate both the on-premises privileged identity management tools and Azure AD PIM through its APIs.

The application will provide a unified view for both cloud and on-premises elevated accounts, along with a single portal for our security administrators to monitor elevated access activity. The application will help operationalize our processes by automating:

• Access request process, including the workflow that secures all the required approvals.
• Multifactor authentication enforcement for access requests.
• Lifecycle management, through JIT access enablement and removal when action is complete.

To provide more security, we’ve integrated secure admin workstations for employees who have elevated administrator access to on-premises, tenant, and Azure subscription resources. The secure admin workstations include enhanced hardware and configuration-based security features that help protect elevated credentials from being compromised. We’re considering required secure admin workstations for Azure AD global administrators.

Using Azure AD PIM for managing your Tenant and Azure subscriptions

With Azure Active Directory PIM, we manage, control, and monitor access within our organization. This includes access to Azure AD and other Azure resources, and Microsoft Online Services like Office 365 and Microsoft Intune. For more information on Azure AD PIM,  click here .

Like all organizations, we want to minimize the number of people who have access to our secure information or resources, because that reduces the chance of a malicious user getting access or an authorized user inadvertently impacting a sensitive resource. However, our people still need to carry out privileged operations in Azure AD, Azure, Office 365, and SaaS apps. We can give users privileged access to Azure resources like Subscriptions, and Azure AD. Oversight is needed for what our users are doing with their admin privileges. We use Azure AD PIM to mitigate the risk of excessive, unnecessary, and misused access rights.

We use Azure AD PIM in the following ways:

• See which users are assigned privileged roles to manage Azure resources, as well as which users are assigned administrative roles in Azure AD.
• Enable on-demand, “just in time” administrative access to Microsoft Online Services like Office 365 and Intune, and to Azure resources of subscriptions, resource groups, and individual resources such as Virtual Machines.
• See a history of administrator activation, including what changes administrators made to Azure resources.
• Get alerts about changes in administrator assignments.
• Require approval to activate Azure AD privileged admin roles.
• Review membership of administrative roles and require users to provide a justification for continued membership.

In Azure AD, we use Azure AD PIM to manage the users we assign to built-in Azure AD organizational roles, such as Global Administrator. In Azure, we use Azure AD PIM to manage our users and groups that we assign via Azure RBAC roles, including Owner and Contributor.

Related Stories

Creating a modern data governance strategy to accelerate digital transformation at Microsoft

This content has been archived, and while it was correct at time of publication, it may no longer be accurate or reflect the current situation at Microsoft. Data is the new currency of digital transformation. Whether it’s providing new insights, improving decision making, or driving better business outcomes, enthusiasm for unlocking the power of data... Read more

How Microsoft used change management best practices to launch a new business intelligence platform

This content has been archived, and while it was correct at time of publication, it may no longer be accurate or reflect the current situation at Microsoft. It was time for a fresh approach to data analysis at Microsoft, one that would make it easier to track sales and operations activities across regions and roles.... Read more

Bringing Microsoft’s commerce platform to Microsoft Azure

This content has been archived, and while it was correct at time of publication, it may no longer be accurate or reflect the current situation at Microsoft. For almost 20 years, our Microsoft’s Commerce Transaction Platform (CTP) processed online payments through an on-premises environment, verifying that all transactions had been processed, sales had been finalized,... Read more

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.

Using Azure policies to audit and automate RBAC role assignments

Usually different RBAC role assignments in Azure might be inherited from subscription / management group level but there may come a time when that's just way too broad spectrum to give permissions to an AD user group.

While it’s tempting to assign permissions on a larger scope, sometimes you might rather prefer to have only some of the subscription’s resource groups granted with a RBAC role with minimal permissions to accomplish the task at hand. In those scenarios you’ll usually end up with one of the following options to handle the role assignments:

• Include the role assignments in your ARM templates / Terraform codes / Bicep templates
• Manually add the role to proper resource groups

If neither these appeal to you, there’s a third option: define an Azure policy which identifies correct resource groups and then deploys RBAC role assignments automatically if conditions are met. This blog will go over with step-by-step instructions how to:

• Create a custom Azure policy definition for assigning Contributor RBAC role for an Azure AD group
• Create a custom RBAC role for policy deployments and add it to your policy definition
• Create an assignment for the custom policy

The example scenario is very specific and the policy definition is created to match this particular scenario. You can use the solution provided in this post as a basis to create something that fits exactly to your needs.

Azure policies in brief

Azure policies are a handy way to add automation and audit functionality to your cloud subscriptions. The policies can be applied to make sure resources are created following the company’s cloud governance guidelines for resource tagging or picking the right SKUs for VMs as an example. Microsoft provides a lot of different type built-in policies that are pretty much ready for assignment. However, for specific needs you’ll usually end up creating a custom policy that better suits your needs.

Using Azure policies is divided into two main steps:

• You need to define a policy which means creating a ruleset (policy rule) and actions (effect) to apply if a resource matches the defined rules.
• Then you must assign the policy to desired scope (management group / subscription / resource group / resource level). Assignment scope defines the maximum level of scanning if resources match the policy criteria. Usually the preferable levels are management group / subscription.

Depending on how you prefer governing your environment, you can resolve to use individual policies or group multiple policies into initiatives . Initiatives help you simplify assignments by working with groups instead of individual assignments. It also helps with handling service principal permissions. If you create a policy for enforcing 5 different tags, you’ll end up with having five service principals with the same permissions if you don’t use an initiative that groups the policies into one.

Creating the policy definition for assignment of Contributor RBAC role

The RBAC role assignment can be done with policy that targets the wanted scope of resources through policy rules. So first we’ll start with defining some basic properties for our policy which tells the other users what this policy is meant for. Few mentions:

• Policy type = custom . Everything that’s not built-in is custom.
• Mode = all since we won’t be creating a policy that enforces tags or locations
• Category can be anything you like. We’ll use “Role assignment” as an example

Now we have our policy’s base information set. It’s time to form a policy rule. The policy rule consists of two blocks: policyRule and then . First one is the actual rule definition and the latter is the definition of what should be done when conditions are met. We’ll want to target only a few specific resource groups so the scope can be narrowed down with tag evaluations and resource group name conventions. To do this let’s slap an allOf operator (which is kind of like the logical operator ‘and’) to the policy rule and set up the rules

As can be seen from the JSON, the policy is applied to a resource (or actually a resource group) if

• It’s type of Microsoft.Resources/subscriptions/resourceGroups = the target resource is a resource group
• It has a tag named RbacAssignment set to true
• The resource group name starts with my-rg-prefix

In order for the policy to actually do something, an effect must be defined. Because we want the role assignment to be automated, the deployIfNotExists effect is perfect. Few mentions of how to set up an effect:

• The most important stuff is in the details block
• The type of the deployment and the scope of an existence check is Microsoft.Authorization/roleAssignments for RBAC role assignments
• An existence condition is kind of an another if block: the policy rule checks if a resource matches the conditions which makes it applicable for the policy. Existence check then confirms if the requirements of the details are met. If not, an ARM template will be deployed to the scoped resource

The existence condition of then block in the code example below checks the role assignment for a principal id through combination of Microsoft.Authorization/roleAssignments/roleDefinitionId and Microsoft.Authorization/roleAssignments/principalId . Since we want to assign the policy to a subscription, roleDefinitionId path must include the /subscriptions/<your_subscription_id>/.. in order for the policy to work properly.

The last thing to add is the actual ARM template that will be deployed if existence conditions are not met. The template itself is fairly simple since it’s only containing the definitions for a RBAC role assignment.

And that’s it! Now we have the policy definition set up for checking and remediating default RBAC role assignment for our subscription. If the automated deployment feels too daunting, the effect can be swapped to auditIfNotExist version. That way you won’t be deploying anything automatically but you can simply audit all the resource groups in the scope for default RBAC role assignments.

That should be enough, right? Well it isn’t. Since we’re using ARM template deployment with our policy, we must add a role with privileges to create remediation tasks which essentially means we must add a role that has privileges to create and validate resource deployments. Azure doesn’t provide such policy with minimal privileges out-of-the-box since the scope that has all the permissions we need is Owner. We naturally don’t want to give Owner permissions to anything if we reeeeeally don’t have to. The solution: create a custom RBAC role for Azure Policy remediation tasks.

Create custom RBAC role for policy remediation

Luckily creating a new RBAC role for our needs is a fairly straightforward task. You can create new roles in Azure portal or with Powershell or Azure CLI. Depending on your desire and permissions to go around in Azure, you’ll want to create the new role into a management group or a subscription to contain it to a level where it is needed. Of course there’s no harm done to spread that role to wider area of your Azure environment, but for the sake of keeping everything tidy, we’ll create the new role to one subscription since it’s not needed elsewhere for the moment.

Note that the custom role only allows anyone to validate and create deployments. That’s not enough to actually do anything. You’ll need to combine the deployment role with a role that has permissions to do the stuff set in deployment. For RBAC role assignments you’d need to add “User Access Administrator” role to the deployer as well.

Here’s how to do it in Azure portal:

• Go to your subscription listing in Azure, pick the subscription you want to add the role to and head on to Access control (IAM) tab.
• From the top toolbar, click on the “Add” menu and select “Add custom role”.
• Give your role a clear, descriptive name such as Least privilege deployer or something else that you think is more descriptive.
• Add a description.
• Add permissions Microsoft.Resources/deployments/validate/action and Microsoft.Resources/deployments/write to the role.
• Set the assignable scope to your subscription.
• Review everything and save.

After the role is created, check it’s properties and take note of the role id. Next we’ll need to update the policy definition made earlier in order to get the new RBAC role assigned to the service principal during policy initiative assignment.

So from the template, change this in effect block:

Assigning the created policy

Creating the policy definition is not enough for the policy to take effect. As mentioned before, the definition is merely a ruleset created for assigning the policy and does nothing without the policy assignment. Like definitions, assignments can be set to desired scope. Depending on your policy, you can set the policy for management group level or individual assignments to subscription level with property values that fit each individual subscription as needed.

Open Azure Policy and select “Assignment” from the left side menu. You can find “Assign policy” from the top toolbar. There’s a few considerations that you should go over when you’re assigning a policy:

• The scope: always think about your assignment scope before blindly assigning policies that modify your environment.
• Exclusion is a possibility, not a necessity. Should you re-evaluate the policy definition if you find yourself adding a lot of exclusions?
• You can fix all the non-compliant resources with a remediation task after initial compliance scan

Remediation

• If you have a policy that changes something either with modify of deployIfNotExists effect, you’ll be creating a service principal for implementing the changes when you assign the policy. Be sure to check the location (region) of the service principal that it matches your desired location.
• If you select to create a remediation tasks upon assignment, it will implement the changes in policy to existing resources . So if you have doubts if the policy works as you desire, do not create a remediation task during assignment. Review the compliance results first, then create the remediation task if everything’s ok.

Non-compliance message

• It’s usually a good idea to create a custom non-compliance message for your own custom definitions.

After you’ve set up all relevant stuff for the assignment and created it, it’s time to wait for the compliance checks to go through. When you’ve created an assignment, the first compliance check cycle is done usually within 30 minutes of the assignment creation. After the first cycle, compliance is evaluated once every 24 hours or whenever the assigned policy definitions are changed. If that’s not fast enough for you, you can always trigger an on-demand evaluation scan .

Subscribe for Practical 365 updates

Please turn off your ad blocker and refresh the page to subscribe.

You may withdraw your consent at any time. Please visit our Privacy Statement for additional information

Microsoft 365

Securing administrator access with privileged identity management for azure active directory.

Table of Contents

In any IT organization there are administrative tasks that need powerful admin privileges. It’s a good security practice that accounts should have the fewest permissions necessary, and only for the period of time they need them. But managing the temporary assignment of admin permissions becomes time consuming. As a result, many organizations assign them on a permanent basis, which is not ideal.

Furthermore, auditing the assignment of administrative permissions is a challenging task. Many of us have used custom scripts and third party reporting tools to keep track of permissions.

In Azure Active Directory we can use Privileged Identity Management (PIM) to solve those problems. PIM allows you to grant permissions for an administrator on a temporary basis. PIM also provides approval controls, alerting, and reporting for administrator assignments.

In this blog post I’m going to walk-though the basic PIM setup within Azure Active Directory.

Privileged Identity Management Licensing

PIM is a premium feature of Azure Active Directory, and as such does need licensing. The license required is Azure AD Premium P2, which is available as a standalone add-on license. You can also buy it as part of the Enterprise Mobility + Security (EM+S) E5 license bundle.

You will need an Azure AD Premium P2 license for each user that interacts with PIM. That includes users who are receiving administrator assignments, as well as those who are involved in approvals and reviews.

For this scenario I have a single EM+S E5 license assigned to my main admin account in Office 365. I will be using PIM to grant admin permissions to a user account, Ted Tester.

Enabling Privileged Identity Management

To enable PIM, open the Azure portal and navigate to Privileged Identity Management . Then go to Azure AD Directory Roles – Overview , and click on Wizard .

Open the wizard and let it discover the admin roles setup in your tenant. Don’t try to configure anything at this point. Let the wizard activate PIM in your tenant. The account that you are using at this stage will be the first Security Administrator in your tenant.

Once the wizard completes it may take some time before you can assign permissions to users. I needed to wait about half an hour before I could proceed.

Configuring Roles in Privileged Identity Management

Next, we need to configure the specific actions for each role assigned via PIM. Navigate to Azure AD Directory Roles – Overview again, and then choose Settings -> Roles .

Select the role you will be assigning to one of your administrators. For this example I will be assigning the role “Exchange Administrator” to Ted.

On this screen, there are a few controls I want to call out:

• Maximum Activation Duration – The maximum number of hours that a user can request activation for. You should keep this as low as possible, but not so low that your users are under pressure to perform admin tasks in a rush.
• Notifications – The admin will receive a notification when a role is activated. This lets them know they can proceed with their admin tasks, and also alerts them to any unauthorized privilege escalation that may be occurring.
• Multi-Factor Authentication – This control can’t be disabled for high privilege roles. All users who have a PIM role activated will need to use MFA to activate that role.
• Selected Approver – These users can approve access requests for the role. It is important to note that the approvers do not need to have the rights they are granting.

Assigning PIM Roles to a User

To assign a PIM role to an administrator, first you must assign that role to the user’s account in the Office 365 portal.

Give that assignment a few minutes to replicate, then go back to the PIM roles wizard we used to activate PIM. Within the Wizard, select the first option to discover roles, and you’ll see the following screen.

These are the roles currently assigned within the tenant. This screen is informational, so click Next to proceed. This is where we active Privileged Identity Managemet for Ted’s Exchange Administrator permissions. Selection that assignment from the list, then click Next .

The next screen will verify your selection and configure PIM for Ted. At the end of this process, the Exchange Administrator role is removed from Ted’s account. In effect, he is a standard user again. But, he is now eligible to become an Exchange Administrator.

Requesting Activation of PIM Managed Roles

Logging into any Office 365 portal at Ted will only show user options now. If Ted needs to do some Exchange admin work, he can request to have his permissions elevated via the Azure AD portal .

When Ted logs into the PIM management tool, under My roles he’ll see roles that he is eligible to request for activation.

Selecting Exchange Administrator will take him to the activation screen.

Ted will need to verify himself with multi-factor authentication before proceeding. If MFA is not already enforced for the user, they’ll be prompted to register. I recommend configuring MFA for your administrators before you start assigning PIM roles.

Once Ted passes the MFA , he can select Activate to request rights elevation.

Authorizing PIM Role Activation

For this example, I am listed as an approver. This means I can see and approve Ted’s request in the PIM portal.

I can approve or reject Ted’s request, and also add notes justifying my action.

While testing PIM in my tenant saw a delay of 30-45 minutes for Exchange permissions to take effect. Other workloads were almost instant. Once the rights kick in for Ted, he was able to perform tasks as an Exchange Administrator. The permissions are then automatically revoked at the end of the approval period.

That approval, and all the information I enter with it, is recorded in the My audit history section of the PIM control panel. In the screenshot below you can see the approvals I did for my test account during the process of writing this blog post.

Privileged Identity Management in Azure Active Directory is the solution for managing least privilege , “just in time” administrative access for Office 365 and Azure AD. As a premium feature it does require additional licensing. However, many organizations will benefit from the increased control that PIM provides for high privilege credentials, making the additional cost a worthwhile investment.

About the Author

Nathan O'Bryan

How do you assign approvers? I am not seeing any approvals, all requests are being automatically approved.

Pingback: Multi-factor Authentication by Default for Administrators in Azure AD and Office 365 – SimpleITPro

Nnice article.

There is a course available in Pluralsight about [Implementing Azure Privileged Identity Manager][Azure AD PIM].

http://www.pluralsight.com/courses/microsoft-azure-privileged-identity-management-implementing?utm_source=Facebook&utm_medium=video&utm_campaign=authordemo

Course Description: ——————- Privileged Identity Management is emerging as one of the hottest topics in cybersecurity. In this Pluralsight course, you’ll learn how to use Microsoft Azure PIM to manage, control, and monitor access within Azure AD, Azure resources, and Microsoft Online Services.

FYI that the picture before this sentence – “On this screen, there are a few controls I want to call out:” – is seemingly the wrong picture. I see the same picture that is showing again about two images down.

These are the similar features of MIM (Microsoft Identity Management) which is similarly called as PAM (Privilaged Access Management). Although the AAD P2 seems pricey, if some one know about the implementation of PAM, PAW under MIM, complexity involved in such configurations and the security benefits that an organization will benifit – will easily compensate the the price we pay for it. Its totally worth it, I hope there will be future enhancements to the PIM on the O365 Platform like what the rich reporting that we get from MIM.

Great feature but at the cost of AAD P2 a steep price.

What too many companies don’t / won’t consider is that P2 is not required for all users. It is only required for users that are actually going to use the P2 features.

In the case of PIM, a company can select to purchase P2 licensing only for employees who will need to access higher privilege roles. That prospect can provide a much better cost/risk balance for implementing PIM.

Leave a Reply Cancel reply

Latest articles.

Practical Protection: Copying Microsoft’s Secure Future Initiative

Microsoft recently released a memo from Security VP, Charlie Bell. In this blog, we recap the memo and discuss some of the new security initiatives Microsoft is working towards.

Leveling Up Privileged Identity Management with Approvals

In this blog, Brandon Colley reviews how to use PIM approvals to create a workflow that could stop attackers in their tracks, even if they have already compromised credentials.

Exchange Server Roadmap, New MS AI model on the way & Entra ID MFA: The Practical 365 Podcast S4 E19

On this week's episode, Paul and Steve cover several major Microsoft announcements impacting the future of AI, Exchange Server, and identity solutions.

Azure RBAC: role assignments and ARM templates

This post is about Azure's role assignments and ARM templates. Role assignments can be thought of as "permissions for Azure".

If you're deploying to Azure, there's a good chance you're using ARM templates to do so. Once you've got past "Hello World", you'll probably find yourself in a situation when you're deploying multiple types of resource to make your solution. For instance, you may be deploying an App Service alongside Key Vault and Storage .

One of the hardest things when it comes to deploying software and having it work, is permissions. Without adequate permissions configured, the most beautiful code can do nothing . Incidentally, this is a good thing. We're deploying to the web; many people are there, not all good. As a different kind of web-head once said:

Azure has great power and suggests you use it wisely .

Access management for cloud resources is critical for any organization that uses the cloud. Azure role-based access control (Azure RBAC) helps you manage who has access to Azure resources, what they can do with those resources, and what areas they have access to. Designating groups or individual roles responsible for specific functions in Azure helps avoid confusion that can lead to human and automation errors that create security risks. Restricting access based on the need to know and least privilege security principles is imperative for organizations that want to enforce security policies for data access.

This is good advice. With that in mind, how can we ensure that the different resources we're deploying to Azure can talk to one another?

Role (up for your) assignments ​

The answer is roles. There's a number of roles that exist in Azure that can be assigned to users, groups, service principals and managed identities. In our own case we're using managed identity for our resources. What we can do is use "role assignments" to give our managed identity access to given resources. Arturo Lucatero gives a great short explanation of this:

Whilst this explanation is delightfully simple, the actual implementation when it comes to ARM templates is a little more involved. Because now it's time to talk "magic" GUIDs. Consider the following truncated ARM template, which gives our managed identity (and hence our App Service which uses this identity) access to Key Vault and Storage:

Let's take a look at these three variables:

The three variables above contain the subscription resource ids for the roles Storage Blob Data Contributor , Key Vault Secrets Officer and Key Vault Crypto Officer . The first question on your mind is likely: "what is ba92f5b4-2d11-453d-a403-e96b0029c9fe and where does it come from?" Great question! Well, each of these GUIDs represents a built-in role in Azure RBAC. The ba92f5b4-2d11-453d-a403-e96b0029c9fe represents the Storage Blob Data Contributor role.

How can I look these up? Well, there's two ways; there's an article which documents them here or you could crack open the Cloud Shell and look up a role by GUID like so:

Or by name like so:

As you can see, the Actions section of the output above (and in even more detail on the linked article ) provides information about what the different roles can do. So if you're looking to enable one Azure resource to talk to another, you should be able to refer to these to identify a role that you might want to use.

Creating a role assignment ​

So now we understand how you identify the roles in question, let's take the final leap and look at assigning those roles to our managed identity. For each role assignment, you'll need a roleAssignments resource defined that looks like this:

Let's go through the above, significant property by significant property (it's also worth checking the official reference here ):

• type - the type of role assignment we want to create, for a key vault it's "Microsoft.KeyVault/vaults/providers/roleAssignments" , for storage it's "Microsoft.Storage/storageAccounts/providers/roleAssignments" . The pattern is that it's the resource type, followed by "/providers/roleAssignments" .
• dependsOn - before we can create a role assignment, we need the service principal we desire to permission (in our case a managed identity) to exist
• properties.roleDefinitionId - the role that we're assigning, provided as an id. So for this example it's the keyVaultCryptoOfficer variable, which was earlier defined as [subscriptionResourceId('Microsoft.Authorization/roleDefinitions', 'ba92f5b4-2d11-453d-a403-e96b0029c9fe')] . (Note the use of the GUID)
• properties.principalId - the id of the principal we're adding permissions for. In our case this is a managed identity (a type of service principal).
• properties.scope - we're modifying another resource; our key vault isn't defined in this ARM template and we want to specify the resource we're granting permissions to.
• properties.principalType - the type of principal that we're creating an assignment for; in our this is "ServicePrincipal" - our managed identity.

There is an alternate approach that you can use where the type is "Microsoft.Authorization/roleAssignments" . Whilst this also works, it displayed errors in the Azure tooling for VS Code . As such, we've opted not to use that approach in our ARM templates.

Many thanks to the awesome John McCormick who wrangled permissions with me until we bent Azure RBAC to our will.

• Role (up for your) assignments
• Creating a role assignment

Automating role assignment to temporary identities

To automate role assignment to temporary identities in Azure using Pulumi, you'd typically use a combination of Azure Active Directory (Azure AD) and Azure role-based access control (RBAC). The goal is to create temporary identities (service principals or managed identities) and assign them specific roles that allow them to perform certain actions within Azure.

Below is a Pulumi program written in TypeScript that demonstrates how you can automate the assignment of a role to a new Azure AD Service Principal. This Service Principal could represent a temporary identity for your application or infrastructure service.

This program uses the azuread and azure-native packages to:

• Create a new application in Azure AD.
• Create a service principal for the application.
• Assign a role to the service principal at a specific scope.

The particular role and scope should be substituted with the ones relevant to your use case. Here, I will use "Contributor" as an example role, and the scope will be a subscription.

To use the following Pulumi program, ensure you have Pulumi installed and configured for Azure. You also need to have Node.js installed to run TypeScript programs.

Explanation

Azure AD Application : This resource represents an application within Azure AD. The application doesn't perform any actions by itself, but it's used to define an identity for applications and services.

Service Principal : Linked to the Azure AD application, the service principal is the identity you assign roles to and authenticate as from your applications or services.

Role Assignment : This specifies what actions the service principal can perform. The "Contributor" role lets the service principal manage resources in the subscription but doesn't allow it to manage access.

The pulumi.interpolate function is used to create the resource strings dynamically based on the current subscription fetched via resources.getClientConfig() . The "Contributor" role is typically suitable for most actions that a service or application might perform in Azure, but you should choose the minimum required permissions for your specific needs.

Be sure to replace the role definition and scope to match your desired role and the scope you want to apply it to. Scope can be a subscription, a resource group, or a specific resource within Azure.

When you run this Pulumi program with pulumi up , it will perform the specified actions in Azure, and you'll be able to see the newly created application ID, service principal ID, and role assignment ID in the Pulumi stack's outputs.

• TS TypeScript
• JS JavaScript
• TF Terraform