Demystifying Azure PIM: What it is, How it Works, What it Doesn’t Do

Azure PIM is a specific product offering from Microsoft Azure and should not be confused with ‘PIM’ as the broad industry acronym for privileged identity management, given that they are entirely separate other than by name. While it is a simple distinction, this point may cause far more confusion than you might think!

Privileged Identity Management (PIM) is a very broad industry term rather than a reference to any specific tools. Many analysts, most notably Forrester, use the term ‘PIM’ to refer to all things within the ‘PAM’, or Privileged Access Management, space. PIM and PAM are often used interchangeably to refer to the wider universe of tools and technology that relate to the management, governance, auditing, and lifecycles of all types of privileged access and privileged user credentials.

How Azure PIM Fits within Identity Management

With the clarification on terminology aside, any explanation of the Azure PIM tool must first start with a deeper look at Microsoft’s position on identity security. Microsoft has released a whole host of tools, with Azure PIM being one of them, that all relate to their core identity security proposal. In Microsoft’s own words:

“In Azure AD, we replace the network security perimeter with authentication in your organization's identity layer”

The idea of identity as a security perimeter is meant to act in lieu of traditional controls placed on the network. For Microsoft, the question is: if you can be more certain that the user accessing a resource is who they say they are, then do you need other controls in place?

We view this initiative as a natural evolution of Active Directory’s very basic approach to securing user identities (i.e. just a username and a password). Azure AD takes this to the next level with core features such as:

• Enhanced MFA, including Windows Hello for Business and MSFT Authenticator
• Conditional Access: the foundational layer of identity security in Azure AD
• Azure PIM and Azure Identity Governance
• Automated Threat Response and Cloud Intelligence solutions

Of these features, Conditional Access is by far the most pervasive feature in Microsoft’s identity stack. If you or your organization leverages Office 365 or Azure AD today, you have most likely worked with, or been subject to, Conditional Access policies. This feature is where Azure AD administrators can define granular, context-based policies which challenge users for things like additional authentication or MFA, depending on where they are trying to authenticate from, or which resources they are trying to authenticate to.

With Conditional Access, you are able to block connections from ‘risky’ locations (perhaps from a country your business isn’t able to operate in), force users to reauthenticate when their connection changes, allow connections seamlessly from Intune managed devices that are compliant with the latest security policies, or many other conditions that administrators can set.

The key to understand for the purpose of de-mystifying Azure PIM is that Conditional Access is an identity security tool that applies to everyone in your organization. Azure PIM then becomes a much more targeted tool in a broad set of capabilities that make up Microsoft’s push for ‘identity as security’.

How Azure PIM Works

Unlike Conditional Access, Azure PIM only applies to administrative roles within Azure and Azure AD. This is an important consideration, both as it relates to ‘administrative’ functions as well as, more importantly, the idea of Azure and Azure AD ‘roles’. Also, unlike Conditional Access, Azure PIM requires Microsoft’s highest license tiers (E5 or Premium 2) for any users that are subject to the tool.

A distilled-down way to describe Azure PIM is that it’s a clever provisioning and deprovisioning utility wrapped around Azure AD and Azure resources to allow for time-bound, or ‘just-in-time’ access instead of the more traditional concept of ‘standing access’.

A good way to understand Azure PIM is to think of what it is coming from: Active Directory Security Groups. In AD, the approach to manage a Security Group is to simply add a user in when they need the privileges associated with that group. If it is a temporary need, then, hopefully, someone remembers to go in later and remove them. This is a clunky, no-frills, manual process that is fraught with opportunities to make a mistake and leave the user as a permanent member of the group. In addition, the user has all the rights and privileges associated with that group 100% of the time while they are a member, even though they may only need those enhanced privileges for a small amount of time. This is the concept of ‘standing access’ that Azure PIM attempts to mitigate.

Azure PIM takes this model and evolves it; the Azure PIM utility within the Azure portal allows you to assign users or groups within Azure AD to become ‘eligible’ for various roles. Eligibility essentially means the user may not have these privileges all the time, but rather for a short period when they opt-in, or ‘activate’ their roles. This eligibility supports conditional access, and may require things like approval workflows, ticketing system integrations, step-up MFA, etc. to fully opt-in.

