Azure Privileged Identity Management (PIM)

Priviledged Identity Management (PIM) is an tool that allows you to securely manage Priviledged Identities in Azure. PIM allows you to assign which users are allowed to elevate to Priviledged Roles. Elevation can be time bound, limiting time that those accounts are elevated. Elevation can require approvals, which provides control over when elevations occur. Additionally, there is strong auditing and reporting on elevations, approvals, and assignments. In this article, I will cover how your organization can leverage PIM to securely Manage Priviledged Identities in Azure Active Directory. However, many of the concepts covered can be utilized for Privileged Identities in Azure. The difference is that these identities are delegated at the Subscription, Management Group, or Resource Group level.

As a side note, there is an aspect of my writing that you might find annoying. And if you do I apologize. I tend to capitalize words that represent aspects of technology. So, you will see me write Resource Group instead of resource group.

Our starting point is the Azure AD Portal. You can of use the Azure Portal. However, I find the AAD Portal less distracting.

Next you will want to Favorite Azure AD Privileged Identity Management, so that it shows up on the left-hand menu.

Next, click on Azure AD Privileged Management

Now, let’s become familiar with the UI. Tasks is where you will perform the majority of your work, once you have PIM configured. Tasks is also where your administrators will spend most of their time interfacing with PIM. Manage will be used primarily for setting up PIM. Activity is used for reviewing your activity in PIM. If you ever feel something strange is happening with your account, you can use this to determine if that is in fact the case.

Configuration
Click on Azure AD Roles to begin the configuration.

Here are your AD Roles that you can now configure. As you can see there are many roles. Some you will become familiar with, some you will not. No need to memorize every role. When you need to delegate access to perform a specific task, you can at that time investigate which role meets your needs.

We will use Global Administrator for an example of how to configure a role. So, locate that role either by scrolling or searching. Next, double click on Global Administrator to begin configuration.

Next, click on Settings to bring up, well the Settings : )

Here, we can see the Settings for the role. Click Edit to configure.

Activation Page
Activation maximum duration (hours)
This setting allows you to configure the duration of time for which a user will be elevated before they are “de-elevated”. Generally, you would want to set this at the average time a change normally takes for a Priviledged User. The maximum you should consider is a “typical” workday. So, generally 8 hours. So, many of us unfortunately do not have an actual workday that short, you have to draw the line somewhere to increase or maintain a certain level of security.

On activation require
This is where you can configure users to have to have MFA enabled to elevate. If the user has not previously configured MFA, they will need to register when they elevate for the first time. I personally think you would be making a huge mistake if you did not require MFA for elevation.

Require justification on activation
This requires the user to enter some text explaining why they are elevating. While it may seem like an inconvenience to users, it is actually in part to their benefit. If there are ever any questions on why they elevated, they can be quickly answered and justified with the information provided here.

Require ticket information on activation
In your environment you should without question require a change control entry prior to making changes to Azure AD. Most if not all change control systems leverage ticket numbers. For reporting and auditing purposes, it is extremely helpful if this is required. Again this protects the user, because if they are ever questioned on if they opened a change control entry for their change, they can reference it here.

Require approval to activate
So, this is a setting that definitely considers additional consideration as there are definitely some tradeoffs. The advantage to requiring approval is that it makes the environment secure. Because a user cannot act on their own to elevate. The disadvantage is what if a user needs to make an emergency change at 3:00 AM in the morning. Is the approver going to be awake to approve? Can you contact the approver? Will the approver be available at that time? If both the person that can make emergency changes and the approver are required to be available 24 x 7, or you otherwise have 24 x 7 coverage, then definitely utilize this setting. As with all of these settings these should be reviewed by your Information Security department, to ensure you meet the security requirements of your organization.

Assignment
Allow permanent eligible assignment
This allows the user to elevate, without their ability to elevate ever expiring. In other words, as you will see later, you can configure a period of time after which a user’s access needs to be removed. I would strongly advise against allowing permanent eligible assignment. As you are aware most organizations do a remarkably poor job of cleaning up accounts that should no longer have access. And this can be sort of a self-remediation for those accounts.

Expire eligible assignments after
As mentioned above this is a restriction of for how long the user has the ability to elevate. Your options at the time of this writing are 15 Days, 1 Month, 3 Month, 6 Months, or 1 year. Unless you have a lot of turnover you may want to go longer rather than shorter.

Allow permanent active assignment
So, based on what I mentioned above you may have been lead to believe that you would not want to Allow permanent active assignment. However, we have not discussed Break Glass accounts. These are Privileged accounts that persist in case no other accounts have access. These type of accounts are typically excluded from Conditional Access Policy. This is done so that if an administrator really misconfigures Conditional Access Policy, you still have a way to recover. So, for Break Glass Accounts you would want to have this configured. Which means you are really going to have two class of accounts Break Glass accounts and non-Break Glass accounts. Break Glass accounts would typically be permanent active assignments and non-Break Glass accounts would be temporary eligible accounts.

Expire active assignments after
If for whatever reason you decide to have temporary active assignments, then you can select how long before those active assignments expire. Your options at the time of this writing are 15 Days, 1 Month, 3 Month, 6 Months, or 1 year.

