Welcome back to part 2 of my series on Azure Active Directory Privileged Identity Management (AAD PIM).  In the first post I covered the basics of the service.  If you haven’t read it yet, take a few minutes to read through it because I’ll be jumping right into using the service going forward.  In this post I’m going to cover the setup process for AAD PIM.

Before you can begin using AAD PIM, you’ll need to purchase a license that includes the capability.  As we saw in my last post, at this time that means a standalone Azure AD Premium P2 or Enterprise Mobility + Security E5 license.  Once the license is registered as being purchased by your tenant, you’ll be able to setup AAD PIM.

Your first step is to log into the Azure Portal.  After you’ve logged in you’ll want to click the Create a Resource button and search for Azure AD Privileged Identity Management.

Select the search result and AAD PIM application will be displayed with the Create button.  Click the create button to spin the service up for your tenant.

It will only take a few seconds and you’ll be informed the service has successfully been spun up and you’ll be given the option to add a link to your dashboard.

The global admin who added AAD PIM to the tenant will become the first member of the Privileged Role Administrator role.  This is a new role that was introduced with the service.  Members of this role are your administrators of AAD PIM and has full read and write access to it.  Beware that other global admins, security administrators, and security readers only have read access to it.  As soon as you successfully spin up the service, you’ll want to add another Privileged Role Administrator as a backup.

Upon opening AAD PIM for the first time, you’ll receive a consent page as seen below.  The consent process requires confirmation of the user’s identity using Azure MFA.  If the user isn’t enabled for it, it will be configured at this point.

After successfully authenticating with Azure MFA. The screen will update to show the status check was completed as seen below. This is a great example of Microsoft exercising the concept of step-up authentication. The user may have authenticated to the Azure Portal with a password or perhaps a still-valid session cookie. By prompting for an Azure MFA challenge the assurance of the user being the real user is that much higher thus reducing the risk of the user accessing such sensitive configuration options.

After clicking the Consent button the service becomes fully usable.  The primary menu options are displayed as seen in the picture below.  For the purpose of this post we’re going to click on the Azure AD directory roles option under the Manage section.

The Manage section of the menu is refreshed and a number of new options are displayed.  Before I jump into the Wizard, I’ll navigate through each option in the section to explain its purpose.

The Roles option gives us a view of all of the users who are members of privileged roles within Azure AD  and Office 365.  In the activation column it’s shown as to whether or not the user is a permanent or eligible admin.  The expiration column shows any user that is eligible and has actively requested and been approved for temporary access to the privileged role.  As you can see from my screenshot from my test tenant I have a number of users in the global admin roles which is a big no no.  We’ll remediate that in a bit using the Wizard.

Selecting the Add user button brings up a new screen where new users can be configured for privileged roles.  Microsoft has done a good job of giving AAD PIM the capability of managing a multitude of Azure AD and Office 365 roles.  Adding users to roles through this tool will make automatically make the user an eligible for the role rather than a permanent member like through other means would.

The Filter button allows for robust filtering options including the permission state (all, eligible, permanent), activation state (all, active, or inactive), and by role.  The Refresh button’s function is obvious and the group option allows you to group the data either by user or by role.  The Review button allows you to kick off an access review which we’ll cover in a later post.  Lastly we have the Export button which exports the data to a CSV.

The Users option under the Manage section presents the same options as the Roles option except it takes a user-centric view.

The Alerts option under the Manage section displays the alerts referenced here.  You can see it is alerting me to the fact I have too many permanent global admins configured for my tenant.  I also have the option to run a manual scan rather than waiting on the next automatic scan.

The Access Reviews option under the Manage section is used to create new access review.  I’ll cover the capability in a future post.

Skipping over the Wizard option for a moment, we have the Settings option.  Here we can configure a variety of settings for roles, alerts, and access reviews.

Let’s dig into the settings for roles first.

