beawolf - Fotolia
Azure MFA NPS extension boosts authentication capabilities
With help from the Network Policy Server extension, organizations can expand their on-premises authentication features by tapping into Microsoft's cloud.
Your traditional RADIUS infrastructure can get a new life -- and expanded multi-factor authentication functionality -- with some assistance from the cloud.
Microsoft provides multi-factor authentication (MFA) through its Azure service with the flexibility to let organizations use it in both cloud services and on-premises infrastructure. For organizations that require cloud-based MFA capabilities within on-premises infrastructure, Microsoft offers a Network Policy Server (NPS) extension. This feature acts as an adapter between Azure Active Directory (AD) MFA and Remote Authentication Dial-In User Service (RADIUS) requests. The Azure MFA NPS extension provides phone calls, text messages or app verification services directly to the organizational authentication flow without requiring a new on-premises server. This arrangement brings authentication enhancements to the existing framework, but there are caveats to connecting this infrastructure to the cloud.
Azure MFA NPS extension prerequisites and costs
Azure MFA ties the second factor request to either a cloud account or a synchronized account within Azure AD. Though simple to use and implement, the NPS extension extends the Azure MFA capabilities directly into services such as Microsoft Remote Desktop or VPNs. The authentication mechanism is modified to support the authorization using a mobile authenticator app.
Using the NPS extension for Azure AD MFA requires the correct licensing. The feature is available to organizations with licenses for Azure MFA, which is available through Azure AD Premium, Enterprise Mobility and Security, or an MFA standalone license.
Consumption-based licenses, such as per user or per authentication, for Azure MFA aren't compatible with the NPS extension. Organizations cannot use the NPS extension with the free Azure AD tier or Office 365/Microsoft 365 Apps licenses. Microsoft bills Azure MFA for per user or per device by the month. If a company uses other licenses that are not per user or per device, there is no extra charge.
The on-premises servers must run Windows Server 2012 or higher to work with the NPS extension. Administrators need to install the Visual C++ Redistributable package and the Azure AD PowerShell module to complete the NPS extension configuration. The NPS needs internet access and must be able to connect to the following URLs over ports 80 and 443:
- https://adnotifications.windowsazure.com
- https://login.microsoftonline.com
- https://credentials.azure.com
Users who will rely on the NPS extension for MFA must be synchronized to Azure AD via Azure AD Connect. Implementing the NPS extension also requires all authentication to use MFA.
Why use Azure MFA and not a third-party platform?
There are many other MFA vendors and platforms available that provide similar authentication capabilities. Many of the other platforms still require Azure MFA licensing and specific product or platform licensing. Most modern third-party platforms now support conditional access implementation versus direct user configuration, but they also require double licensing.
A third-party vendor's advantage is often better support for other services and applications, support for different operating systems and applications, and better single sign-on support and end-user experience.
The main advantages of using the NPS extension are MFA works with a single license and the operating server contains the required roles.
Factors to weigh in the Azure MFA NPS extension deployment
Depending on the NPS extension's deployment size, organizations can either use dedicated NPSes or reuse an existing server. Most common deployments employ an existing NPS that may already function as a VPN server for the NPS extension installation. After deployment, the NPS extension brokers the connection between on premises and the cloud. End-user authorization flows to the primary authenticator, such as on-premises Active Directory, then directly to the Azure MFA service for the second factor.
Two main factors affect authentication methods available within the NPS extension deployment. The first is the selected password algorithm used between the RADIUS client, such as the VPN client, and the second is the chosen input method for the second-factor verification.
The NPS extension currently supports several password algorithms: password authentication protocol (PAP), challenge-handshake authentication protocol version 2 (CHAPV2) and extensible authentication protocol (EAP). PAP supports every authentication method within Azure AD MFA: phone call, one-way text message, mobile app notification, open authentication hardware tokens and mobile app verification code. CHAPV2 and EAP only support phone call and mobile app notification.
Where to look if problems start
If a failure occurs with the NPS extension, it could affect the entire authentication and authorization process. Some common issues found in many NPS extension implementations relate to security token errors, failing authentication and even invalid certificates.
If an error occurs, restart the NPS and run verification tests to check that the system is working as expected: verify the certificates, check Azure AD Connect account synchronization and NPS internet access.
Logs in the Event Viewer, specifically within the AzureMFA event list, help administrators with troubleshooting. Error details are also available within the Custom Views option of the Event Logs for Network Policy and Access Services.
The NPS extension does not support end user password changes as part of the sign-in workflow. While not technically an issue, this can cause support issues for the IT team.
What happens if an Azure Service outage occurs?
Outages are common issues for any organization that relies on a cloud service. What happens when unexpected downtime happens?
For an implementation of the NPS extension and Azure MFA, end users cannot complete the required second-factor validation. The effects of this outage could be massive or relatively minor, depending on the usage and implementation. For example, it could be limited to VPN access to the network. It could prevent an administrator from using Remote Desktop to access on-premises servers. It could block use of all cloud services, such as Microsoft 365.
Administrators can try to resolve this issue with configuration changes when the failure happens. Enabling MFA on the account is a cloud adjustment, which may not work due to the outage. A straightforward approach is to ensure security groups enforce MFA use. IT can add or remove users who require the second-factor enforcement and then use another group that does not require the second factor if a cloud outage happens. Another option is to set up two NPSes -- one configured with the Azure MFA extension and one without -- to perform a swap if required.
