Exploring Azure AD Privileged Identity Management (PIM) – Part 2 – Setup

Exploring Azure AD Privileged Identity Management (PIM) – Part 2 – Setup

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.

1pim1.png

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.

1pim2.png

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.

1pim3.png

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.

1pim4.png

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.

1pim5

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.

1pim6.png

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.

1pim7.png

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.

1pim8.png

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.

1pim9.png

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.

1pim10.png

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.

1pim11.png

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.

1pim12.png

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.

1pim13.png

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.

1pim14

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.

1pim15.png

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.

1pim16.png

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.

1pim17.png

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.

1pim18.png

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!

 

Exploring Azure AD Privileged Identity Management (PIM) – Part 1

Exploring Azure AD Privileged Identity Management (PIM) – Part 1

We’re going to take a break from Azure Information Protection and shift our focus to Azure Active Directory Privileged Identity Management (AAD PIM).

If you’ve ever had to manage an application, you’re familiar with the challenge of trying to keep a balance between security and usability when it comes to privileged access.  In many cases you’re stuck with users that have permanent membership in privileged roles because the impact to usability of the application is far too great to manage that access on an “as needed basis” or as we refer to it in the industry “just in time” (JIT).   If you do manage to remove that permanent membership requirement (often referred to as standing privileged access) you’re typically stuck with a complicated automation solution or a convoluted engineering solution that gives you security but at the cost of usability and increasing operational complexity.

Not long ago the privileged roles within Azure Active Directory (AAD), Office 365 (O365), and Azure Role-Based Access Control had this same problem.  Either a user was a permanent member of the privileged role or you had to string together some type of request workflow that interacted with the Graph API or triggered a PowerShell script.  In my first entry into Azure AD, I had a convoluted manual process which involved requests, approvals, and a centralized password management system.  It worked, but it definitely impacted productivity.

Thankfully Microsoft (MS) has addressed this challenge with the introduction of Azure AD Privileged Identity Management (AAD PIM).  In simple terms AAD PIM introduces the concept of an “eligible” administrator which allows you to achieve that oh so wonderful JIT.  AAD PIM is capable of managing a wide variety of roles which is another area Microsoft has made major improvements on.  Just a few years ago close to everything required being in the Global Admin role which was a security nightmare.

In addition to JIT, AAD PIM also provides a solid level of logging and analytics, a centralized view into what users are members of privileged roles, alerting around the usage of privileged roles, approval workflow capabilities (love this feature), and even provides an access review capability to help with access certification campaigns.  You can interact with AAD PIM through the Azure Portal, Graph API, or PowerShell.

To get JIT you’ll need an Azure Active Directory Premium P2 or Enteprise Mobility and Security E5 license.  Microsoft states that every use that benefits from the feature requires a license.  While this is a licensing requirement, it’s not technically enforced as we see in my upcoming posts.

You’re probably saying, “Well this is all well and good Matt, but there is nothing here I couldn’t glean from Microsoft documentation.”  No worries my friends, we’ll be using this series to walk to demonstrate the capabilities so you can see them in action.  I’ll also be breaking out my favorite tool Fiddler to take a look behind the scenes of how Microsoft manages to elevate access for the user after a privileged role has been activated.