Require Azure Multi-Factor Authentication on active assignment
This setting does what it says that it does. If you are using active assignments for Break Glass accounts then you should not enable this setting. Any setting that interferes with a Break Glass account from logging in should not be configured. Obviously, extra controls need to be in place for these accounts. Some examples are restricting knowledge of the password, perhaps keeping in a physical or digital safe that is offline. Enabling auditing and especially alerting that sets of all sorts of alarms when someone logs in with the Break Glass account.

Require justification on active assignment. It would obviously be good to have a user have to give a justification when accepting an active assignment.

Notifications
I am not going to cover every option on this page as it is mostly self-explanatory. Basically, you can control whether the email alerts go to the Admin (Global Administrators), Assignee, and Approver. Additionally, you can additional recipients. And you can also configure the alerts so that Critical emails only are sent, which according to the page are: A mode where PIM only sends out emails requiring an immediate action.

And obviously you can complete configuration by selecting Update.

Assigning Roles
Now I am going to assign the Global Administrator role to a user.
Step 1: Starting from the PIM home, click on Azure AD roles

Step 2: Click on Roles

Step 3: Search for or locate the Global Administrator role

Step 4: Click Add assignments

Step 5: Under Select member(s), click on No member selected

Step 6: Search for or scroll to the user you want to assign this role
Step 7: Select the user and click Select

Step 8: Click Next or Setting

Step 9: Select Eligible or Active
Note: Previously I discussed the differences between Eligible and Active. However, for greater clarity I am going to use Microsoft’s verbiage to provide a second explanation.
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.
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.
Assign eligible owners and members for privileged access groups – Azure Active Directory | Microsoft Docs
Step 10: If necessary adjust the assignment start and end date
Step 11: Click Assign

You can now view your assignment for this role

Delegation
So, roles such as Global Administrator are delegated at the Directory level. However, there is another level at which you can delegate. You can delegate at the Administrative Unit level. Administrative Units are basically a container if you will, that you add users or groups to, and then they can be controlled by a user who is delegated “permissions” to the Administrative Units. Some, like to compare Administrative Units to Organizational Units in Active Directory. Others do not prefer that comparison. I personally do not like to make the comparison because these are two different and distinct things.

The following roles can be delegated to an Administrative Unit:
• Authentication Administrator
• Groups Administrator
• Helpdesk Administrator
• License Administrator
• Password Administrator
• SharePoint Administrator
• Teams Administrator
• Teams Devices Administrator
• User Administrators
When assigning roles that can be assigned to Administrative Units, you have the option to select Administrative unit or Directory.

Then in order to select the Administrative unit, under Selected scope click on No scope selected

Then either search for or scroll to the Administrative Unit and click Select

Alternative Method to Assign Roles
Step 1: When in the Privileged Identity Management view, select Assignments

Here you will see all of the Eligible assignments
Step 2: Click Add assignments

Step 3: Select the role you want to assign. In this instance I selected Global Administrator
Step 4: Click on No member selected
Step 5: Choose a member and click Select

Step 6: Select Next

Step 7: Decide on whether to make the assignment Eligible or Active. Remember Active assignments should be reserved for Break Glass accounts.

The account is now eligible to elevate to Global Administrator

Elevating
Below is the process for the user to elevate
Step 1: Starting from the Privileged Identity Management view, click on My roles

You will now see your Eligible assignments
Step 2: For the role you want to elevate to, click Activate

Step 3: Enter whatever information is required to elevate. In this case a Reason is required. Enter a Reason and click Activate. Optionally, configure a Custom activation start time.

Once your elevation is approved, it will show up under Active assignments

Approving requests
Step 1: To approve requests click on Approve requests
Step 2: Locate the request you want to approve
Step 3: Select the elevation you want to approve
Step 4: Click Approve

Step 5: Enter a Justification and click Confirm

Self Audit
To review your own activity in PIM, select My audit history

You can then view and search activity

Privileged Access Groups
Privileged Access Groups is a feature that is currently in Preview, or at least at the time of this writing. This feature allows you to assign Roles to a group. So, for example if you have a position in your organization where a user needs two Azure AD roles. You can create a Privileged access group to have those two roles. Then when you want to assign a user to those two roles for the position, you just add that user as a Member of the Privileged access group.

Assigning roles
First step is when creating a group is to select Yes for Azure AD roles can be assigned to the group

One you create the Group, you can go to Azure AD Portal and select Groups

Next you click on the Group you created. In this example Branch User Administrator

Next you click on Assigned roles

Now to add your roles, click Add assignments

Select the role you want to add and click Next

Determine if you want the role to become Eligible or Active. Also determine if you want to make the role Permanently eligible or Permanently Active. And adjust the assignment dates if necessary.
Finally click Assign

So, I then went and assigned a second role

Provisioning members
To provision members click on Privileged access (Preview)

Choose Member as the role. Then click on No member selected. Select a Member and click on Select.

Click Next

Then choose whether you want to make the Member Eligible or Active. You make the user Eligible if you want them to activate their membership in the group. If you want to just provision the user then click Active.

Finally, click Assign

Activate your Membership in the Privilege access group
If you a user was made eligible instead of active, they will need to accept the assignment.