Entra ID’s P2 license (previously Azure AD Premium P2) unlocks the Privileged Identity Management (PIM). PIM is part of broader identity governance features, and is most known for enabling just-in-time admin rights. For example, you are eligible to become an administrator for a maximum of X hours, at which point the permissions expire and you need to reactivate.

This blog covers five of the common misconfigurations and misunderstandings I see with customers. Intuitive as PIM may appear, there are some gotchas you need to be aware of. It is a follow up from my previous Conditional Access – Common Microsoft 365 Security Mistakes Series article.

Table of Contents

‘Require Azure MFA’ probably isn’t giving you the security you think it is

When configuring PIM for a role, in addition to specifying how long activation lasts, you can require Azure MFA.

The assumption that most folks have here – rightly so – is the activating user will be prompted to respond to MFA on each activation, but this isn’t the case.  When PIM requires Azure MFA, it will not prompt the user if this has previously been satisfied.  This is consistent with most of Entra ID (including Conditional Access), but not widely understood with most customers.

Let’s explain with an example.

1. The eligible user signs in to the Entra admin center. A Conditional Access policy requires Azure MFA for this account, so the eligible user responds to the prompt on their phone at time of sign-in.

2. The eligible user heads to My roles and clicks Activate for the role.

3. The eligible user activates their role, but is not prompted for MFA, despite the setting On activation, require Azure MFA being enabled for the role.

Other than (usually) not being the expected behavior (but by design), this can be a security risk depending if you don’t have some of the mitigations explained later in this article.

What’s the security risk, specifically?  Token theft, primarily.  A type of attack that’s on the rise, based on data in the Microsoft Digital Defense Report (2023).

Malware or adversary-in-the-middle (AiTM) attacks can compromise (steal) your tokens, including the fact MFA has been satisfied.

To simplify the explanation, think back to step 1 earlier.  Entra ID provided the eligible user a token that includes a claim that MFA was satisfied. Think of it like a pass being issued with a check mark against the “provided MFA” field.  If the token is stolen, so is the MFA check.  For the duration of that token’s validity, the thief gets the MFA claim too.

So, should you not bother with requiring MFA on PIM activation?  Absolutely not.  If the session has expired, this will prompt for MFA.  That’s important because the stolen token may not be used by the adversary immediately, and if used after its lifetime, will require MFA.  This is a good case for using Conditional Access to enforce things like the following for your eligible users, particularly for privileged roles:

  • Set the sign-in frequency (SIF) to as low a value as tolerable (reference).
  • Do not allow persistent sessions (reference).
  • Ideally, use an IP-based location requirement (block any other IPs) with strict location enforcement. Unlike geo-based requirements, IP requirements are supported by continuous access evaluation for near real-time revocation when it changes (reference).

The next logical question follows: can we force require MFA, despite existing MFA claim validity?  Just about, using authentication contexts, which is covered next.

Further reading: see these excellent blogs by Fabian Bader, Jan Bakker, and Jeffrey Appel for deep dives into token theft, specifically using AiTM tools.

Not using authentication context

In the last mistake, you learned that requiring Azure MFA on activation is an important control but with some shortcomings. Here’s a way we can improve on it.

Authentication context in Entra ID is a flexible capability for enforcing another Conditional Access policy. Normally, Conditional Access policies only apply at the time of authentication to a cloud app. Think of authentication context as a way to apply another Conditional Access requirement within the cloud app.

The authentication context itself is just a tiny object you create in Entra admin center | Conditional Access | Authentication contexts. It only has a name and description.

You then follow this up by creating a Conditional Access policy that’s required whenever the authentication context is invoked by the app (in our case, PIM).

Continue to build the CA policy based on the security you want for the PIM activation.  For example…

  • if you only want someone to become a Global Admin from a known corporate IP, you could set up a block rule that includes all locations except that IP.
  • if you want to require a third-party MFA solution (e.g. Symantec VIP, Duo, etc), use authentication strength requirements
  • if you want to enforce use of a privileged access workstation, use filter for devices

