Skip to main content

Priviledged Identity Management in Azure AD

What is it?

Privileged Identity Management or PIM is a service that provides just in time access to privileged roles in Azure and Azure AD. It does this with an approval process which can be manual or automatic. This article will concentrate solely on the Azure AD setup and management of PIM. 

What is required?

An Azure P2 license. This can be purchased as a standalone license or as part of the EMS E5 license suite. A Global Administrator account will have access to administer PIM by default, but an account can also be added to the Privileged Identity Administrator role for this purpose. A good understanding of the process, which accounts will be managed this way, and why is required is important. It is also necessary to identify who will be responsible for approving, renewing, and reviewing privileged accounts in Azure Active Directory.  

Where do I find PIM?

PIM can be found by logging into https://portal.azure.com and searching for PIM and clicking on "Azure AD Privileged Identity Management".


How do I set it up?

The first thing to note is that there are two versions of PIM. Since Nov 2019 there has been a new version, the instructions here are based on the new look dashboard. How do you know which version you are using? There should be a banner on opening PIM informing you which you are using. 

The image above clearly shows that this tenancy is on the latest version. There should be few tenancies left with the old version, but it is worth pointing out in case you have a very different looking dashboard. If you have the old version please see this guide from Microsoft: https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-how-to-activate-role?tabs=previous

Here is the PIM blade in the Azure portal.


To get started either click "Azure AD roles", "Roles" or simply click "Manage" under the "Manage access" section in the "Get started" pane. Here you will see the roles and can begin setting them up to your requirements. To begin, select one of the roles. For this part of the demonstration, the "Global Administrator" account PIM settings will be configured. This is a great starting place but should not be where the PIM journey ends. It is recommended to start with the Global Administrator and the Security Administrator accounts. As two of the most powerful accounts, protecting them represents a quick win. Once this has been trialled, it is recommended to add the "usual" administrator accounts to the mix. Here are the most protected accounts according to Microsoft:

Ten most protected administrator accounts: -

1. Global administrator
2. Security administrator
3. User administrator
4. Exchange administrator
5. SharePoint administrator
6. Intune administrator
7. Security Reader
8. Service administrator
9. Billing administrator
10. Skype for Business administrator.

Click the required role. 


As you will see in the image below, there is already one "eligible" user for Global Administrator (GA) access. 


An "eligible" account is one with privileges to request, or self-elevate their permissions to add the role for which they are eligible. In this case, the role is the global administrator or GA access. 

Click on the "Active assignments" to quickly see who has elevated privileges. In the image below you can see that both administrator accounts have a permanent assignment of the GA role.


These permanent assignments should be the exception, not the rule. Make as many accounts as possible eligible rather than permanently assigned. Click "Settings". The following image shows a summary of the PIM settings.


Settings: - 

Activation section

Activation maximum duration (hours): - here it is important to strike a balance between usability and security. This can take some adjustment both in your company processes and within these settings. Eight hours is the default which should cover a working day, but if the administrators do not typically need a full day of access, this can be reduced. Here it could be useful to sit with a typical administrator and see what roles they use and how often. Remember: - always start small then branch out when you are happy with the process. 

Require justification on activation: - if administrators are committed to giving a justification beyond "I need it for my job" this setting can be useful to review regularly and see if the usage fits in with your understanding of administrator permissions before the project kickoff. 

Require ticket information on activation: - this is an important one. If the company has any ambitions to follow an ISO or similar standard, or even if they need to provide some accountability for work carried out then every activity should be backed up with a ticket or project number.

