Introduction
When administrators use directory roles (aka Entra ID roles) when configuring Conditional Access Policies (CAPs), users are not included in the enforcement of that CAP until after that user’s role assignment is activated. If administrators use Privileged Identity Management (PIM) for role assignments, this adds complexity because role eligibility is not considered for roles in CAPs. This has implications for offensive testing, defensive coverage, and even disaster recovery.
What areCAPs?
To put it very simply, CAPs are if-then statements for determining access. There are several conditions which can be set for evaluation and Microsoft is adding more regularly. Conditions for access to resources are set in the CAPs and authentication attempts are evaluated against the policies at the time of authentication. This evaluation occurs for all authentication attempts and principals to see if they match the conditions for a policy. The parameters evaluated can include details such as the device used, the location or IP address, the authentication context, and several other factors which can be configured.
CAPs can be used to provide an additional layer of protection for resources in Entra and Azure Resource Manager (Azure RM) on top of other access control. They allow administrators to more granularly specify how a principal is allowed to access resources. This is a quick explanation of CAPs and if you are unfamiliar with the concepts, it would be best to review the linked information.
Specifically, for this blog, we will focus on the conditions in a policy which apply to directory roles. Entra allows built-in roles to be specified in a policy by including directory roles in the policy for under “Users” as shown below. Directory roles can be included or excluded in a policy, and it is common to find roles used for both. Below, we can see what a directory role included in a CAP lookslike.
What isPIM?
PIM is Microsoft’s solution for providing just-in-time (JIT) access to roles or groups. PIM can currently be used with Entra roles, certain types of groups for membership, and Azure RM if configured. For this blog, our focus is specifically on PIM for Entra roles. In this context, PIM is used to assign eligibility to principals for roles in Entra. These can be the built-in roles or custom roles in the tenant. In the image below, we can see the list of roles and the users who are eligible for those roles under the “Eligible assignments” in the PIMblade.
When a user is eligible for a role, that eligibility allows for users to activate their roles when needed, and the roles remain inactive when unneeded the privileges. When a user activates a role, they are reauthenticated automatically with the context of the role they activate.
Role policies can be configured with additional requirements to use or assign the role. This is important to note because additional requirements or notifications can be added to a role which can have a further impact on how the roles must be activated. A user must be eligible for a role in order to activate it for use with PIM. After activation, the user will have the same privileges as a user with a permanently active role assignment for the duration of the activation.
What is theProblem?
The issue with using PIM and CAPs together is that CAPs look at the current state of the account when it is authenticating. PIM eligibility for a role is not the same as having the role active for the account when it comes to evaluation in CAPs. Currently, CAPs do not consider role eligibility as a factor in authentication.
If a user is eligible for a role but the role is not activated, then the CAPs are not applied to the user. After the role is activated, the user will reauthenticate so the active Entra ID role is reflected in their tokens for use. Activation is the point at which CAPs which apply to the role will be evaluated for conditional access.
To demonstrate this, let us look at a simple example. In this scenario, we have the following three elements configured:
- PIMUser1 — Test user account with role eligibility
- Organizational Messages Approver — Built-in role in the tenant with PIMUser1 assigned eligibility
- PIMCAPTest — Conditional access policy which requires users with the PIMTestRole assignment to authenticate from aVPN
CAPs are only applicable to built-in roles; there is no significance to the role choicehere
To start, we can authenticate with the PIMUser1 user account because the role is not activated and so the CAP is not applied to the user’s logonattempt.
Next, if we open the PIM blade and activate the role, the user will automatically attempt to authenticate again with the new role applied. However, this time the user will be blocked because they now meet the conditions specified in theCAP.
CAPs will reevaluate access as soon as the role is activated because a new token must be issued when the role is activated. When that happens a new authentication request is sent by Entra automatically and CAPs will match for our PIMUser1 because the role is now activated for theuser.
What is theImpact?
Since CAPs evaluate the current state of the account and there is a reevaluation when the role activates, this can cause some issues if not considered when configuring CAPs and PIM in a tenant. To get a better understanding of this impact, we can look at some common scenarios in which CAPs and PIM areused.
Scenario 1: Loss of Access During DisasterRecovery
One example of a potential issue is when a role is excluded from CAPs. Certain roles are often excluded from CAPs, such as Global Administrator, so those users can gain access into the environment in case of a lockout. It is recommended that break-glass accounts be created and CAPs exclude these accounts from policies to allow for access. To simplify this, some tenants I have encountered will simply exclude their Global Administrators by role instead of having dedicated break-glass accounts. Additionally, Microsoft recommends using PIM for roles and it is not uncommon for a tenant to use PIM instead of having permanent assignments for highly privileged roles.
In this scenario, if the tenant is using PIM for all Global Administrator roles and at the time of lockout, the role is not activated for any users, the administrators are in for a long day trying to regain access. The role eligible Global Administrator users will not be allowed to authenticate because they do not meet the requirements for access without the active role. This is part of the reason why dedicated break glass accounts with permanent Global Administrator role assignments are recommended. You should not find yourself in this situation if you are setting these up correctly, but I have seen this type of setup in environments before unfortunately.
Scenario 2: Unforeseen Gaps inCoverage
In cases where roles are included in CAPs as a condition, a similar issue can arise. Roles included in a CAPs will only be applied when a role is activated so those users who are role eligible are not covered in the CAP until the role is activated. For example, let us say an administrator is attempting to secure the environment and instantiates a CAP which covers the directory roles in use. The administrator also uses PIM for all role assignments so people will have JIT access to those roles instead of them being permanently active. The image below shows an example of how this policy wouldlook.
Independently, these decisions seem to adhere to best practices. However, without additional configuration for the users who are role eligible, the CAP does not cover them until the time of activation. What an administrator would need to do is make sure those accounts are covered by another CAP to ensure that MFA is alwaysused.
Scenario 3: Role Activation During an Offensive Engagement
For offensive engagements, this can become relevant when looking for avenues for escalation. If you find a user who can get around CAPs and is role eligible, CAPs could cause you to lose access when the role is activated.
As we saw in the previous examples, role activation can cause additional conditions to be evaluated which may match settings in a CAP and change the access decision. If you are conducting an offensive engagement, policies which apply to a role should be evaluated prior to activation of the role to ensure activation will not cause accessloss.
NOTE: Although not discussed here in depth, it is a good idea to look at role policies as well. In addition to CAPs, role policy settings for the specific role should be reviewed prior to activation. By default, there are no additional requirements published to a role, but these can be added for roles individually. These can require multi-factor authentication (MFA), approval, or send notifications toothers.
What is the Solution?
The solution is not to avoid using CAPs and PIM together. These features do provide protection when implemented properly, but it is important to understand how they work and the purpose they serve. CAPs are an additional layer of protection which deal with authentication. PIM is for JIT access to privileged roles. To use an analogy, we can compare these to a gate guard and a camera respectively. CAPs are the equivalent of a guard sitting at a gate with a list of conditions to determine if someone is allowed on the campus but does not check which building they go to after they get to the gate. Each building should have a list of who is allowed to enter or not, but the gate guard does not see those lists. PIM is similar to installing a camera outside of the door to a secure area. Functionally for access, the camera records what happened but does nothing to prevent someone from entering the door. It may deter some people, but the camera is in no way a barrier for entry when someone can simply open the door. Similarly, PIM without additional configuration will provide you a record of what happened during the intrusion, but the actual activation of a role is as simple as clicking abutton.
This does not mean there is nothing for us to do. Sticking with the analogy, we can provide a more robust list of rules to our gate guard to ensure more coverage for access scenarios. For CAPs, this would look like creating additional policies to account for changes in roles and ensuring coverage of authentication scenarios. For our camera, additional actions such as alerting on motion or requiring biometric information to prove identity can be included. For PIM, this would be setting notifications for role activation and requiring MFA for role activation.
Since there are many settings for both CAPs and PIM this blogpost did not cover, I will suggest a couple of resources to help in securing a tenant with PIM and CAPs. First is this blog which takes a critical look at PIM and how it is commonly implemented and provides recommendations for securing it further. Second is this resource, which discusses how PIM and CAPs can be used together, though it does focus on PIM for groups. Lastly, this blog provides attacker insight into how attackers can circumvent PIM restrictions.
Conclusion
The main take away from the blog should be that role eligibility with PIM is not taken into account for CAP evaluation. It is not until a role is activated which is specified in a CAP that the policy is applied to an authentication attempt. This is both when a role is included and excluded from a policy. Additional configuration can help reduce the oversights thiscreates.
One last note, Microsoft makes changes to these features, so it is best to not treat PIM and CAPs as “set it and forget it” security features. These should be reevaluated regularly to ensure new configuration settings do not create new gaps or problems foraccess.
How Privileged Identity Management Affects Conditional Access Policies was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from Posts By SpecterOps Team Members - Medium authored by Hope Walker. Read the original post at: https://posts.specterops.io/how-privileged-identity-management-affects-conditional-access-policies-03371d06cfe3?source=rss----f05f8696e3cc---4
