A new, must-have Conditional Access policy

It has been a while since I have been really excited over a new feature/capability that Microsoft has released. Yesterday was one of these times, when Microsoft announced new supported scenarios for re-authentication. This opens up some new use cases, that should (in my opinion) be covered in every organization. In this blog, I want to dive into some of the current dangers/threats and how these policies can help.

Threats to the cloud

With more and more organizations moving into the cloud and Microsoft adopting security defaults such as multifactor authentication, attacks are becoming more sophisticated. For me, the biggest attack vector in a modern world is token theft.

Previously, attackers would execute a password spray attack to gain attack to a system, but nowadays, everything is protected with multifactor authentication, protected against MFA spam. To work around this, attackers steal the sign-ins tokens that provide access to Entra ID, without needing a password or multifactor authentication method.

This attack vector is also shared in great detail in this awesome blog by my colleague Robbe. If you have a browser with your admin account, an attacker can steal that token and replay it to gain access to your account. If PIM activation is required, the actor can still activate a role (because the MFA claim is included in the token). This attack vector can be mitigated by the new capabilities announced by Microsoft.

What is released?

In Conditional Access, we have the option to configure session controls and more specifically sign-in frequency. This allows us to configure how long a user stays signed-in, thus showing when they should re-authenticate with their username, password and multifactor authentication.

You should not require an end-user to reauthenticate every hour as this greatly impacts the productivity. Instead, you should require reauthentication in specific scenarios. This is covered by the ‘Sign-in Frequency Every Time‘ capability. Before this announcement, you could already require reauthentication when a user has a risky sign-in. This is a policy which I have implemented multiple times and recommend to everyone. This combats token theft as re-authentication will be required if a user has a sign-in risk, meaning if they sign-in from a new device or location. The user impact is minimal, as this only happens if the user travels or activates a VPN.

With this new capability, additional scenarios are covered for the ‘sign-in frequency every time’ feature. It can now be used to require re-authentication for applications and authentication contexts. The latter is the most interesting because of it’s integration with PIM.

Hardening PIM activations

In the Robbe’s blog, he talked about the attack vector where a threat actor breaches the device of an IT admin and steals the sign-in token. With this token, the attacker can activate any role. Even if this role is set to require MFA, the attacker will waltz through it because the MFA claim is included in the token.

With this new feature, we can require re-authentication if a role is activated. To do this, we can use a combination of authentication contexts and Conditional Access.

To get started, navigate to Entra ID > Security > Conditional Access > Authentication Context and create a new authentication context. The name and description can be set to your liking.

An authentication context doesn’t do anything by itself, this needs to be integrated into something. This can be either integrated in a custom application or it can be integrated within PIM. By integrating it in PIM, this authentication context will trigger when a role is activated.

To configure this, navigate to PIM and configure settings of the desired role. In my case, I navigated to an Entra ID role and add my authentication context to the Global Administrator role.

Now we have linked our authentication context to a specific action, but we need to configure what kind of effect the authentication context will require. This is done by creating a new Conditional Access policy and selecting the auth context as a target resource.

In our case, we only want to configure sign-in frequency and select ‘every time’.

With this configuration, an IT administrator will require to re-authenticate if they want to activate a specific role. Even if they had previously signed in with MFA, they will be required to log in again. This measure combats token theft, ensuring an attacker cannot use a token to elevate their privileges.

This configuration should be scoped to highly privileged roles (Global Administrator, Privileged Role Administrator and Privileged Authentication Administrator). This has two different reasons:

• We don’t want to bully administrator for every actions and we should limit the impact we cause.
• These roles should not be used often, meaning the chances of the token being stolen while the role is active, is smaller.

Not an air-tight solution

Off course this control doesn’t cover every scenario. If a token is stolen from a user who had already activated the role, this control won’t have any effect. However, that specific scenario should be covered by other Conditional Access policies such as disabling persistent browser and limiting the activation time for a highly privileged role.

Scoping to an application

Another use cases which is covered by this update, is enforcing strict authentication for specific applications. You can now require re-authentication for specific applications by selecting certain Cloud Apps within Entra ID Conditional Access. This is great for critical applications, VPN software or Privileged Access Workstations.

The same note applies as before; we should not hinder the users. These policies should be scoped to highly critical actions/applications that don’t have all that often.

Let’s hit the ground running

These kinds of Conditional Access policies have a limited impact, but can greatly decrease the attack surface. Having this capability enables us to put additional protection against token theft.

While deploying it, it’s important to keep it user friendly and not require re-authentication for everything.