Named Locations and Conditional Access Policies

Named Locations in Azure Active Directory (Azure AD) are defined sets of IP address ranges or countries/regions that you can use to create rules in Conditional Access policies. They allow you to identify trusted or untrusted network locations where users sign in from. Conditional Access policies are the engine that enforces access controls based on signals like user, device, location, and application. Together, they enable granular access decisions beyond simple username and password.

In a zero-trust security model, you cannot assume that a user is safe just because they have the correct password. You need to consider where they are connecting from. For example, a sign-in from a corporate office IP range may be considered low-risk, while a sign-in from an anonymous proxy IP is high-risk. Named Locations allow you to categorize these IP ranges and countries, and Conditional Access policies use those categories to require additional verification (like MFA) or block access entirely.

When a user attempts to sign in, Azure AD evaluates the request. The source IP address of the authentication request is extracted from the HTTP headers. This IP is then compared against all defined Named Locations. Each Named Location is either an IPv4/IPv6 CIDR range or a country/region. Azure AD supports up to 195 named locations per tenant, with each location containing up to 1200 IP ranges. The evaluation happens in real-time during authentication.

Key components: - IP Ranges: You define IPv4 or IPv6 CIDR blocks. For example, 203.0.113.0/24. These are the actual network addresses of your corporate offices or VPN exit points. - Countries/Regions: You can select one or more countries from a predefined list. Azure AD uses the IP-to-location mapping from Microsoft's geo-IP database, which is updated regularly. - Mark as trusted location: A boolean flag. If checked, the location is considered trusted. This is used in Conditional Access policies to allow or require less stringent controls.

A Conditional Access policy is an if-then statement: if a condition is met, then apply access controls. Conditions include user/group membership, cloud app assignment, device state (compliant or hybrid Azure AD joined), location (via Named Locations), client app type, sign-in risk, and more. Access controls can be: - Block access: Deny sign-in entirely. - Grant access: Require MFA, require device to be marked as compliant, require hybrid Azure AD joined device, require approved client app, require app protection policy, or require password change. - Session controls: Use app-enforced restrictions, Conditional Access App Control, sign-in frequency, persistent browser session.

- If the policy includes a location condition, it compares the user's IP against Named Locations. - If the IP falls within an IP range of a Named Location, that location is considered the user's location. - If the IP maps to a country that is in a Named Location, that country location applies. 5. The policy then checks if the location is included or excluded. For example, a policy might say "Apply to all locations except trusted ones." 6. If the policy applies, the specified access controls are enforced. 7. If multiple policies apply, all grant controls must be satisfied (AND logic). If any policy blocks, block wins.

Named Locations can be configured via Azure portal (Azure AD > Security > Conditional Access > Named locations) or via PowerShell. Example PowerShell:

# Create a named location with IP ranges
$ipRanges = New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$ipRanges.CidrAddress = "192.168.1.0/24"
$location = New-Object -TypeName Microsoft.Open.MSGraph.Model.NamedLocation
$location.DisplayName = "Corporate Office"
$location.IpRanges = @($ipRanges)
$location.IsTrusted = $true
New-MgPolicyNamedLocation -BodyParameter $location

Conditional Access policies can be created via portal or PowerShell. Example using Microsoft Graph PowerShell:

# Create a Conditional Access policy requiring MFA for all users from untrusted locations
$params = @{
    displayName = "Require MFA from untrusted locations"
    state = "enabled"
    conditions = @{
        locations = @{
            includeLocations = @("All")
            excludeLocations = @("TrustedLocationsID")
        }
    }
    grantControls = @{
        builtInControls = @("mfa")
        operator = "OR"
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Named Locations and Conditional Access work closely with: - Azure AD Identity Protection: Sign-in risk and user risk can be used as conditions. For example, if a sign-in comes from an untrusted location and has medium risk, require MFA. - Azure AD MFA: Conditional Access is the primary way to enforce MFA. You can require MFA based on location. - Device compliance (Intune): You can require a device to be compliant or hybrid Azure AD joined. Location can be combined: from trusted locations, allow access without compliance; from untrusted, require compliance. - Azure AD B2B: Guest users can be subject to Conditional Access policies based on their location. - Azure AD Join/Hybrid Join: Device state is a condition. For example, only allow access from hybrid joined devices when coming from untrusted locations.

Azure AD supports IPv6 ranges in Named Locations. However, many organizations still use IPv4. When configuring, ensure you include both IPv4 and IPv6 ranges if your corporate network uses IPv6. The evaluation logic is the same.

A frequent mistake is not marking a corporate IP range as trusted. This causes Conditional Access policies that block untrusted locations to also block corporate users. Always mark your known corporate IP ranges as trusted locations.

Another mistake is using countries for location control without understanding that VPNs and proxies can mask the true location. For example, a user in a restricted country might use a VPN to appear in a trusted country. Conditional Access cannot detect VPNs unless you use additional signals like sign-in risk.

Named Locations provide a way to label IP ranges and countries. Conditional Access policies use these labels to make access decisions. The decision is binary: allow (with or without controls) or block. The evaluation is done at sign-in time and is based on the source IP of the authentication request. Policies are applied in a cumulative manner, with block policies taking precedence.

A multinational company with 50,000 employees wants to enforce MFA for all users accessing Office 365 from outside the corporate network. The corporate network consists of 10 offices worldwide, each with its own public IP range. The network team provides the IP ranges for each office. The Azure AD admin creates a named location called 'Corporate Network' with all these IP ranges and marks it as trusted. Then, they create a Conditional Access policy that applies to all users and all cloud apps, with location condition set to 'All untrusted locations', and grant control requiring MFA. They also exclude the 'Corporate Network' location from the policy. This ensures that users on the corporate network sign in without MFA, while remote users must use MFA. The policy is first tested in report-only mode for a week, and sign-in logs are reviewed to ensure no false positives. After enabling, MFA enrollment is enforced for all remote users. The company also uses Azure AD Identity Protection to detect risky sign-ins and block them if they come from untrusted locations with high risk.

A financial services firm operates only in the United States and Canada. They want to block all access to their cloud apps from other countries. They create a named location of type 'Countries' and select 'United States' and 'Canada'. They do not mark it as trusted because country locations cannot be trusted. Then they create a Conditional Access policy that applies to all users and all cloud apps, with location condition set to 'All locations' and exclude the named location 'Allowed Countries'. The grant control is set to 'Block access'. This effectively blocks sign-ins from any IP that resolves to a country outside the US and Canada. However, they realize that users traveling abroad might be blocked. To handle this, they create a second policy that allows access from excluded locations but requires MFA and device compliance. They also add a break-glass admin account that is excluded from all policies. This scenario is common for compliance with data sovereignty laws.