Continuous access evaluation is a strong default protection method enabled in Conditional Access by default. It ensures that continuous two-way communication is maintained between the client device and Microsoft Entra to ensure that if the client parameters fall out of the scope of the conditional access requirements, access to that resource is blocked almost immediately, without having to wait for token expiry.
However, it is not a perfect solution. Microsoft has to be lenient with enforcing defaults to accommodate complex scenarios where over-zealous policies may hinder productivity. But of course this also opens up additional risk.
In this tutorial, I am going to show you how to combat this additional risk and enforce the strictly enforce location policy settings in Conditional Access.
Basic location restrictions in Conditional Access and the risks
Located-based access in Conditional Access enables you to block access based on the IP address or geographical location of the user. The issue is that by default, there is a chance that continuous two-way communication between the client and service (Microsoft Entra) to allow policies to be evaluated in real-time is evaded.
Although location-based restrictions provide a strong foundation for securing access to resources, there are still some risks if you do not or can not implement additional protection.
Firstly, in the event of a system compromise, the access token could be exported and used on another network during its validity period. If the impacted user is also a highly privileged role member, the attacker could simply disable or create hidden allowances in the existing Conditional Access policies to further extend their malicious access to your environment.
Secondly, a less-expected attack could come in the form of a malicious VPN connection. Unsuspectingly a user could connect to an existing VPN connection that they use daily, but without knowing, the VPN-providing device (such as a firewall) could have been breached and configured to provide perform a DNS spoofing or DNS poisoning attack. They could then trick the user into exposing their access token from malicious (but seemingly legit) login pages.
To demonstrate this issue I have created a simple Conditional Access policy to include all locations, exclude my trusted locations and block access:
If I attempt to sign-in outside of my trusted network, conditional access will block my sign-in as expected:
Then if I attempt to sign in while inside of my trusted network, my access will be allowed. For this test, I used a public VPN provider which was added as one of my trusted networks. The below image of the Conditional Access sign-in log for this test demonstrates that this sign-in was excluded from the block policy based on the location exclusion.
Now for the issue. While I am connected to my trusted VPN and signed in to Exchange Online (for example) through my Outlook desktop client, I can then disconnect my VPN client and maintain access to my browsing session outside of my trusted network for a short period. Also, depending on my network topology, changes in routing may cause continuous access evaluation to revert to the legacy evaluation method of token expiry and renewal to trigger policy evaluation, which would extend my unevaluated access to Exchange Online.
When doesn't Continuous Access Evaluation apply?
As mentioned, Continuous Access Evaluation for IP address locations doesn’t always apply in some complex network environments, depending on how network traffic is being routed.
For scenarios where the resource provider (such as Exchange Online) cannot enumerate the user’s IP address, but Microsoft Entra can, Continuous Access Evaluation will not apply to the IP location, but instead only to risky events post-authentication. Examples of network topologies that may trigger this include:
- Split tunnel VPN
- Load balanced/redundant networks that impact Source NAT (SNAT)
- SD-WAN based deployments
- Branch offices where traffic is routed between other offices and the internet
Fundamentally, if traffic is handled differently between the identity provider (Microsoft Entra) and the resource (Exchange Online for example), then this will render CAE IP location controls ineffective.
How Strictly enforce location policies works
As mentioned above, Continuous Access Evaluation is enabled by default, even though it is not configured in your Conditional Access policies. The problem is that by default, it is lenient.
Without configuring ‘Strictly enforce location policies’ and in the event of complex network topologies, this is detected by Microsoft Entra and the network location evaluation method can/will fall back to pre-CAE detection methods, as mentioned above. This would pro-long unauthenticated access to the protected resource and occurs to prevent hindrance to productivity.
The solution is to strictly enforce location policies through Conditional Access session controls. This provides an ‘opt-in’ experience that allows you to bypass the failsafe mechanism built into Conditional Access evaluation.
By strictly enforcing location policies, a user will only be granted access to the resource in the event the following is true:
- The users IP address can be enumerated by both the identity provider and resource provided (Entra and Exchange Online for example)
- The enumerated IP is the same for the identity provider and resource provider
If either of the above conditions are not met, then access to the service will be denied. This will be visible through the Conditional Access sign-in logs:
How to enable Strictly enforce location policies in Conditional Access
The Strictly enforce location policies setting is easy to configure, but it is important you understand your own routing topologies before you enable your Conditional Access policy.
Start by following the below steps to create a Conditional Access policy, enable these settings and configure reporting mode.
2. Expand Protection, then select Conditional Access > Policies > New policy
3. In your new policy, configure the standard settings such as the Name, User assignments and Resource assignment, then on the Condition assignments configure your location conditions.
4. Under Access controls, expand the session control and check the box next to Customize continuous access evaluation and select Strictly enforce location policies.
Is this supported by the Graph API?
Sure is:
PATCH: https://graph.microsoft.com/beta/policies/conditionalAccessPolicies/%PolicyID%
Body:
{
“sessionControls”: {
“disableResilienceDefaults”: null,
“applicationEnforcedRestrictions”: null,
“cloudAppSecurity”: null,
“signInFrequency”: null,
“persistentBrowser”: null,
“secureSignInSession”: null,
“continuousAccessEvaluation”: {
“mode”: “strictLocation”
}
}
}