Here we can configure the default settings for all roles as well as settings specific to one role.  When a user successfully activates a privileged role, the membership in that role is time bound with a default of one hour.  If after doing some baselining we find one hour is insufficient, we could bump it up to something higher.  We can also configure notifications to notify administrators of activation of a role.  There is also the option to require an incident or request reference that may map back to an internal incident management or request management system.  Azure MFA can be required when a user activates a role.  You’ll want to be aware that the MFA setting is automatically enforced for roles Microsoft views as critical such as global administrator.

Finally we have the option to require an approval.  If you’ve played around with AAD PIM since preview, you may remember the approval workflow.  For some reason the product team removed it when AAD PIM original went general available.  This effectively meant users could elevate their access whenever they wanted.  Sure they weren’t permanent members but there were no checks and balances.  For organizations with a high security posture it made AAD PIM of little value and forced the on-demand management of privileged roles to be done using complicated PowerShell scripts or third-party tools that were integrated with the Graph API.  It’s wonderful to see the product team responded to customer feedback and has added the feature back.

Toggling to Enable for the require approval option adds a section where you can select approvers for requests for the role.

Moving on to the Alerts settings we have the ability to configure parameters for some of the alerting as can be seen from the examples below.

The default values for the configurable thresholds around the “There are too many global administrator” should be a good wake up call to organizations as to the risk Microsoft associates with global admin access.  The thresholds for the “Roles are being activated too frequently” should be left as the default until the behavior of your user base is better understood.  This will help you to identify deviations from standard behavior indicating a possible threat as well as to identify opportunities to improve the user experience by bumping up the activation time span for users holding privileged roles that the hour long default activation time is insufficient.

Lastly we have Access Review settings.  Here we can enable or disable mail notifications to reviewers are the beginning and end of an access review.  Reminders can also be sent to reviewers if they have no completed a review they are a part of.  A very welcome feature of requiring reviewers to provide reasons for approvals of a review.  This can be helpful to capture business requirements as to why a user needs continued access to a role.  Finally, the default access review duration can be adjusted.

Now on to the Wizard.  The Wizard is a great tool to use when you first configure AAD PIM in order to get it up and running and begin capturing behavioral patterns.  The steps within the Wizard are outlined below.

The Discover privileged roles step displays a simple summary of the privileged roles in use and the amount of permanent and eligible users.  We can see from the below my tenant has exceeded either the 3 global admins or greater than 10% of users default thresholds for the “There are too many global admins” alert.  Selecting any of the roles displays a listing of the users holding permanent or eligible membership in the role.

Clicking the next button bring us to the “Convert users to eligible step” where we can begin converting permanent members to eligible members. From a best practices perspective, you should ensure you keep at least two permanent members in the Privileged Role Administrator role to avoid being locked out if one account becomes unavailable. You can see that I’m making Ash Williams and Jason Voorhies eligible members of the global admins group.

After clicking the Next button I’m moved to the “Review the changes to your users in the privileged roles” step.  I commit the changes by hitting the OK button and my two users are now setup as eligible members of the roles.

As you’ve seen throughout the post AAD PIM is incredibly easy to configure.  I firmly believe that the only successful security solutions moving forward will be solutions that are simple to use and transparent to the users.  These two traits will allow security professionals to focus less of their time on convoluted solutions and more time working directly with the business to drive real value to the organization.

I’m going to start something new with a quick bulleted list of key learning points that I came across while performing the lab and doing the research for the post.

• AAD PIM can be configured after the first Azure AD Premium P2 or EMS E5 license is associated with the tenant
• Be aware that at this time Microsoft does not enforce a technical control to prevent all users from benefiting from PIM but the licensing requirements require an individual license for each user benefitting from the feature.  Make sure you’re compliant with the licensing requirements and don’t build processes around what technical controls exist today. They will change.
• Once AAD PIM is activated by the first global admin, immediately assign a second user permanent membership in the Privileged Role Administrators role.

That’s it folks.  In the next post in my series I’ll take a look at what the user experience is like for a requestor and approver.  I’ll also look at some Fiddler captures to see I capture any detail as to how/if the modified privileges are reflected in the logical security token.

Thanks!