Named Locations and Network-Based Policies

Named locations are administrative constructs in Microsoft Entra ID that allow you to label IP address ranges or countries/regions with a meaningful name. They serve as conditions in Conditional Access policies and as signals for Identity Protection risk detection. The primary use cases are:

Named locations solve the problem of managing IP addresses in a human-readable way. Without them, administrators would have to enter raw IP ranges repeatedly in every policy. They also support IPv4 and IPv6, and can be marked as trusted or untrusted, which influences risk calculations.

When a user attempts to access a resource, the Microsoft Entra authentication pipeline evaluates the request. The source IP address of the client is extracted from the incoming HTTP request headers (specifically the X-Forwarded-For header if behind a proxy, or the direct client IP). This IP is compared against the defined named locations:

This evaluation happens for every authentication request, including interactive sign-ins, non-interactive token refreshes, and device-based auth. The result is passed to Conditional Access policies as the 'Location' condition.

- Types of Named Locations: - IP ranges location: Defined by one or more CIDR notation ranges (e.g., 192.168.1.0/24, 2001:db8::/32). You can mark it as 'Trusted location' (checkbox) which sets the location as trusted for risk calculations. - Countries/Regions location: Select from a list of countries/regions. You can optionally include 'Unknown' areas (IP addresses that cannot be geolocated). You can also exclude specific IP ranges from the country definition (e.g., exclude your corporate VPN from the 'United States' country location to avoid false positives). - Maximum number of named locations: 195 per tenant (as of 2025). Each IP range location can contain up to 2000 IP ranges (CIDR blocks). - Default values: No default named locations exist. You must create them. However, Microsoft provides predefined countries/regions for selection. - Timers: Changes to named locations are cached and may take up to 5 minutes to propagate to all authentication endpoints. For Identity Protection risk events, location data is evaluated in near real-time. - IP Geolocation: Microsoft uses a combination of public and proprietary data. It is not perfectly accurate, especially for mobile carriers and VPNs. Administrators can override geolocation by creating IP range locations that map to a specific country.

To create a named location via the Entra admin center: 1. Navigate to Identity > Security > Conditional Access > Named locations. 2. Click 'New location'. 3. Choose 'IP ranges location' or 'Countries/Regions location'. 4. Provide a name (e.g., 'CorpNet'). 5. For IP ranges: enter CIDR blocks, one per line. Optionally mark as trusted. 6. For countries: select from the list. Optionally include unknown areas. 7. Save.

To verify which named location a sign-in came from, you can use the Sign-in logs: 1. Go to Identity > Monitoring & health > Sign-in logs. 2. Select a sign-in event. 3. Under the 'Conditional Access' tab or 'Location' tab, you'll see the named location (e.g., 'CorpNet') or 'Unknown'.

Using PowerShell (Microsoft Graph PowerShell SDK):

# Connect to Graph
Connect-MgGraph -Scopes "Policy.Read.All"

# List named locations
Get-MgIdentityConditionalAccessNamedLocation | Select-Object Id, DisplayName, @{N='Type';E={$_.AdditionalProperties['@odata.type']}}

# Get details of a specific location
Get-MgIdentityConditionalAccessNamedLocation -NamedLocationId "<id>" | ConvertTo-Json -Depth 10

Named locations interact with: - Conditional Access: The 'Locations' condition can be set to 'Any location', 'All trusted locations', or 'Selected locations'. You can also exclude specific locations. - Identity Protection: Trusted locations lower the sign-in risk level. Sign-ins from untrusted or unknown locations can contribute to risk events like 'Anonymous IP address' or 'Atypical travel'. - Microsoft Defender for Cloud Apps (MDCA): MDCA can also define IP ranges and geolocations, but these are separate from Entra ID named locations. Policies in MDCA use their own context. - Hybrid Identity: For federated domains, the source IP seen by Entra ID might be the ADFS proxy's IP, not the client's. This can cause incorrect location matching unless you configure the correct IP addresses. - Network policies: Named locations are purely logical; they do not enforce network segmentation. They only inform access decisions.

Example policy: Block access from all countries except the United States, but allow access from corporate VPN even if it appears to be from another country.

This blocks all sign-ins except those from the US or from the corporate VPN.

A multinational company has offices in North America, Europe, and Asia. They want to allow access to internal apps only from office IPs and from a corporate VPN. They create named locations for each region (e.g., 'NA-Offices', 'EU-Offices', 'APAC-Offices') and a 'CorpVPN' location. In Conditional Access, they block access from all other locations. However, they discover that traveling employees using hotel Wi-Fi are blocked. They modify the policy to require MFA for non-office locations instead of blocking, but still block from high-risk countries. They also mark the office locations as trusted to reduce risk scoring. Challenges: IP geolocation for VPNs may show the VPN exit country, not the user's actual location. They overcome this by creating IP range locations for VPN ranges and marking them as trusted. Performance: With hundreds of IP ranges, the authentication pipeline remains fast as matching is done via efficient subnet lookup.

A hospital must ensure that access to patient records only comes from within the hospital network (on-premises) or from a managed device connected via VPN. They create a named location 'Hospital-Network' with all internal subnets (IPv4 and IPv6) and a 'Managed-VPN' location for VPN IPs. They also create a countries location that includes only the home country. Conditional Access policies require that any access from outside these locations is blocked. They also integrate with Microsoft Defender for Cloud Apps to monitor for impossible travel. A common issue: doctors working from home using personal devices may connect via VPN but the device is not managed. They solve this by requiring device compliance in addition to location. The named locations are updated quarterly as network changes occur. They use PowerShell scripts to export and audit the locations.

A tech startup has no physical offices; all employees work remotely. They use a corporate VPN for internal resources. They create a named location 'VPN-Exit' with the VPN's public IP ranges. They mark it as trusted. They also create countries locations for countries where they have employees (e.g., US, Canada, UK). They use Conditional Access to require MFA for all access, but exclude the VPN location from MFA to reduce friction. However, they notice that some employees connect from coffee shops without VPN and are prompted for MFA, which is acceptable. They also use Identity Protection to detect sign-ins from anonymous IPs. They learn that if an employee's home IP changes (ISP dynamic IP), they might not match the VPN location if they are not connected to VPN. They educate employees to always use VPN. They also set up a named location for 'Unknown' as untrusted. This simple setup works well for their small scale (<500 users).