|
| 1 | +--- |
| 2 | +title: Continuous access evaluation strict location enforcement in Azure AD |
| 3 | +description: Responding to changes in user state faster with continuous access evaluation strict location enforcement in Azure AD |
| 4 | + |
| 5 | +services: active-directory |
| 6 | +ms.service: active-directory |
| 7 | +ms.subservice: conditional-access |
| 8 | +ms.topic: conceptual |
| 9 | +ms.date: 07/10/2023 |
| 10 | + |
| 11 | +ms.author: joflore |
| 12 | +author: MicrosoftGuyJFlo |
| 13 | +manager: amycolannino |
| 14 | +ms.reviewer: eolasunkanmi |
| 15 | + |
| 16 | +ms.collection: M365-identity-device-management |
| 17 | +--- |
| 18 | +# Strictly enforce location policies using continuous access evaluation (preview) |
| 19 | + |
| 20 | +Strictly enforce location policies is a new enforcement mode for continuous access evaluation (CAE), used in Conditional Access policies. This new mode provides protection for resources, immediately stopping access if the IP address detected by the resource provider isn't allowed by Conditional Access policy. This option is the highest security modality of CAE location enforcement, and requires that administrators understand the routing of authentication and access requests in their network environment. See our [Introduction to continuous access evaluation](concept-continuous-access-evaluation.md) for a review of how CAE-capable clients and resource providers, like the Outlook email client and Exchange Online evaluate location changes. |
| 21 | + |
| 22 | +| Location enforcement mode | Recommended network topology | If the IP address detected by the Resource isn't in the allowed list | Benefits | Configuration | |
| 23 | +| --- | --- | --- | --- | --- | |
| 24 | +| Standard (Default) | Suitable for all topologies | A short-lived token is issued only if Azure AD detects an allowed IP address. Otherwise, access is blocked | Falls back to the pre-CAE location detection mode in split tunnel network deployments where CAE enforcement would affect productivity. CAE still enforces other events and policies. | None (Default Setting) | |
| 25 | +| Strictly enforced location policies | Egress IP addresses are dedicated and enumerable for both Azure AD and all resource provider traffic | Access blocked | Most secure, but requires well understood network paths | 1. Test IP address assumptions with a small population <br><br> 2. Enable “Strictly enforce” under Session controls | |
| 26 | + |
| 27 | +> [!NOTE] |
| 28 | +> The **IP address (seen by resource)** is blank when that IP matches the IP address. |
| 29 | +
|
| 30 | +## Configure strictly enforced location policies |
| 31 | + |
| 32 | +### Step 1 - Configure a Conditional Access location based policy for your target users |
| 33 | + |
| 34 | +Before administrators create a Conditional Access policy requiring strict location enforcement, they must be comfortable using policies like the one described in [Conditional Access location based policies](howto-conditional-access-policy-location.md). Policies like this one should be tested with a subset of users before proceeding to the next step. Administrators can avoid discrepancies between the allowed and actual IP addresses seen by Azure AD during authentication, by testing before enabling strict enforcement. |
| 35 | + |
| 36 | +### Step 2 - Test policy on a small subset of users |
| 37 | + |
| 38 | + |
| 39 | + |
| 40 | +After enabling policies requiring strict location enforcement on a subset of test users, validate your testing experience using the filter **IP address (seen by resource)** in the Azure AD Sign-in logs. This validation allows administrators to find scenarios where strict location enforcement may block users with an unallowed IP seen by the CAE-enabled resource provider. |
| 41 | + |
| 42 | + - Admins must ensure all authentication traffic towards Azure AD and access traffic to resource providers are from dedicated egress IPs that are known. |
| 43 | + - Like Exchange Online, Teams, SharePoint Online, and Microsoft Graph |
| 44 | + - Before administrators turn on Conditional Access policies requiring strict location enforcement, they should ensure that all IP addresses from which your users can access Azure AD and resource providers are included in their [IP-based named locations](location-condition.md#ipv4-and-ipv6-address-ranges). |
| 45 | + |
| 46 | +If administrators don't perform this validation, their users may be negatively impacted. If traffic to Azure AD or a CAE supported resource is through a shared or undefinable egress IP, don't enable strict location enforcement in your Conditional Access policies. |
| 47 | + |
| 48 | +### Step 3 - Identify IP addresses that should be added to your named locations |
| 49 | + |
| 50 | +If the filter search of **IP address (seen by resource)** in the Azure AD Sign-in logs isn't empty, you might have a split-tunnel network configuration. To ensure your users aren't accidentally locked out by policies requiring strict location enforcement, administrators should: |
| 51 | + |
| 52 | +- Investigate and identify any IP addresses identified in the Sign-in logs. |
| 53 | +- Add public IP addresses associated with known organizational egress points to their defined [named locations](location-condition.md#named-locations). |
| 54 | + |
| 55 | + [  ](./media/concept-continuous-access-evaluation-strict-enforcement/sign-in-logs-ip-address-seen-by-resource.png#lightbox) |
| 56 | + |
| 57 | +The following screenshot shows an example of a client’s access to a resource being blocked. This block is due to policies requiring CAE strict location enforcement being triggered revoking the client’s session. |
| 58 | + |
| 59 | +  |
| 60 | + |
| 61 | +This behavior can be verified in the sign-in logs. Look for **IP address (seen by resource)** and investigate adding this IP to [named locations](location-condition.md#named-locations) if experiencing unexpected blocks from Conditional Access on users. |
| 62 | + |
| 63 | +  |
| 64 | + |
| 65 | +Looking at the **Conditional Access Policy details** tab provides more details of blocked sign-in events. |
| 66 | + |
| 67 | +  |
| 68 | + |
| 69 | +### Step 4 - Continue deployment |
| 70 | + |
| 71 | +Repeat steps 2 and 3 with expanding groups of users until Strictly Enforce Location Policies are applied across your target user base. Roll out carefully to avoid impacting user experience. |
| 72 | + |
| 73 | +## Troubleshooting with Sign-in logs |
| 74 | + |
| 75 | +Administrators can investigate the Sign-in logs to find cases with **IP address (seen by resource)**. |
| 76 | + |
| 77 | +1. Sign in to the **Azure portal** as at least a Global Reader. |
| 78 | +1. Browse to **Azure Active Directory** > **Sign-ins**. |
| 79 | +1. Find events to review by adding filters and columns to filter out unnecessary information. |
| 80 | + 1. Add the **IP address (seen by resource)** column and filter out any blank items to narrow the scope. |
| 81 | + |
| 82 | + [  ](./media/concept-continuous-access-evaluation-strict-enforcement/sign-in-logs-ip-address-seen-by-resource.png#lightbox) |
| 83 | + |
| 84 | +**IP address (seen by resource)** contains filter isn't empty in the following examples: |
| 85 | + |
| 86 | +### Initial authentication |
| 87 | + |
| 88 | +1. Authentication succeeds using a CAE token. |
| 89 | + |
| 90 | +  |
| 91 | + |
| 92 | +1. The **IP address (seen by resource)** is different from the IP address seen by Azure AD. Although the IP address seen by the resource is known, there's no enforcement until the resource redirects the user for reevaluation of the IP address seen by the resource. |
| 93 | + |
| 94 | +  |
| 95 | + |
| 96 | +1. Azure AD authentication is successful because strict location enforcement isn't applied at the resource level. |
| 97 | + |
| 98 | +  |
| 99 | + |
| 100 | +### Resource redirect for reevaluation |
| 101 | + |
| 102 | +1. Authentication fails and a CAE token isn't issued. |
| 103 | + |
| 104 | +  |
| 105 | + |
| 106 | +1. **IP address (seen by resource)** is different from the IP seen by Azure AD. |
| 107 | + |
| 108 | +  |
| 109 | + |
| 110 | +1. Authentication isn't successful because **IP address (seen by resource)** isn't a known [named location](location-condition.md#named-locations) in Conditional Access. |
| 111 | + |
| 112 | +  |
| 113 | + |
| 114 | +## Next steps |
| 115 | + |
| 116 | +- [Continuous access evaluation in Azure AD](concept-continuous-access-evaluation.md) |
| 117 | +- [Claims challenges, claims requests, and client capabilities](../develop/claims-challenge.md) |
| 118 | +- [How to use continuous access evaluation enabled APIs in your applications](../develop/app-resilience-continuous-access-evaluation.md) |
| 119 | +- [Monitor and troubleshoot sign-ins with continuous access evaluation](howto-continuous-access-evaluation-troubleshoot.md#potential-ip-address-mismatch-between-azure-ad-and-resource-provider) |
0 commit comments