Trying to get rid of the PhoneFactor remnants in my Azure AD tenant, I’ve already shown hot to move from per-user MFA to Conditional Access and to move from the ‘Allow users to remember multi-factor authentication on devices they trust’ option to Conditional Access.
Today let’s tackle a third configuration item: PhoneFactor’s Trusted IPs.
The Trusted IPs feature of Azure Multi-Factor Authentication bypasses multi-factor authentication prompts for people who sign in from a defined IP address range. You can set trusted IP ranges for your on-premises environments so when people are in one of those locations, there's no Azure Multi-Factor Authentication prompt.
However, I feel there’s a better way to handle this, with Named Locations.
Why you’d want to move to Named Locations
There are a couple of reasons why you’d want to make the move to Named Locations from Trusted IPs:
IPv6 is supported for Named Locations
Where the Trusted IPs functionality only supports IPv4 addresses, Named Locations can include both IPv4 and IPv6 addresses.
Named Locations offer descriptions
The Trusted IPs list, is just that; a list of IP addresses. The Named Locations name implies that it applies names to locations, defined as IP addresses. In Named Locations, you have the ability to provide a name for the IP addresses. This makes it more convenient for admins to manage locations, as they don’t need to remember the IP ranges.
Conditional Access offers more fine-grained controls
Trusted IPs are IP addresses that are trusted for every application and for every user; They exclude the IP address from ever having to perform Multi-factor Authentication. In Conditional Access, you can set Named Locations as part of a Conditional Access policy and apply it to only selected apps, selected users, selected user risks or selected devices. Also, you can specify certain Named Locations for a Conditional Access policy, but not all of them (as you would with trusted IPs).
Trusted IPs are also surfaced in Conditional Access, but do you really want to managed IP addresses in two places as an Azure AD admin?!
Conditional Access applies to non-Azure MFA too
The Trusted IPs functionality is part of the Azure Multi-Factor Authentication settings. As such, it does not apply to third-party multi-factor authentication solutions that you may have integrated with Azure AD.
Skip MFA for requests from federated users on my intranet
The option to skip multi-factor authentication for requests from federated users on the intranet seems like a good choice to keep when you use an on-premises federation solution and you use a Proxy-as-a-Service like ZScaler. However, it’s not a very reliable setting. Besides, ZScaler, F5, etc. now offer integrations with Azure AD to cope with these situations whether you’re using federation as the sign-in method or not.
Why you’d want to stick with Trusted IPs
There is only one reason to stick with the settings in the Trusted IPs area of the PhoneFactor settings:
Azure AD Premium
Conditional Access requires Azure AD Premium subscription licenses. While the Microsoft 365 E3, E5, F1 and F3, and EMS E3 and E5 product suites all include Azure AD Premium licenses, your organization may still lack these licenses and be locked out from using Conditional Access as a consequence.
How to make the switch
Switching from Trusted IPs to Named Location requires three actions:
- Delete the Trusted IPs
- Create the corresponding Conditional Access policy that defines the same coarse-grained location control
- Tweak your Conditional Access policies to define the optimal multi-factor authentication exclusions for your organization’s use cases
Delete the Trusted IPs
First, we need to create an inventory of the Trusted IPs. While we’re at the PhoneFactor admin website, we’ll delete them right away to avoid having to go there twice.
- Start a browser and navigate to the Azure AD Portal.
- Sign in with an account with Global Administrator privileges.
Perform multi-factor authentication when prompted. - In the left navigation menu, click Azure Active Directory.
- In Azure AD’s navigation menu, click Security.
- In the Security navigation menu, click on MFA under Manage.
- Follow the Additional cloud-based MFA settings link in the main pane.
A new tab or browser window opens.
You may have to sign in again. - In the trusted ips area, note down the IP addresses and/or IP address ranges currently defined as trusted IPs.
- Clear the list of trusted IPs (or go back after you’ve created the corresponding named locations and conditional access policies by performing steps 3-6 again.
Create the corresponding Named locations
To create the corresponding named locations, append the information of your IP addresses with meaningful labels in the Named Locations-fields:
- While still signed in to the Azure AD Portal, navigate back to the main Azure AD Tenant level or the Security level through the bread crumbs in the top bar of the Azure Portal.
Note:
If you’ve closed the browser window, or only want to perform this part of the steps, complete steps 1 through 4 of the steps for disabling the ‘Allow users to remember multi-factor authentication on devices they trust’ option above.
- In the Security navigation menu, click on Conditional Access.
- In the Conditional Access navigation menu, click on Name locations.
- In the Conditional Access | Named locations main pane, click the + New location link in the top action bar.
- The New named location pane appears.
- Specify a meaningful name for the named location in the Name field.
- Select the IP ranges option.
- Select the Mark as trusted location option if you want the named location to lower the user sign-in risk for people in your organization when they sign in from this location.
- Add the IP range(s) for the new named location. You can specify a /32 subnet mask to denote a single IPv4 address. You can add multiple IP ranges to the same named location. You can specify IPv6 locations.
- Click Create at the bottom of the New named location pane.
Repeat steps 3-9 to create additional named locations.
In step 6 you can also choose the Countries/Regions option. Then you’d select specific countries and/or regions, without having to worry about having to manually keep IP ranges in check for specific countries where you don’t want your organization’s applications and data to be accessible.
Tweak your Conditional Access policies
Now, use the named locations in your organization’s Conditional Access policies.
For any Conditional Access policy where you’d want the Named Location to be exempt from the Conditional Access policy, follow these steps:
- In the Conditional Access navigation menu, click on Policies.
- In the Conditional Access | Policies pane, click on the Conditional Access policy that you want to manage.
- In the pane for the Conditional Access policy, click on Conditions.
- In the Conditions context menu, click Locations.
- Switch the Configure setting to Yes.
- Click the Exclude header.
- Select Selected locations.
- Click the Select label.
The Select blade appears. - Select the named location(s) to use as exceptions to the Conditional Access policy.
Note:
If the Conditional Access policy features the MFA Trusted IPs location, unselect it here.
- Click the Select button at the bottom of the Select blade to select the location(s).
- Click the Save button at the bottom of the pane for the Conditional Access policy you’re managing.
Repeat steps 2-11 for any other Conditional Access policies where you want to use one or more named locations as exceptions for performing multi-factor authentication or other access controls.
Concluding
One by one, the settings in the legacy PhoneFactor pages is being replaced by better alternatives within the Azure Portal.
Extremely helpful, much better than the Microsoft documentation which doesn't tell me much about duplicative features such as this. Very appreciated.
Is there a way to use internal ip ranges to exclude a citrix farm or VDI's in a conditional access policy so those ip's don't get MFA?
Yes, device filters in Conditional Access exist for this purpose.
Very helpful description!
I am struggling with locations who have a dynamic IP assigned. It is undoable to update those trusted locations when the IP changes. And I am always too late. Is there a method to use something like a domain name/dynamicDNS entry to identify these locations and update them in azure?