Use Microsoft Entra ID Multifactor Authentication (MFA)

These instructions walk you through how to configure the Microsoft Entra ID integration allowing you to authenticate user accounts based on the information stored and managed there.

Before using MFA you should consider the relevant MFA troubleshooting section first.

Preflight (Checklist)

An installation of RADNAC with a working Microsoft Entra ID integration
- Follow the Start using Microsoft Entra ID if you do not
A Microsoft Entra ID P1 (or higher) license
- Also included with some Microsoft 365 subscriptions
- You should be able to find an Enterprise Application with the client ID ‘981f26a1-7f43-403b-a875-f8b09b8cd720’ however if you cannot you likely do not have a suitable license.
Users that will be in scope for MFA authentications must have Microsoft Authenticator installed on their mobile phone.

Steps

From the web user interface, click on the Entra tab and make sure you have selected the inner ‘MFA’ tab.

Policy

This works exactly in the same way as regular Microsoft Entra ID authentication policy but is used to determine which accounts are in scope for MFA.

Once you have configured your policies, click the Update button at the bottom of this page to activate your settings.

Troubleshooting

No Push Notifications

If you enable an MFA policy and immediately authentications fail without notifications being sent to user devices, it either menas:

Your tenant does not have any P1 or higher licenses associated with it.

The provisioning of those licenses failed to enable MFA for your tenant and requires manual intervention to fix.

Once fixed up, you also need to add the integration for RADNAC to be able to use the MFA functionality. This is best done by re-installing RADNAC but if this is inconvienent and you are comfortable with using the command line then please contact us for instructions on how to do this to an existing RADNAC deployment.

You have included users in the policy group that do not have the Microsoft Authenticator installed on their mobile phone.

Too Many Push Notifications

You may find your users are repeatedly sent push notifications when their devices either roam between access points or reconnecting during suspend and resume cycles.

This can be due to a number of reasons:

Your wireless equipment does not support 802.11r (FT - fast BSS transition).
Your wireless devices do not support TLS session resumption.
- RADNAC uses this to deduplicate MFA requests.
You are running a two VM deployment of RADNAC
- A known issue, described on our roadmap, prevents reliable deduplication of MFA requests.

Timeouts

A common issue is by default RADIUS clients (eg. wireless access points, VPN appliances and networking switches) expect replies to an authentication to complete within a few seconds which is not long enough for a push notification to make it to a user’s phone, that notification to be interactively reviewed and confirmed and then response to make it back to the RADIUS service.

This leads to timeouts and authentication failures.

The workaround is to increase any RADIUS timeout values to thirty (30) seconds, any higher will have no effect; for MikroTik equipment the configuration parameters are called timeout and radsec-timeout.

Limitations

Microsoft detail a number of limitations of their MFA integration when used with RADIUS that you should consult.

A common question is why support only push notifications. On the server side there are many possible options but the main issue is the lack of client side (device supplicant) support for this to work.

This can be accomplished using EAP-TTLS with EAP-GTC as your inner method but unfortunately the OS vendors (Android, Microsoft Windows, Apple iOS, …) have broken implementations of EAP-GTC that instead of treating this method as an interactive challenge for the user to complete it is instead treated as a generic ‘prompt for password’ field with the following consequences:

No supplicants (except for Linux) will display the dynamic challenge text to the user.
- For example “please type ‘42’ into your mobile authenticator app” is not show to the user.
The supplicant caches (meaning it remembers) the value previously provided by the user (no longer re-prompting) and attempts to reuse an old expired value.
- For example “type the OTP generated into your connecting device” is impossible as the user will not be re-prompted.