One of the things we can do to protect our organization from account takeover attacks is to use locations as one of the conditions in our Conditional Access policies. Relying on location signal alone is not a good practice, but using location signal as one of the conditions might just be that one control that stops the otherwise successful attack. I think of this as ‘defense-in-depth’ style of condition that raises the cost of breach for the attacker. As the legacy MFA and SSPR controls are deprecating next year 2025, we should aim to stop using legacy ‘trusted IPs’ control at the same time when we migrate legacy MFA/SSPR to unified authentication method policies.
Setting the goal
Let’s dive into Microsoft Entra security feature called Named Locations that is the versatile successor of Trusted IPs which is a legacy control that we must get rid of (with one exception). In this blog we compare these two features and gain understanding how they work, what we should understand about having both features configured at the same time and lastly how Named Locations can be used to protect from an account takeover.
Trusted IPs
What are Trusted IPs? They are a legacy control that you can find at https://account.activedirectory.windowsazure.com/. In the Entra portal there are at least two links to this site: one at the Users > All users > Per-User MFA and the other at Security > Named Locations > Configure multifactor authentication trusted IPs. When you open this configuration page it opens in new tab and depending on which route you took you might either end up on the view below or at the ‘users’ tab. In the ‘service settings‘ tab there’s the trusted IPs section.
The most important insight about this control what we need to understand is that the ‘Skip multi-factor authentication for requests from federated users on my intranet’ checkbox is tenant-wide setting. This means that you cannot scope it to a certain group of people or application(s). The effect of it when it is checked, is that there will not be a multifactor authentication challenge to the user coming from the configured trusted IP addresses. It is in fact a MFA bypass mechanism and that’s why it is important and should be noticed and under control.
Organizations must migrate from legacy MFA and SSPR controls before 30th of September 2025. While this does not mean that the trusted IPs control will also be obsolete once the authentication method migration is completed, it means that we’re having our controls spread out which makes them more complex to manage. As of right now, if you’re using the Conditional Access policies (requires at least Entra ID P1 licensing) and you need to exclude IP addresses from MFA, please use Named Locations! Also at least start planning moving trusted IP exclusions to Named Locations.
If a user account that would have the permission to log in to the legacy MFA portal would get compromised, an attacker could set his own IP address(es) to the Trusted IPs list to gain backdoor access bypassing MFA. There does not seem to be a programmatic way to configure or monitor Trusted IPs which makes Named Locations more appealing option.
If you’re using Security Defaults instead of Conditional Access, trusted IPs legacy control does apply in that scenario also, and even after the authentication method migration. I consider Security Defaults being the only valid reason to still keep on using the trusted IPs.
Named Locations
Named locations is more versatile feature that is essential part of Microsoft Entra Conditional Access. With Named Locations there are two main methods of defining locations
- Define locations as countries either based on IP address or GPS coordinates
- Define locations as IP address ranges based on IPv4 or IPv6 addresses (in CIDR format)
- With IP address ranges you have the possibility to upload the IP address ranges as a text file
Here’s examples that you can define with Named Locations:
- Untrusted countries: Define countries that you want to block access from
- Trusted countries: Defined countries that you want to allow access from (with some other conditions + grant controls like MFA)
- Countries where company has offices and does business
- Untrusted network locations: Define untrusted network IP address ranges
- Trusted network locations: Define trusted network IP address ranges
- Company VPN, company network (office networks) etc.
Named Locations (countries and IP address ranges) need to be associated with Conditional Access policies (see picture above) to be included or excluded (Grant or block access). Named Locations in Conditional Access policy falls under the Network (Previously under Conditions > Locations).
GPS location
To use the country location defined by GPS, a user targeted to the conditional access policy needs Microsoft Authenticator app installed on their mobile device. The GPS location data is collected from the user’s mobile device using the Authenticator app. This process also includes jailbreak detection. Jailbroken devices are not considered trustworthy and user is blocked. GPS locations do not work with passwordless methods!
Trusted locations
Marking locations as trusted will improve Microsoft Entra ID Protection risk calculation accuracy for the sign-ins. User’s sign-in risk is lowered when signing in from trusted location. Of course, this happens even if the Named Location is not associated with any Conditional Access policy!
Manage Named Locations with PowerShell
This simple command will list all your Named Locations
# GET ALL NAMED LOCATIONS
Connect-MgGraph -Scopes Policy.Read.All -TenantId <YOUR_TENANT_ID>
Get-MgIdentityConditionalAccessNamedLocation
You can also create new named location, remove named location or update named location object (country type).
# CREATE NEW NAMED LOCATION OBJECT
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'
$params = @{
"@odata.type" = "#microsoft.graph.countryNamedLocation"
DisplayName = "Named Location: Allowed countries"
CountriesAndRegions = @(
"FI"
"SE"
"NO"
"DK"
)
IncludeUnknownCountriesAndRegions = $false
}
New-MgIdentityConditionalAccessNamedLocation -BodyParameter $params
# UPDATE NAMED LOCATION (country)
# You need Named Location id which you can get with Get-MgIdentityConditionalAccessNamedLocation command
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'
$params = @{
"@odata.type" = "#microsoft.graph.countryNamedLocation"
DisplayName = "Named location with unknown countries and regions"
CountriesAndRegions = @(
"FI"
"SE"
"NO"
"DK"
"EE"
)
IncludeUnknownCountriesAndRegions = $false
}
Update-MgIdentityConditionalAccessNamedLocation -NamedLocationId '187dcc1f-e726-48fa-adfa-df9ba0c76313' -BodyParameter $params
# REMOVE NAMED LOCATION
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'
Remove-MgIdentityConditionalAccessNamedLocation -NamedLocationId '187dcc1f-e726-48fa-adfa-df9ba0c76313'Named Locations and Protected Actions
Modifying named locations can be protected with Microsoft Entra Protected Actions feature which throws in an additional layer of authentication security. Trusted IPs cannot be protected with Protected Actions.
Named Locations as defense-in-depth control
In order to protect our organization from account takeover and token theft using AiTM infrastructure, we need to implement controls that will either prevent the AiTM attack or make the token replay impossible. There controls can be found from the Conditional Access policies under the Access control section and they are:
- Require authentication strength: Phishing-resistant MFA
- Require device to be marked as compliant
- Require Microsoft Entra hybrid joined device
There is a proverb (in Finland, maybe elsewhere too?) that goes like “To use belt and suspenders” meaning that it’s better to be safe than sorry. This approach is what we must utilize to benefit from the Named Locations. Like I said before, configuring the Network section in Conditional Access policy alone is not going to be good enough safety measure and in general we might not want to configure it at all for our mobile workforce. But maybe some actions, operations or applications are that sensitive that we do want to take the extra step to make sure that the user will have to comply with multiple conditions even before they need to satisfy the Grant control requirements.
For example, Microsoft Entra has Protected Actions feature that can be associated to Conditional Access via Authentication Context. Those actions are classified as the most sensitive actions there are in Entra ID. If Protected Actions is not familiar check out my blog post about Protected Actions and also check the official documentation. So it’s a good idea to require additional conditions like trusted network location to be able to execute any of the protected actions. Or maybe you have highly sensitive data on your SharePoint which you do not want to be access from all over the world? Define the network location (countries) that are allowed among the MFA and compliant device requirement.
My suggestion is to use Named Locations as an additional security condition layer, but never to rely only on network location and for example dismiss user MFA requirement because of trusted network location.
Summary
This was a short summary about Named Locations and Trusted IPs, which is a legacy control that in most cases organizations can and should let go of. I’ve seen many organizations already done this, but I’ve also seen that some organizations might be happily oblivious that this control still exists and means something. Because of the sensitive and high impact nature of the legacy control, being MFA bypass at tenant-wide scope, I felt like I needed to do my part to raise awareness.
Stay secure!