A new set of audit records now exist where they did not before in native Active Directory; you can now view who activated roles and when, but not necessarily what they did with those privileges. Email alerts are available here as well to fire off notifications when certain roles are activated and deactivated.

Administrators can select users or groups and define their eligibility criteria, such as which specific role and the time period that it applies to:

(NOTE: Permanent eligibility is enabled by default in this portal)

On the other side, users navigate to the ‘Azure PIM blade’ within the portal and find their eligible assignments to start the activation process. If successful, the portal will force a refresh once the role privileges are successfully applied.

As anyone who works within Active Directory can attest, there is a big improvement that Azure PIM offers as a utility to manage role membership. However, the point around the roles themselves is the point at which many similarities to Active Directory become strained. Azure and Azure AD roles are a completely new entitlements scheme. Many role capabilities exist and are relevant only within the walled garden of Azure and can be considered silos when looking at an organization’s entire IT estate.

Azure PIM can manage a number of these different roles. View an up-to-date list here.

In this scheme, Global Administrator becomes the new ‘Domain Administrator’ as they own anything and everything within your Azure tenant and management group. Other roles like, Billing Administrator, are specific to functions within Azure, while things like Exchange, Intune, and SharePoint administrators are all relevant to those Microsoft products which exist in the Azure ecosystem.

Azure PIM in the Perspective of Privileged Access Management

At the end of the day, Azure PIM is simple a utility within Azure. It is important, however, that we take a step back and look at the bigger picture for those trying to understand where, how, and if Azure PIM should be part of your privileged access management technology stack. I would argue that the biggest driver of this decision should start with an in-depth review of Azure and Azure AD roles. Azure PIM is only as effective as the roles themselves, so keep a keen eye on the boundaries and where they fall short. A guiding principle here is to ask yourself how integrated you are or plan to be into the Azure ecosystem. Most of the customers we work with are quite diversified in this sense.

Of course, make sure you get a full view of the costs for the Azure PIM tool. The E5 or P2 license must apply not just to users that are managed by PIM, but also for anyone that’s part of the review or audit process. Membership into the roles themselves does not require the enhanced licensing, only the time-bound provisioning benefits that Azure PIM specifically brings to the table.

Also, when reviewing the roles, I highly recommend that you evaluate any feature and functionality gaps that may be present in that role or in the Azure PIM tool itself. In our evaluation of Azure PIM, we uncovered the following four potential pitfalls to be aware of in your planning stages:

1. The Device Administrator role

For those who have already, or are planning to, migrate their Windows environment over to Azure AD, you may have come across the topic of Local Administrator Rights (LAR) management. For a long time, including to this day, the answer from Microsoft on workstation and server least privilege was the Local Admin Password Solutions (LAPS). One could assume that, with the advent of Intune and Azure AD, Microsoft would have evolved this approach to a more modern set of capabilities. Unfortunately, you’d largely be wrong in that assumption.

The recommendation on least privilege remains mostly unchanged, as Microsoft still does recommend LAPS be used where possible. LAPS requires on-premises Active Directory infrastructure to function and, thus, may not even be feasible for pure Azure AD and Intune-managed environments.

There is one addition specific to Azure: the Device Administrator role. This role, which is manageable via Azure PIM, is designed to allow member users the privilege of being a local administrator across Azure AD joined devices (this applies to hybrid devices as well). At first glance, this role appears to enhance Microsoft’s approach to managing least privilege, however, upon reviewing the role in further depth, this is unfortunately not the case

Below is an excerpt from the Microsoft documentation on this role:

“Device administrators are assigned to all Azure AD joined devices. You cannot scope device administrators to a specific set of devices. Updating the device administrator role doesn't necessarily have an immediate impact on the affected users. On devices where a user is already signed into, the privilege elevation takes place when both the below actions happen:

Up to 4 hours have passed for Azure AD to issue a new Primary Refresh Token with the appropriate privileges.

User signs out and signs back in, not lock/unlock, to refresh their profile.”

To reiterate: any member of this role has admin access across all of your Azure AD-joined devices. Thus, managing access via Azure PIM becomes an almost crucial function to limit your attack surface. But, if you manage the access via Azure PIM, it might take 4 hours for the change to take effect. This is the ultimate technical catch-22.

