Microsoft Entra IDOverview
Microsoft Entra ID Conditional Access allows an organization to configure Named locations and configure whether those locations are trusted or untrusted. These settings provide organizations the means to specify Geographical locations for use in conditional access policies, or define actual IP addresses and IP ranges and whether or not those IP addresses and/or ranges are trusted by the organization.
Rationale
Defining trusted source IP addresses or ranges helps organizations create and enforce Conditional Access policies around those trusted or untrusted IP addresses and ranges. Users authenticating from trusted IP addresses and/or ranges may have fewer access restrictions or access requirements when compared to users who try to authenticate to Azure Active Directory from untrusted locations or untrusted source IP addresses/ranges.
Impact
When configuring Named locations, the organization can create locations using Geographical location data or by defining source IP addresses or ranges. Configuring Named locations using a Country location does not provide the organization the ability to mark those locations as trusted, and any Conditional Access policy relying on those Countries location settings will not be able to use the All trusted locations setting within the Conditional Access policy. Instead, they will have to rely on the Select locations setting. This may add additional resource requirements when configuring and will require thorough organizational testing.
In general, Conditional Access policies may completely prevent users from authenticating to Azure Active Directory, and thorough testing is recommended. To avoid a complete lockout, a 'Break Glass' account with full Global Administrator rights is recommended in the event all other administrators are locked out of authenticating to Azure Active Directory. This 'Break Glass' account should be excluded from Conditional Access Policies and should be configured with the longest pass phrase feasible. This account should only be used in the event of an emergency and complete administrator lockout.
Default Value
No trusted locations are configured by default.
Remediation guidance
From Azure Portal
- Open Conditional Access | Named locations
- Click on
IP ranges location. - Enter a name for this location setting in the
Nametext box. - Click on the
+sign. - Add an IP Address Range in CIDR notation inside the text box that appears.
- Click on the
Addbutton. - Repeat steps 5 through 7 for each IP Range that needs to be added.
- If the information entered is trusted ranges, select the
Mark as trusted locationcheck box. - Once finished, click on
Create.
From PowerShell
Create a new trusted IP-based Named location policy:
[System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.IpRange]]$ipR anges = @()
$ipRanges.Add("<first IP range in CIDR notation>")
$ipRanges.Add("<second IP range in CIDR notation>")
$ipRanges.Add("<third IP range in CIDR notation>") New-AzureADMSNamedLocationPolicy -OdataType "#microsoft.graph.ipNamedLocation" -DisplayName "<name of IP Named location policy> -IsTrusted $true -IpRanges $ipRanges
Set an existing IP-based Named location policy to trusted:
Set-AzureADMSNamedLocationPolicy -PolicyId "" -OdataType "#microsoft.graph.ipNamedLocation" -IsTrusted $true
Multiple Remediation Paths
SERVICE-WIDE (RECOMMENDED when many resources are affected): Apply organization/tenant-level guardrails and baseline policies for the entire platform.
ASSET-LEVEL: Fix only the affected resources identified by this control.
PREVENTIVE: Add preventive policy checks to CI/CD and periodic posture scans.
References for Service-Wide Patterns
- Platform policy/governance and preventive control patterns should be applied tenant-wide where supported.
Query logic
These are the stored checks tied to this control.
Entra tenants without trusted IP Named Locations
Connectors
Covered asset types
Expected check: eq []
{
connectors(
where: { namedLocations_NONE: { type: "ipNamedLocation", isTrusted: true } }
) {
...AssetFragment
}
}
