Scenario:
As part of their cloud-strategy, your organization migrated to Azure on an accelerated timescale. This often meant rules were “bent”, exceptions were handed out freely, and access governance was overlooked. Now that the Azure Data-center is stable, you have been asked to reign in privileged accesses in Azure and put in a robust control process to manage privileged access.
Why PIM?
Azure PIM is tightly integrated with Azure AD Roles, which in turn governs many of the privileged roles in other Microsoft services like Office365, CRM etc. Note the caveat regarding Exchange Online and SharePoint Online as explained here. The following features make it very
1. Simple request and approval process
2. Strong audit capabilities
3. Simple configuration on a per Role basis
4. Included in Azure Premium P2 or EMS E5 or M365 M5 (at least one of which is what you should already have if you are serious about your investments in Azure). The official PIM deployment guide covers other reasons in detail here.
Before you deploy PIM:
Azure PIM deployment is straightforward for the most-part. There are however some… unique properties about its implementation that you need to be aware of:
1. There is no going back
As of this writing (30 May 2019), I have not found a way to disable or un-enroll from PIM once you click the consent button. This is not necessarily a bad thing. Turning it on really has no downside that I came across. However, you can choose to stop using the just-in-time concept and make the managed roles as permanent assignments. This “rollback” procedure is explained here.
2. AzureAD Roles and AzureResources are two separate sections
After clicking the consent button, you must also onboard AzureAD roles. t’s probably best to focus on AzureAD roles first. The built-in roles limits your scope and reduces complexity. Managing Azure Resource roles can be a but more daunting depending on the complexity of you environment.
The complexity can be compounded by the fact that different roles are required to manage AzureAD roles and Azure Resource (see point 5).
3. Switching on PIM does not change any existing role assignments
This is not explicitly stated anywhere in the document, but it’s good to know that by switching on PIM, you will not be applying any changes automatically.
The onboarding process basically allows you to first discover privileged roles and assignments, review and change users, then apply changes (if any). Applying no changes essentially means all current role assignments will be treated as permanent. The discovery step is a powerful tool to give you up-to-date reports before you make changes to role assignments.
4. Understand the terminology
If you are new to the concept of privileged access management, it’s important to wrap your head around Azure PIMs terminologies. I always found it to be a bit of a misnomer to call it Privileged Identity Management, when it actually is managing roles, which I equate to Access. Terminology can be found in detail here.
5. PIM has it’s own roles, and you will need to decide who all manage PIM
A well-defined governance process is a must to effectively manage PIM. PIM comes with it’s own “Privileged Role Administrator” role, which only manages AzureAD roles, while Azure Resource requires Subscription Administrator, Resource Administrator and User Access Administrator. Read more details here.
6. PIM cannot manage all roles (yet?)
This is explained much better here. If your primary usecase is managing the roles mentioned in that link, PIM will not help. Also, note the caveat regarding possible delay in provisioning SharePoint Administrator role to eligible users.
It’s also a good idea to review the forums section for PIM to understand what features are currently not offered by PIM but users have requested for. The forum link is here.
Deploy Azure PIM
Assuming you have read through the lengthy documentation advising the deployment of Azure PIM (found here), let’s plan out the deployment.
- Initial deployment — In this stage, we are just going to enable PIM and allow it to discover the AzureAD roles. This will help provide reports directly from PIM that can be reviewed to configure role assignment settings as well as review role assignments to all admins for AzureAD. The steps are:
a. Consent to PIM — This just enables PIM on your tenant. There is pretty much no functionality available at this point.
b. Sign up AzureAD Role for PIM — This consents to PIM discovering AzureAD Role, turning on auditing of role assignments and enables alerts for certain usecases. - Review user and audit reports — This is most likely the longest and tiresome stage. The previous step enables you to leverage the features of PIM to plan your governance and management of privileges roles. The two reports generated in the steps below will help follow the recommendations as provided by Microsoft here.
a. Export the initial Role Assignment report — In the Azure AD Roles section, click on “Roles” under the “Manage” heading. You should see all AzureAD roles. Click the “Export” button to get a list of user and role assignments. You can validate that all role assignments are permanent at this point, thus ensuring no changes took place as part of onboarding AzureAD roles to PIM.
b. Export the initial Audit History report — In the Azure AD roles section, under “Activity” heading, click on “Directory roles audit history”. Your initial audit graph will show all the roles as having been activated the same day that you signed-up PIM for AzureAD roles. click on the “Export” button to get the list of assignment details. - Generate the project artifacts — As stated earlier, the most important part of your PIM deployment project will be the governance rules. Use the above reports to generate the following artificats:
a. Privileged Role Governance — This document will define the policy and procedure that administrators must follow to to use privileged roles in AzureAD.
b. Privileged Role Configuration — This document will define the configurations for each privileged role in scope. Config items like max duration of role assignment, approval requirement etc (described in detail here) must be documented before you roll it into PIM.
c. User Guide — Since the next steps will be testing and self-audit, you should by now have a user guide to help administrators understand how to use PIM for requesting roles, reviewing their access etc. - Initiate a self-audit — There may be administrators who have been assigned roles in the past and no longer need them. The Access Review section provides a way for you to initiate a self-audit where they can either remove their own roles, or provide a justification to keep their current roles. This becomes and audit artifact for later user, but also allows you to validate whether the justification matches the role assignment, or whether a lower role will meet the needs of the admin.
- Identify your test group — Again, using the Role Assignment report, identify your test user group so you can move them to the “eligible” category and test that you Privileged Role Configuration from the previous steps meets the requirements for your admins as well as for security and compliance.
- Rollout to production — Once testing is successful and you have UAT, you are ready to rollout the new Privileged Role Configuration setting in PIM for all users.
Steps 4, 5 and 6 may actually be carried out on a per role basis moving from high risk roles to lower risk roles, thus allowing for easy management. Start with Global Administrator and Security Administrator, and then move on to lower roles until eventually you can get to a situation where there is almost zero permanent assignments.