2. Planning for human nature

Another important topic to consider when planning for Azure PIM is to recognize that, while it brings more to the table than native Active Directory, human nature still does play a part. When users are made ‘permanently eligible’ for a role, as is the default, there is an argument to be made that Azure PIM isn’t actually providing any real value above and beyond more basic, less costly tools available in Azure. For instance, if you take a user out of a group, or a role, but give them free reign to add themselves back in at any point, are you doing anything measurably differently?

At BeyondTrust, we emphasize the point that just-in-time access is not just a feature of our PAM solutions that you can enable, it’s also a concept that requires technical capabilities combined with the adoption of workflows.

Human nature does often dictate that the ‘noisiest’ users (those requesting privileged access most frequently) are often the first to be given permanent access so they stop bothering their administrators. Care should be taken to address this sort of gap in any planning phase and ensure that shortcuts do not erode the effectiveness of your PAM strategy, or they are at least remediated.

3. Privileged Access Workstations

One additional component worth noting is Microsoft’s concept of a Privileged Access Workstation (PAW). While this piece is not strictly related to Azure PIM, it plays a major part of Microsoft’s larger proposal around securing privileged access, of which Azure PIM is also a part. It is important to bear this in mind in your planning phase to get a full appreciation of the tangential costs associated with aligning yourselves fully to Microsoft’s vision.

The Privileged Access Workstation is the concept of administrators having entirely separate workstations that they use for all administrative activity. The idea is based on ‘browse down’, which means ensuring that lower-order behavior, such as checking emails or browsing the internet, is not performed on the same machine used to administer the environment, such as through the Azure portal.

To fully adopt this model, the PAW becomes an additional cost above and beyond Azure PIM, as Microsoft themselves recommend that Azure PIM is not a replacement for a PAW.

Source: https://docs.microsoft.com/en-...

4. What exists outside of Azure in your environment?

This is the broader question that I believe is worth asking in a planning phase when considering Azure PIM: what in your environment will exist outside of the Microsoft ecosystem, both now and in the future?

Consider that an environment where multiple solutions exist to solve the same problem can often add complexity that a consolidated solution would inherently avoid. In the case of Azure PIM, the guiding principle to understand, if multiple tools might be required, will it be based on what is or is not part of Azure. Think about your own environment:

• What does your workstation environment look like? Are they all Azure AD-joined? What about macOS or Linux devices?
• On the server side, are these devices in Azure? What about *nix servers? How is root access or management of SSH keys handled for these systems? How is secure RDP and SSH access handled?
• Think of data warehousing – which database platforms do you use? How is privileged access managed for these systems?
• SaaS or 3^rd-party applications? Can these be integrated into Azure? How are the most privileged credentials for those platforms managed and who has that access?
• Network switches? Hypervisors? Firewalls? Load Balancers? VPN infrastructure?
• What about 3^rd-parties that need remote access into any of these systems? How do you secure that access?
• Is identity the end-all-be-all of security for you? Or just one part of a wider PAM strategy?
• Make sure you do not forget other cloud providers as well. If you diversify across Azure, AWS, GCP, Oracle, etc., how do you plan to unify processes and technology across these platforms?

Extending PIM/PAM Best Practices across your entire Environment

Azure PIM is just one piece of Microsoft’s identity focus. It is crucial to understand the natural boundary of Azure PIM is Azure itself.

When answering the question of how effective Azure PIM might be for you, I’d ask you to balance what you know about your environment and where gaps might exist, as those gaps would have to be filled by another point solution. It is fairly easy to see where Azure PIM provides value as a natural evolution of AD security groups, but it’s important to be mindful of mapping Azure PIM’s real capabilities against what a comprehensive PAM strategy needs to look like.

BeyondTrust secures your entire universe of privileges through our unified PAM platform. Our portfolio of Privileged Access Management solutions enables our customers with Privileged Password and Session Management, Endpoint Privilege Management, and Secure Remote Access across their endpoint and cloud estate to fully realize a holistic PAM platform. This platform functions across all areas of your business and is not limited to a single provider, while still integrating with external identity security solutions, including Azure AD to get the best of both worlds.

Download our guide to learn more about BeyondTrust versus Azure PIM and about BeyondTrust’s holistic privilege management approach: