This chapter covers Named Locations in Conditional Access, a critical component for controlling access based on geographic or network location. Named locations allow administrators to define trusted or untrusted IP ranges (like corporate offices) or countries, and then use them in Conditional Access policies to enforce actions such as blocking access from certain regions or requiring multi-factor authentication from others. On the SC-900 exam, this topic appears in roughly 10-15% of questions related to Conditional Access, often testing your understanding of location conditions, trust types, and configuration options. Mastering named locations is essential for answering scenario-based questions about securing access in hybrid and cloud environments.
Jump to a section
Imagine a nightclub that has a strict bouncer at the door. The club has a VIP list and a blacklist. The bouncer checks each guest's ID (the user's location) against these lists. A 'named location' is like a predefined entry on either list—for example, 'Corporate HQ' is a VIP entry that always gets in, and 'Blocked Country X' is a blacklist entry that is always denied. The bouncer doesn't need to know every address; he just looks up the name. If a guest's ID shows they are from a trusted zip code (like a corporate office), the bouncer lets them in without further checks. If they are from a banned region, they are turned away immediately. For unknown locations, the bouncer might ask for additional proof (like multi-factor authentication). Importantly, the bouncer's lists are maintained by the club manager (the IT admin) and can be updated as needed. This system is efficient because the bouncer doesn't have to memorize every address—he just references the named lists. In the same way, Conditional Access policies use named locations to apply rules based on the user's IP address or country, without needing to hard-code IP ranges in every policy. The named location acts as a reusable, centrally managed reference that simplifies policy management and ensures consistency across all access rules.
What Are Named Locations and Why Do They Exist?
Named locations are a feature in Azure Active Directory (Azure AD) Conditional Access that allow administrators to define a set of IP address ranges or countries/regions, assign them a meaningful name, and then use that name as a condition in Conditional Access policies. For example, you can create a named location called 'Corporate HQ' containing the public IP addresses of your main office, and another named location called 'Blocked Countries' containing countries where your company does not operate. Then, in a Conditional Access policy, you can specify that access from 'Corporate HQ' is allowed without additional controls, while access from 'Blocked Countries' is blocked entirely.
The primary reason named locations exist is to simplify policy management and improve consistency. Without named locations, each Conditional Access policy would need to directly include the IP ranges or country codes, leading to duplication and maintenance nightmares. Named locations act as a central repository for location definitions that can be reused across multiple policies. They also support two types of location definitions: - IP ranges location: Specifies a set of IPv4 and IPv6 address ranges (CIDR notation) that are considered trusted or known. - Countries/Regions location: Specifies one or more countries or regions based on ISO 3166-2 codes.
How Named Locations Work Internally
When a user attempts to access a resource protected by a Conditional Access policy that includes a location condition, Azure AD evaluates the user's current IP address against the named locations defined in the tenant. The process is as follows:
User initiates authentication: The user signs in to an application (e.g., Outlook Web App, Azure portal).
Azure AD collects the user's IP address: Azure AD receives the source IP address from the authentication request. This is typically the public IP address of the user's network (e.g., the corporate NAT gateway).
Policy evaluation begins: Conditional Access evaluates all policies that apply to the user and application. For each policy that includes a location condition, Azure AD checks whether the user's IP address falls within any named location of type IP ranges, or whether the user's country (derived from IP geolocation) matches any named location of type countries/regions.
Matching logic:
- For IP range locations: Azure AD checks if the user's IP address is within any of the defined CIDR ranges. If it is, that named location is considered a match. - For country/region locations: Azure AD uses geolocation data to determine the country from the IP address and compares it to the selected countries/regions. If there is a match, that named location is considered a match. 5. Policy decision: Based on the configured condition (e.g., 'Include' or 'Exclude' a named location), the policy determines whether to apply controls (like requiring MFA) or to block access.
Key Components and Configuration
Named locations are configured in the Azure AD admin center under Security > Conditional Access > Named locations. There are two tabs: 'IP ranges location' and 'Countries/Regions location'.
IP Ranges Location:
You can add multiple IPv4 and IPv6 CIDR ranges.
Each range must be a valid CIDR block (e.g., 192.168.1.0/24, 2001:db8::/32).
You can mark a location as 'Trusted location'. Trusted locations are used by other Azure AD features like Identity Protection (e.g., for risk detection) and can be used in Conditional Access policies to exempt trusted locations from certain controls.
The maximum number of IP ranges per named location is 2,000, and the maximum number of named locations per tenant is 195.
Countries/Regions Location:
You select from a list of countries/regions based on ISO 3166-2 codes.
You can optionally enable the option 'Include unknown areas' to include IP addresses that cannot be geolocated (e.g., private IPs, test IPs). This is important because some users might be on VPNs or internal networks that don't have a public geolocation.
The 'Unknown' area is treated as a separate entity; if you include it, any IP that cannot be resolved to a known country will match this location.
Configuration Steps: 1. Navigate to Azure AD > Security > Conditional Access > Named locations. 2. Click 'New location'. 3. Choose either 'IP ranges location' or 'Countries/Regions location'. 4. Provide a name (e.g., 'Corporate Offices'). 5. For IP ranges: Add one or more CIDR ranges. Optionally check 'Mark as trusted location'. 6. For countries/regions: Select the countries from the list. Optionally check 'Include unknown areas'. 7. Click 'Create'.
Verification:
You can test the named location by using a tool like Azure AD's 'What If' policy evaluator. This tool simulates a user sign-in and shows which policies would apply, including location matches.
You can also use Azure AD sign-in logs to see the location details (IP, country) and whether a named location was matched.
Interaction with Related Technologies
Named locations are used in conjunction with several Azure AD features: - Conditional Access Policies: The location condition is one of many conditions (like user risk, device platform, client app). You can include or exclude named locations. - Identity Protection: Trusted locations are used to lower the risk score. If a sign-in comes from a trusted location, it is considered less risky. - Azure AD Multi-Factor Authentication (MFA): You can configure policies to require MFA only when users are not from trusted locations. - Azure AD Privileged Identity Management (PIM): PIM can use named locations to restrict activation of roles to trusted networks. - Azure AD Application Proxy: When publishing on-premises apps, you can restrict access based on named locations.
Important Defaults and Limits
Maximum named locations per tenant: 195.
Maximum IP ranges per named location: 2,000.
IPv6 support: Full support for both IPv4 and IPv6.
Geolocation accuracy: Country-level only; not city or postal code. The geolocation database is updated regularly but may have slight inaccuracies.
Trusted location flag: Only applicable to IP range locations, not countries/regions.
Evaluation time: Location is evaluated at authentication time. If the user's IP changes during a session (e.g., moving from office to coffee shop), the policy is not re-evaluated until the next authentication request.
Common Configuration Examples
Example 1: Block access from specific countries - Create a named location 'Blocked Countries' with countries where the company does not do business. - Create a Conditional Access policy: 'All users', 'All cloud apps', location condition: 'Include' the named location 'Blocked Countries', access controls: 'Block'.
Example 2: Require MFA from untrusted locations - Create a named location 'Corporate Network' with the company's public IP ranges, marked as trusted. - Create a Conditional Access policy: 'All users', 'All cloud apps', location condition: 'Exclude' the named location 'Corporate Network', access controls: 'Grant' requiring MFA.
Example 3: Allow only from corporate network for sensitive apps - Create a named location 'Corporate Network'. - Create a Conditional Access policy: 'All users', 'Sensitive app', location condition: 'Include' 'All locations' but 'Exclude' 'Corporate Network', access controls: 'Block'.
Troubleshooting Named Locations
User is not matching expected location: Check the user's IP address in the sign-in logs. The geolocation might be different from expected due to VPNs or proxy services.
IP range location not matching: Ensure the CIDR notation is correct and includes the user's IP. Remember that Azure AD uses the public IP, not the internal IP.
Country location not matching: The 'Unknown' area might need to be included if users are on internal networks without public geolocation.
Policy not applying as expected: Use the 'What If' tool to simulate sign-in and see which policies apply. Check the policy's user and app assignments.
Best Practices
Use named locations to reduce administrative overhead by reusing location definitions across multiple policies.
Mark corporate networks as trusted to simplify risk evaluation.
Regularly review and update IP ranges as your network changes.
Use countries/regions for broad geographic restrictions, but be aware of geolocation inaccuracies.
Combine location conditions with other conditions (e.g., device compliance) for defense in depth.
Define the Named Location
Navigate to Azure AD admin center > Security > Conditional Access > Named locations. Click 'New location' and choose either 'IP ranges location' or 'Countries/Regions location'. Give it a descriptive name, e.g., 'Headquarters'. For IP ranges, add CIDR blocks like 203.0.113.0/24. Optionally check 'Mark as trusted location' to use for risk reduction. For countries, select from the list. Click 'Create'. This step creates a reusable location definition that can be referenced in multiple policies.
Create a Conditional Access Policy
Go to Conditional Access > Policies > New policy. Assign a name, e.g., 'Require MFA from non-corporate locations'. Under 'Assignments', select users (e.g., All users) and cloud apps (e.g., Office 365). Under 'Conditions', click 'Locations'. Set 'Configure' to 'Yes'. In the 'Include' tab, select 'Any location'. In the 'Exclude' tab, select 'Selected locations' and choose the named location you created (e.g., 'Headquarters'). This ensures the policy applies only when the user is NOT at headquarters.
Configure Access Controls
Under 'Access controls', select 'Grant'. Choose 'Require multi-factor authentication' (or other controls like 'Require device to be marked as compliant'). Check 'Require all the selected controls' if combining multiple. Optionally, under 'Session', you can configure sign-in frequency or persistent browser session. Then set 'Enable policy' to 'On' (or 'Report-only' for testing). Click 'Create'. The policy will now evaluate every sign-in and apply MFA if the user's location matches the included (any) but not the excluded (headquarters).
Test with What If Tool
In Conditional Access, use the 'What If' tool to simulate a sign-in. Enter a test user, the cloud app, and the user's IP address (e.g., from a non-corporate network). Also set 'Country' if needed. Click 'What If'. The tool will list all policies that would apply, including the location-based policy. Verify that the policy shows 'Will apply' and the controls are as expected. This is a safe way to validate before enabling the policy in production.
Monitor Sign-in Logs
After enabling the policy, monitor Azure AD sign-in logs (Azure AD > Monitoring > Sign-ins). Filter by the user or app. For each sign-in, check the 'Location' tab to see the IP, country, and whether a named location was matched (the 'Named location' field). If the policy blocked access, the sign-in will show 'Failure' with reason 'Blocked by Conditional Access'. Review logs regularly to ensure the policy is working as intended and to catch any false positives.
Enterprise Scenario 1: Global Company with Regional Offices
A multinational corporation has offices in New York, London, and Tokyo, each with known public IP ranges. The security team wants to allow access to internal apps only from these offices, blocking all other locations. They create three named locations: 'NYC Office' (IP range 198.51.100.0/24), 'London Office' (203.0.113.0/24), and 'Tokyo Office' (192.0.2.0/24). They then create a single Conditional Access policy that includes all locations, but excludes these three named locations, and sets access to 'Block'. However, they soon realize that remote employees using VPNs from home are also blocked because their home IPs are not in the named locations. To fix this, they add the VPN's public IP ranges (e.g., 10.0.0.0/8 is private so they use the VPN gateway's public IP) as another named location 'VPN Pool'. They also create a separate policy for trusted locations that requires MFA only when not at an office or VPN. This scenario highlights the need to include all trusted IP ranges and to use multiple policies for different requirements.
Enterprise Scenario 2: Compliance with Data Residency Laws
A European company must ensure that user data never leaves the EU. They create a named location 'EU Countries' containing all EU member states. They create a Conditional Access policy that blocks access from any location not in 'EU Countries'. However, they encounter a problem: the geolocation database occasionally maps IPs to neighboring non-EU countries incorrectly. To mitigate, they enable 'Include unknown areas' to avoid blocking users whose IP cannot be geolocated (e.g., internal test networks). They also add a secondary policy that requires MFA for any access from unknown areas. This approach balances security with usability.
Common Pitfalls and Misconfigurations
Using private IPs in IP range locations: Named locations expect public IP addresses. Private IPs (like 10.x.x.x) are never seen by Azure AD because they are NATed. This leads to policies never matching.
Forgetting to exclude trusted locations: If you create a policy that requires MFA for all locations, but forget to exclude the corporate network, employees will be prompted for MFA even from the office, causing frustration.
Too many named locations: The 195 limit can be hit if you create separate named locations for each small subnet. Instead, aggregate IP ranges into larger CIDR blocks where possible.
Not updating IP ranges: When a company changes ISP or adds a new office, the named location must be updated. Otherwise, legitimate users may be blocked or required to MFA unnecessarily.
Performance Considerations
Named location evaluation is fast and does not introduce significant latency. However, if you have many IP ranges (close to 2,000 per location), the matching process may take slightly longer. Azure AD caches location data, so repeated evaluations from the same IP are efficient. The geolocation lookup is done at authentication time and adds negligible overhead.
What SC-900 Tests on Named Locations
The SC-900 exam objectives under 'Describe the capabilities of Azure AD Conditional Access' include understanding location conditions. Specifically, you need to know:
The two types of named locations: IP ranges and countries/regions.
That named locations are reusable across policies.
The concept of trusted locations and how they affect risk.
How to configure a Conditional Access policy to include or exclude a named location.
The difference between 'Include' and 'Exclude' in location conditions.
The maximum limits (195 named locations per tenant, 2000 IP ranges per location).
That geolocation is country-level only.
Common Wrong Answers and Why Candidates Choose Them
'Named locations can be based on city or postal code.' Many candidates assume geolocation is granular, but Azure AD only provides country-level. The exam tests this by offering options with city or postal code; the correct answer is always country.
'You can use private IP ranges in named locations.' Candidates often think they can specify internal IPs, but Azure AD sees only public IPs. The correct approach is to use the public IP of the NAT gateway.
'Named locations are applied in real-time during a session.' Some think location is re-evaluated continuously, but it is evaluated only at initial authentication. The exam might present a scenario where a user moves locations mid-session; the policy does not re-trigger.
'Trusted location is available for both IP ranges and countries.' Only IP range locations can be marked as trusted. Countries/regions locations cannot be trusted. This is a frequent trick.
Specific Numbers and Terms to Memorize - Maximum named locations: 195. - Maximum IP ranges per location: 2,000. - Trusted location: Only for IP ranges. - 'Include unknown areas' option for countries/regions. - ISO 3166-2 is the country code standard used.
Edge Cases the Exam Loves - What happens when a user's IP cannot be geolocated? The country is 'Unknown'. If the policy includes 'Unknown' area, it matches; otherwise it does not. - If you have overlapping IP ranges in different named locations, both are considered matches. The policy evaluation uses 'include any' or 'exclude all' logic. - When a user is on a VPN, the IP seen by Azure AD is the VPN's public IP, not the user's home IP.
How to Eliminate Wrong Answers - If an answer mentions 'city' or 'state', eliminate it immediately. - If an answer says 'private IP', eliminate it. - If an answer says 'trusted location for countries', eliminate it. - Look for the number '195' or '2000' in the correct answer. - For scenario questions, focus on the user's public IP and whether it falls in a named location.
Named locations come in two types: IP ranges and countries/regions.
Only IP range locations can be marked as trusted.
Maximum 195 named locations per tenant; maximum 2,000 IP ranges per named location.
Location is evaluated at initial authentication only, not continuously.
Private IP ranges are never seen by Azure AD; use public IPs of NAT gateways.
Geolocation is country-level only; city or postal code is not supported.
Use 'Include unknown areas' to handle IPs that cannot be geolocated.
Named locations are reusable across multiple Conditional Access policies.
These come up on the exam all the time. Here's how to tell them apart.
IP Ranges Location
Defined by CIDR IP address ranges (IPv4 and IPv6).
Can be marked as trusted location.
Maximum 2,000 IP ranges per location.
Suitable for known corporate networks or VPN pools.
More precise but requires maintenance when IPs change.
Countries/Regions Location
Defined by selecting countries/regions from a list.
Cannot be marked as trusted location.
No limit on number of countries per location.
Suitable for broad geographic restrictions (e.g., block all non-EU).
Less precise due to geolocation inaccuracies.
Mistake
Named locations can be based on city or postal code.
Correct
Azure AD named locations only support country-level geolocation (via countries/regions) or IP ranges. City or postal code granularity is not available.
Mistake
You can use private IP addresses (e.g., 10.0.0.0/8) in IP range locations.
Correct
Azure AD sees only the public IP address of the user's network. Private IPs are never visible because they are NATed. Therefore, private IP ranges will never match.
Mistake
Named locations are re-evaluated continuously during a user session.
Correct
Location is evaluated only at initial authentication. If a user's IP changes during a session (e.g., moving from office to home), the policy is not reapplied until the next sign-in.
Mistake
Countries/regions locations can be marked as trusted.
Correct
Only IP range locations have the 'Mark as trusted location' option. Countries/regions locations cannot be marked as trusted.
Mistake
You can create an unlimited number of named locations.
Correct
There is a hard limit of 195 named locations per tenant. Planning and consolidation are necessary to avoid hitting this limit.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A named location is a collection of IP address ranges or countries/regions that you define in Azure AD. You assign it a name and then reference it in Conditional Access policies to control access based on the user's location. For example, you can create a named location 'Corporate Network' with your office IPs and then create a policy that requires MFA only for users not coming from that location.
No. Azure AD named locations only support country-level geolocation. You cannot block by city, state, or postal code. For more granular control, you would need to use IP ranges if you know the specific public IP addresses of that city.
The maximum is 195 named locations per tenant. Each IP range location can contain up to 2,000 CIDR ranges. Plan accordingly to avoid hitting these limits.
This option is available only for IP range locations. When marked as trusted, the location is considered low-risk by Azure AD Identity Protection. Conditional Access policies can use this to exempt trusted locations from requiring MFA or other controls. It also affects risk scores in Identity Protection.
Azure AD sees the public IP address of the VPN gateway, not the user's home IP. So if you want to include VPN users in a named location, you must add the VPN gateway's public IP ranges to the named location.
The country is marked as 'Unknown'. In a countries/regions location, you can enable 'Include unknown areas' to treat these IPs as matching that location. If not enabled, unknown IPs will not match any country location.
Yes. Identity Protection uses trusted locations (from IP range named locations) to lower the risk of a sign-in. You can also use named locations in risk-based Conditional Access policies.
You've just covered Named Locations in Conditional Access — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?