Require approval to activate: - this is an interesting one, and there is no straight forward answer as to if you should set this or not. If the approvals are not going to be too numerous then approval should be sought. If this is going to be too tying for one or more individuals to approve, leave this turned off. What then is the point of having a time limit I hear you ask? (Maybe that's just the voices in my head). The point is if an administrator automatically enables their GA access first thing in the morning and has eight hours of elevated access, this expires. When they have gone home or commuted to their living room in today's global situation, the access expires. Any attacks on the account during this time will be on an account without elevated privileges. This limits the usefulness of the compromised account to any attacker who may need to find other means to get to their nefarious business. 

Approvers: - the approvers can be individuals or a group. It is best to assign the approver role to a group as individuals can be tied up in meetings, be off shift, on a break, etc. To set this click "Edit". 
  


Tick "Require approval to activate" and click the "+" symbol to select your approver.


Click "Update" if no other changes are required. 


Back to the settings page. 

Assignment section

Allow permanent eligible assignment: - is it a requirement for the account to have permanent eligibility for the role? If this is not ticked, a box appears allowing the length of time eligible assignments are valid. The image below shows the options available. 
Expire eligible assignments after: - 



This setting requires a bit of a judgment call and a bit of realism. How often are reviews required? Who is going to do the renewal? These should be reviewed regularly, but consider that approvers may have holidays. What happens then? Does the business grind to a halt because the permissions have expired and nobody is around to approve renewal requests?

Allow permanent active assignment: - This is the same deal as the eligible assignment settings, but are applied to permanent active assignments. Do you want to allow accounts to have permissions permanently assigned? If not, specify the amount of time you wish the assignment to be active in the next drop-down box. 
Expire active assignments after: -



Require Azure Multi-Factor Authentication on active assignment: - is MFA required once these permissions become active? That's a big yes. If MFA isn't set up in the environment, what are you waiting for? Stop right now and go and sort it out. At the very least the administrators should be protected by MFA. 

Require justification on active assignment: - make the administrator requesting access provide a reason for requesting the access. To see where administrators can view the reasons given, see the section on "Audit logs".  

Following the settings section described above is the all-important alert section. There are three areas of concern:

1. Send notification when members are assigned as eligible to this role
2. Send notifications when members are assigned as active to this role
3. Send notifications when eligible members activate this role.

In these areas there are three settings that are common to each area:

1. Role assignment alert
2. Notification to the assigned user (assignee)
3. Request to approve a role assignment renewal/extension. 

The image below shows the available options for notifications.


These are fairly self-explanatory, except perhaps "Critical emails only". This warrants further explanation. Clicking on the information icon produces the following explanation.


Clear as mud, right? below is a better explanation:

"For each type of email, you can select the checkbox to receive critical emails only. What this means is that Privileged Identity Management will continue to send emails to the configured recipients only when the email requires an immediate action. For example, emails asking users to extend their role assignment will not be triggered while an emails requiring admins to approve an extension request will be triggered" from https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-resource-roles-configure-role-settings.

Add any additional recipients required, click "Update".


The Global Administrator account is now configured for Privileged Identity Management. Update the other accounts and you are done. 

Admin experience

To add a user to eligibility for a role, click "Azure AD Roles" from the main menu then click "Assignments".

In the Privileged Identity Management console click roles and click the role you need to update. In this example, the "Global Reader" role will be used.  


Click "Add assignments".


Click the link under "Select members".


Find the eligible user. Select the user and click the "Select" button. 



Click "Next"

Select an assignment type, so whether or not the assignment is permanent. If the role is for a temporary employee for example a contractor or a partner, consider setting an assignment end date. This can be reviewed and extended nearer the expiry date if required. For this demonstration "Permanently eligible" is selected (we think this one is going to stay awhile). Click "Assign".


The image above shows what that should look like when it's finished. 

User experience

When you need to activate a role as administrator, you will need to sign in to the Azure Portal (https://portal.office.com), search for and open Privileged Identity Management. Click "My roles"


Click "Activate" which will be located at the end of the row.  


Depending on the settings in your tenancy, a window similar to the image below will be shown.


Here a custom activation start time has been selected. This can be done in advance if a change is being made out of hours for example. Select the amount of time for which this role is required. The settings in this tenancy allow a maximum of eight hours. Select as per your requirement and add a descriptive reason for the required access and click "Activate". Note: - it can take around 15 minutes for the permissions to be assigned. 

Approval

A PIM administrator needs to log in to PIM and click "Approve requests" in the main menu, or they can click the link in a request email.


Click the tick box next to the request. Click "Approve" or "Deny" as appropriate.


For the demonstration "Approve" was selected. Because of the settings assigned to the GA accounts in PIM a request for a justification was presented. Provide a justification and click "Confirm".


The request will disappear from the "Approve requests" blade. The approving administrator will receive an email confirming the approval has been granted. 


 

Renewal

Renewal email alerts are sent 14 days before, 1 day before, and on the day of role expiry. These alerts are sent to admins and affected users. See the image below to see what the email alerts look like. Click "Renew assignment" in the email.


Click "Remove", "Update", or "Extend" as required. In the example below "Extend" is greyed out because the assignment has already expired. For this demonstration "Update" has been selected.



Select the assignment type, select if they are permanently eligible and when the assignment ends. Click "Save"


If remove is selected, a confirmation box is shown. Click "Yes".


Alerts

If alert emails are configured, the can be used to view any actions carried out in PIM. Alternatively, see the "Audit logs" section later in the article for more information. Click "View history" in the alert email 


This takes you to the resource audit page. 


Here you can view the actions that have been applied through PIM. 

Audit logs

"My audit history" is clearly visible in the main PIM menu, but what if an administrator wants to view all activity and see reasons that other administrators have requested elevated access? On the quick start page (the default starting page) click "Discover" under the "Discover and monitor" section.  


Click one of the "Principal names" under the role you wish to audit.


Click "Audit logs" under "Activity". Change the filters to suit.


Click an entry to see more detail. Here "STATUS REASON" can be viewed along with other important details. 


Quite why you have to go through so many hoops to get to the audit logs is beyond me. Hopefully, Microsoft will add "Audit logs" to the main menu to avoid this palaver. 

Access Reviews

The image below shows the email that will be received when an access review is required. Click "Start review" from the email request, or click "Review Access" on the main PIM menu and select the review. 


Scroll down, click on the required user. Specify the reason the role is granted, or not granted and click "Approve" or "Deny" as required. 



Once approved, the requesting administrator will receive an email informing them that their request has been approved. 


Summary

We have examined what PIM is, what requirements there are, how to use it from a PIM administrator points of view, and from the requestor point of view. We have explored access reviews, audit logs, and the most important settings. Hopefully, this article has been of some use. If so, please leave a comment.  







Comments

Popular posts from this blog

Session control policies in Microsoft Defender for Cloud Apps - block copy, cut, and paste in web apps

In this article, I attempt to outline the process for creating session control policies using Conditional Access (CA) and Microsoft Defender for Cloud Apps or MDA for short. When I first set this up, I was unaware of the need to have a user sign in between setting up the CA policy and setting up the policy in MDCA which then allows session control policies to be applied. I will guide you through this, the policy setup and testing.  An overview of the setup process looks like this: 1. Setup the CA policy 2. Have a user login 3. Apply the MDA access policy and add your conditions.  4. Test it 1. Setup the CA policy Pre-requisites: -  a. the app should be available as an "Enterprise App" in Azure AD. Secondly, the app should support and be configured for SAML SSO.  b. Azure AD P1 licenses are required. My understanding was always that MDA required Microsoft 365 E5 or equivalent licenses for applying policies, but Microsoft states in the following article that Azure AD P1 license

Microsoft Purview Endpoint DLP for MacOS

Get onboarded The first step is to get the macOS device enrolled in Intune for easy management. To do so, follow this guide: https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-your-device-in-intune-macos-cp The guide is a little out of date, but the principals work all the same. Now to get the device onboarded into Microsoft Purview. https://learn.microsoft.com/en-us/microsoft-365/compliance/device-onboarding-offboarding-macos-intune?view=o365-worldwide As you will have seen in the article above, onboarding uses the same mechanism for onboarding macOS to MDE. Once the configuration profiles are installed as seen in Intune > Devices > macOS > macOS devices > click the device name > Device configuration . They should have a nice green tick next to the word “Succeeded” under the “State” header. I had a bit of a brain spasm with the naming, I would use Microsoft’s naming suggestion as seen in their guide.   Create the DLP policy To configure the DLP