Azure Privileged Identity Managment
How it works
At large PIM is divided into four sections: Request, Approval, Configuring and Audit. Each section is pretty self-explanatory and when you select each one in the interface a unique page is presented. Below is the breakdown of each section in the order you will likely use them:
Once you have enabled PIM within Azure Active Directory you will need to create assignments. You can create assignments for Azure AD roles, PIM Groups and Azure Resources. Assignments control who and how people have access to a role.
You first need to configure what role you want to create an assignment for and add the identities you want to be able to access the role. You can use privileged groups here if you want to.
You then need to set the controls you want to place on the assignment. Best practice is to keep the assignment as short as time as possible and always use the 'Eligible' assignment type. The assignment types are described below
- Eligible - The identities attached to the assignment are permitted to assign themselves the role.
- Active - The identities attached to the assignment are actively in the role.
Hopefully, it's obvious using the above descriptions why using the 'Eligible' assignment type everywhere is a good idea. Users can still gain access to the role they just have to navigate to the interface.
You now want to configure the role so that least privilege principals are always applied. Keeping the activation time to a minimum enables users to only have access when they are actually completing work (Identities are removed from the role automatically once it lapses) . Additionally, you should use 'Require approval' where you can, it can be very useful when you have junior members in teams.
Once you have configured your roles and assignments those assigned to users will appear in the PIM interface like so:
Selecting activate next to each role will begin the approval process (if implemented). If you are forcing the user to use MFA they will have to select the box at the top of the approval page, and it will redirect them to a login page. If you have configured the role to send a request for approval it will appear as such in the approver's interface
You get pretty much all the information you need to make an informed decision as to whether to approve a request. If the request is ADHOC obviously make sure you ensure there is an appropriate behavior change whereby users are providing as verbose as possible request reasons.
There are a lot of different pages/interfaces within PIM for auditing largely because they decided to create an overview page and a page unique to each feature. Below I've listed the most impactful ones
Details the changes made within PIM including the activation of roles and requests made for access.
Simple recommendations based on the current configuration/posture of Azure PIM.
Alerts with changeable thresholds.
This is probably my favourite audit feature as it basically builds an audit workflow for you. You can configure audit reviews to take action once their thresholds have been breached. This can be used to prevent stale assignments.
At large logs generated by PIM are denoted with the string "PIM" so you can easily find them in your workspace. They appear much like the standard "Add User", "Create Group" etc logs in the AuditLogs table except with some additional data fields such as 'ResultDescription (Request Reason)'. I think the logs are verbose enough for me and you could even explore building a workbook around the frequency of requests by role, user, time etc.
If you wanted to be really fancy, you could implement an org policy where all users are mandated to enter a change number or some sort of reference back to a tracking system and then build a detection around request reasons that do not match the org policy. I've put an example below:
// Assuming each user is required to input a change number of the format C11432A
| extend RequestReason = tostring(TargetResources.displayName)
| where RequestReason matches regex @"([C](.*?)[A])"
Personally, I like Azure PIM as it makes implementing least privilege principles in Azure very easy and enables you to enforce a separation between your cloud infrastructure and on-prem because you don't need to use your on-prem tools to manage the identities. The interface definitely needs more work because it can get almost disorientating when clicking through features only to arrive at the same place several times. If you do a lot of building or operations in Azure, you definitively want to use PIM to at a minimum manage your highest privilege roles such as Global Administrator. I can see a reduction in value for smaller teams where there's literally only two or so people who build things in azure.