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, Move from MFA Trusted IPs to Conditional Access Named Locations and to move from the ‘Allow users to remember multi-factor authentication on devices they trust’ option to Conditional Access.

Today let’s tackle another configuration item: the ‘Skip multi-factor authentication for requests from federated users on my intranet’ setting:

The the ‘Skip multi-factor authentication for requests from federated users on my intranet’ setting of Azure Multi-Factor Authentication bypasses multi-factor authentication prompts for people who:

• have federation defined as their Azure AD sign-in method,
• the federation solution is configured with an issuance transformation rule that passes through the insidecorporatenetwork claim type,
• sign-in using federation from a network location that is designated as the ‘Intranet’ or ‘Inside’ network in the federation solution, and thus;
• sign-in to an AD FS server that is part of the AD FS farm, and not to one of the Web Application Proxies, and thus;
• get the insidecorporatenetwork claim type from the federation solution in their claim.

In a networking infrastructure that features Active Directory Federation Services (AD FS), this scenario would be true when a person signs into an Azure AD-integrated app or service while connected to the corporate network or while connected to the VPN (depending on the tunneling settings of the VPN connection).

Tip!
If the claims rule is not present in your federation solution, add it using the claim rules from ADFSHelp for your ‘Office 365 Identity Platform’ Relying Party Trust.

I feel there are better ways to handle this.
These methods all revolve around Conditional Access and thus incur Azure AD Premium licenses. Yet, they are better solutions, because they don’t rely on a setting in an effectively deprecated portal, and they don’t rely on a condition that is examined only at the last stage of authentication when all other components, including Azure AD Identity Protection have deemed it necessary to perform multi-factor authentication.

Named Locations

For some organizations, the Named Locations feature in Conditional Access helps with avoiding multi-factor authentication prompts for on-premises users and other users in trusted locations.

For other organizations, using third party and/or hosted proxy services, the Named Location feature cannot be used, as they would either lose functionality when thy use a different egress IP address, or they would allow all organizations using the service to gain access without multi-factor authentication…

Hybrid Azure AD Join

Especially for the organizations in the latter category, but I feel this is true for every organization with people working remotely, configuring Hybrid Azure AD Join is a better solution.

With Hybrid Azure AD Join, domain-joined device objects are synchronized to Azure AD by Azure AD Connect. In federated setups, these objects are then attached to by the device itself so that it establishes a trust relation with both Azure AD and Active Directory.

In Conditional Access, the Grant blade offers the ability to grant access when devices are hybrid Azure AD-joined with the Require Hybrid Azure AD joined device.

When this route is taken, the organization explicitly trusts its Hybrid Azure AD-joined devices, regardless of their location.

Centralized management tooling and other risk mitigating controls will need to be in place to make sure the devices are, indeed, to be trusted.

Mobile Device Management (MDM)

For organizations that want to go one step further than to trust devices purely based on their domain membership, the Mobile Device Management (MDM) route is a method that’s based on continuous evaluation of the device’s compliance.

In MDM solutions, like Microsoft Intune, compliance policies can be defined that require security controls for Windows 10, like:

1. Require BitLocker Drive Encryption
2. Require Secure Boot
3. Require a password and password complexity
4. Require that the Microsoft Defender Firewall is enabled with appropriate settings
5. Require an anti-malware solution like Microsoft Defender with appropriate settings
6. Require a minimum OS (patch level)

Note:
When Microsoft Intune is used as an MDM solution, the above functionality requires Microsoft Intune licenses.

In Conditional Access, the Require device to be marked as compliant would then be used on the Grant blade to only allow access to these types of devices.

Concluding

There are better methods than the ‘Skip multi-factor authentication for requests from federated users on my intranet’ setting in the PhoneFactor portal.

When the time comes to migrate off AD FS, you’ll be glad you did, because the option is often overlooked during the inventory stage of the project to move from AD FS to Azure AD authentication and authorization.