In my example for this blog, I’m just going to require a FIDO2 security key, which isn’t an explicit option in out-the-box PIM settings (only Azure MFA is).

Better yet… keep in mind what you’re protecting against (each org. will have different threat tolerances, etc).  An IP based restriction is potentially the best for token theft mitigation.  However, using a FIDO2 requirement, if the stolen token only satisfied Azure MFA, this would require “step-up”.

But… using only a FIDO2 example, what if the attacker simply registers their security key against the compromised account?  Each time you register a security key, you need to perform 2FA again, even if a CA policy previously required it*.  Let’s assume that fails: there’s a good argument for requiring specific AAGUIDs either for registration or the authentication strength.  Conditional Access could also enforce additional requirements for the Register security information action.

*There is a 15 minute exception to this: registering a new sign-in method only force-prompts for MFA again after at least 15 minutes from original MFA claim. Gee, isn’t there a lot to think about in this Entra ID security puzzle 😵‍💫

Now we’ve got a Conditional Access policy in place for when the authentication context is invoked, we can head back to Edit role settings in PIM.

When setting up PIM roles, instead of On activation, require Azure MFA, you can choose On activation, require Microsoft Entra Conditional Access authentication context (try saying that quickly 5 times).

Now, if an administrator (or compromised token) only previously satisfied Azure MFA, it will force them to also require a security key (or any of the other examples discussed earlier).

Is there more we can still do? Nothing’s perfect, but let’s consider one more mitigation against undesirable or malicious PIM elevations, and a common mistake associated with it.

Not appropriately requiring approval to activate

When helping customers with PIM, I often see the Require approval to activate option…

  • Overused.  Need to create a Microsoft 365 Group?  Need approval.  Need to view billing statements?  Need approval.  Need to release an email from quarantine?  Need approval.
  • Underused.  Goes hand-in-hand with general overpermissioning admins (Is that word? I feel like that should be a word).  Want to PIM-up and get God mode via Global Administrator?  Go for it, level-one-service-desk-person-who-just-needed-user-admin.
  • Misunderstood.  Why is this capability preferable, in some regards, to both requiring Azure MFA or authentication context?  Or at least complement those?

Look, if you want the overhead and general annoyance with requiring an approval flow to do everything, go for it. But, there is approval-fatigue in the same way there is MFA fatigue.  Are you really checking the person who just Teams’d you to ask for approval is a legitimate user?  You ideally want a balance, which for me is based on how privileged the role is.

This takes me to the misunderstanding of the real benefit to requiring approval.  It’s great for internal legitimate administrative control to either enforce or audit least privilege (and potentially block changes outside of windows, etc).  What it’s really great for, however, is a security boundary that protects compromised accounts.

Think about it. Previously, you learned that requiring MFA isn’t token theft proof. Depending on your authentication context and its strength, that might not help either. But requiring approval with a real and enforced approval process is token theft proof.  Let’s run it through:

1. An eligible admin account is compromised. Either only requiring single-factor authentication or with a stolen MFA claim.

2. The compromised eligible admin has no standing permissions. Really all they can do is head to the PIM page and request permissions (they likely can perform read-only reconnaissance too, depending on other Entra ID config).

3. The compromised eligible admin fails your validation process for requests, and you identify the breach.  Not a great situation but could have been a lot worse.

This illustrates both the value of not inducing approval fatigue by requiring it constantly, and requiring it for highly privileged roles.  There’s one really important thing you need to avoid though, coming up next.

No mitigation against role lockouts

If you’re in the Entra ID world and doing good stuff like Conditional Access, you’ll probably be aware of the emergency access or “break glass” account concept.  There’s several ways to address emergency access accounts, but the most common is:

  • One or more (ideally) accounts added to an ’emergency access’ group
  • This group is excluded from all Conditional Access policies
  • The users or group is assigned Global Admin rights (or other permissions that would help resolve the lockout).

The point of this PIM mistake is you need to implement this to protect PIM roles too.  If you’re already doing the above, you’re fine for this mistake.  If you’re not, consider the following scenario:

