Configuring ADFS to bypass Azure Multi-factor Authentication from inside the Intranet

Multi-factor Authentication is becoming common place for all enterprise applications, especially those applications running in the cloud. Office 365 is no exception, out the box even the most basic Office 365 SKU’s provide some level of MFA. Although MFA is great for increasing the security posture of your Office 365 tenant, it does inherently annoy users.

A common requirement for enterprise organisations deploying MFA with Office 365, is the ability for MFA to be bypassed if a user is connecting from a domain-joined, Intranet device.

It is possible to achieve this using the full Azure Multi-Factor Authentication product from Azure AD, the feature is called Trusted IP’s. As you will see from the table below, the entry-level MFA for Office 365 does not support Trusted IP’s. The full Azure Multi-Factor Authentication is part of EMS E3/5 and is bundled with Azure AD Premium P1/P2.

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-versions-plans

If you are using cloud-managed identities (e.g not using ADFS) you can enable this straight out the box if you are using Azure Multi-Factor Authentication. However, many enterprise organisations have ADFS in the mix to provide SSO to users. If you have federated identities (e.g using ADFS) enabling Trusted IP’s straight from the portal alone does not bypass the MFA prompt. Users will still be asked to enter their 2nd factor or “something they have”. ADFS must be configured to emits the multipleauthn claim when a user performs two-step verification.

The following Microsoft guide explains how to configure the changes required on the Office 365 Relaying Party Trust

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-adfs-cloud

Once completed your Office 365 Relaying Party Trust > Edit Claim Issuance Policy for Microsoft Office 365 Identity Platform should look similar to this.

Restart the Active Directory Federation Services service once you have made the changes.

Browse to https://manage.windowsazure.com then click on Active Directory.

Click on the Azure Active Directory instance which is linked to your Office 365 tenant and click Configure.

Under the Multi-Factor Authentication subheading click Manage Service Settings.

Under Trusted IPs enable Skip multi-factor authentication for requests from federated users on my Intranet.

You should populate this field with all your Public IP’s which are used by clients for Internet access. In my example, I’ve put my testing server address with CIDR mask of /32 which locks it down to a single address.

Click Apply.

Customise IKE/IPsec Policy for Azure Virtual Network Gateway Connection Object

Microsoft has given us the ability to define custom IKE/IPsec policies for use with the native Virtual Network Gateway. In the past, the on-premise peer device had to support the fairly limited protocols suites that were statically set on the Virtual Network Gateway. 

It should be noted that custom IKE/IPsec policies are set at connection object level and not on the Virtual Network Gateway itself, this offers greater flexibility when you have multi-site VPN connections terminated on a single Virtual Network Gateway. This example covers how to create a custom policy for an S2S VPN connection, it is also possible to apply custom policies to vNet to vNet connection. Although this may not be as commonly done after vNet Peering becoming GA. 

Please note that in this example the Virtual Network Gateway along with the Local Network Gateway has already been defined in my subscription. The Local Network Gateway is the resource that contains the remote VPN peer address etc.

This command creates the new policy and stores it in a variable called $policy, this will be referenced when we are creating the new connection object.

$policy = New-AzureRmIpsecPolicy -DhGroup ECP384 -IkeEncryption AES256 -IkeIntegrity SHA384 -IpsecEncryption GCMAES256 -IpsecIntegrity GCMAES256 -PfsGroup

This command stores the Virtual Network Gateway you want to create the connection object on and stores it in a variable called $gateway.

$gateway = Get-AzureRmVirtualNetworkGateway -Name "rbVNG01" -ResourceGroupName "rbRG1"

This command stores the Local Network Gateway object in the variable $remote

$remote = Get-AzureRmLocalNetworkGateway -Name "TW-2-AZ" -ResourceGroupName "rbRG1"

This command creates the connection object and applies the newly created policy.

New-AzureRmVirtualNetworkGatewayConnection -Name "TW-2-AZ" -ResourceGroupName "rbRG1" -VirtualNetworkGateway1 $gateway -LocalNetworkGateway2 $remote -Location "UK South" -ConnectionType IPsec -IpsecPolicies $policy -SharedKey "VerySecretCode"

Please review this article for full details on the supported protocol suites etc.

https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-ipsecikepolicy-rm-powershell