1. You require approval for all admin activation. The activation must be approved by other eligible admins; a common scenario I’ve seen based on two-keyed lock ideas.

2. You are trying to follow recommend practice by having only a few global admins. Let’s say you’ve got three.  One is active (not you) and the other two are eligible. This scenario would be worse with only two.

3. Of your three global admins, one is on holiday (unreachable), and the other is sick (unreachable). In a worse (but true) example, two of the eligible admins  immediately exit the business. All that’s left is you (eligible only).

4. You try to PIM-up. Because you required approval from administrators who are no longer with the business, you can’t activate the role.

5. Worse still, when you reach out to those unavailable admins, they can’t log in because they deleted MFA from their phone or otherwise CA prevents them.

Point is: always have a highly-monitored but available break-glass admin account with active, not eligible-with-approval, assignments, to avoid scenarios like this. You won’t find a perfect solution, but you can find ones that are less bad!

This oversight brings us to the last mistake (for this blog, anyway!) often seen.

Not protecting non-Entra or non-Azure resources with PIM for Groups

When setting up PIM, out the box you can enable and configure it for Microsoft Entra roles (e.g. global admin, security admin, Exchange admin) or Azure resources (e.g. resource groups).

This leaves a gap for areas that don’t fall under their scope, most commonly other Microsoft 365 RBAC roles:

  • Microsoft Defender XDR RBAC roles (previously known as Microsoft 365 Defender), including Defender for Identity and Defender for Endpoint
  • Exchange Online role based permissions, such as Recipient Management or View-Only Organization Management
  • Microsoft Purview roles, such as  eDiscovery Manager or the Azure Information Protection super user
  • Non-Microsoft privileges, such as admin roles in things like ERP, CRM, HR, finance, or other business apps.

For the above examples, it’s common to see the gap not addressed, with permanent standing access instead of PIM benefits like just-in-time, authentication context, or approval processes.

What can address all of the above is PIM for Groups, previously known as privileged access groups (PAGs).  W

With PIM groups, you can layer PIM ontop of anything that supports Microsoft 365 or security groups.  For either ownership or membership of the group, you can make sure there’s no standing access. Instead, you activate PIM to get those, with all the same benefits like just-in-time.

Let’s illustrate the use case with an example: your ERP system uses Entra SSO, and you want to manage the ERP system’s admins with PIM.

1. You create a security group with no members, and assign this group the admin role in your app.

2. You add assignments to the group, which keeps the admins from having standing membership to the group, but they can jump in and out of membership by activating PIM

3. The eligible admin can head to My roles | Groups and click Activate to become a just-in-time member of the group, similar to other admin roles.

4. Because the group has admin rights in your app, the user inherits those, but they’re governed in line with the group’s activation criteria.

In the screenshots above, you can see how the user activates to become an ERP system admin, despite PIM, Entra, or Azure having no concept of that system’s administrative function. All you need is group support.

This fact that PIM for Groups allows PIM-management for anything that supports groups means you can get creative.  In the last screenshot, you’ll see the example of temporary exclusions to Conditional Access policies.

To summarize this last mistake, PIM for Groups allows you to minimize access and gaps across your environment, not just what may appear obvious at first glance.

Conclusion

Let’s make it clear: PIM is an essential tool in securing Entra, and even other services, as established with our last point. That said, there is no perfect tool and we need to consider additional security defenses in combination with out-the-box PIM, such as Conditional Access, authentication contexts, IP-based restrictions, real-human verification.

If you’ve just got your hands on Entra ID P2, PIM is likely one of the first new toys you’ll play with, but mistakes can be made, and hopefully this blog will help you avoid some of them.

—————————————————–

This is the second in a series of blogs on Microsoft 365 security mistakes I commonly see in the field.  In the first entry, we covered Conditional Access.  Coming up will be similar posts for Microsoft Defender for Endpoint/Cloud Apps/Office 365/Identity, Exchange Online Protection, and more. If there’s a specific product or service you want me to cover, hit me up on LinkedIn or Twitter/X.

Tags:
Last updated on November 19, 2023