Show Remote Authentication Dial-In User Service (RADIUS) is a network protocol that secures a network by enabling centralized authentication and authorization of dial-in users. Many applications still rely on the RADIUS protocol to authenticate users. Microsoft Windows Server has a role called the Network Policy Server (NPS), which can act as a RADIUS server and support RADIUS authentication. Azure Active Directory (Azure AD) enables Multi-factor authentication with RADIUS-based systems. If a customer wants to apply Azure AD Multi-Factor Authentication to any of the previously mentioned RADIUS workloads, they can install the Azure AD Multi-Factor Authentication NPS extension on their Windows NPS server. The Windows NPS server authenticates a user’s credentials against Active Directory, and then sends the Multi-Factor Authentication request to Azure. The user then receives a challenge on their mobile authenticator. Once successful, the client application is allowed to connect to the service. Use when:You need to add Multi-Factor Authentication to applications like
Note Rather than relying on RADIUS and the Azure AD Multi-Factor Authentication NPS extension to apply Azure AD Multi-Factor Authentication to VPN workloads, we recommend that you upgrade your VPN’s to SAML and directly federate your VPN with Azure AD. This gives your VPN the full breadth of Azure AD protection, including Conditional Access, Multi-Factor Authentication, device compliance, and Identity Protection. Components of the system
Implement RADIUS with Azure AD Cisco Meraki MR access points offer a number of authentication methods for wireless association, including the use of external authentication servers to support WPA2-Enterprise. This article outlines Dashboard configuration to use a RADIUS server for WPA2-Enterprise authentication, RADIUS server requirements, and an example server configuration using Windows NPS. WPA2-Enterprise with 802.1X authentication can be used to authenticate users or computers in a domain. The supplicant (wireless client) authenticates against the RADIUS server (authentication server) using an EAP method configured on the RADIUS server. The gateway APs (authenticator) role is to send authentication messages between the supplicant and authentication server. This means the RADIUS server is responsible for authenticating users. APs perform EAPOL exchanges between the supplicant and convert these to RADIUS Access-requests messages, which are sent to the RADIUS server's IP address and UDP port specified in Dashboard. Gateway APs need to receive a RADIUS Access-accept message from the RADIUS server in order to grant the supplicant access to the network. For best performance, it is recommended to have the RADIUS server and gateway APs located within the same layer-2 broadcast domain to avoid firewall, routing, or authentication delays. Keep in mind the AP is not responsible for authenticating wireless clients and acts as an intermediary between clients and the RADIUS server. The following image provides a detailed breakdown of the PEAP with MSCHAPv2 association process:
When WPA2-Enterprise with 802.1X authentication is configured, the following attributes are present in the Access-Request messages sent from the Cisco Meraki access point to the customer's RADIUS server.
The following attributes are honored by Cisco Meraki when received in an Access-Accept message from the customer's RADIUS server to the Cisco Meraki access point:
The most common EAP configuration is PEAP with MSCHAPv2, which prompts users for credentials (either user or machine authentication).
There are many server options available for RADIUS, which should work with MR access points if configured correctly. Please refer to your RADIUS server documentation for specifics, but the key requirements for WPA2-Enterprise with Meraki are as follows:
Once the RADIUS server is configured, refer to the Dashboard Configuration section below for instructions on how to add your RADIUS server to Dashboard.
The most common method of authentication with PEAP-MSCHAPv2 is user auth, in which clients are prompted to enter their domain credentials. It is also possible to configure RADIUS for machine authentication, in which the computers themselves are authenticated against RADIUS, so the user doesn't need to provide any credentials to gain access. Machine auth is typically accomplished using EAP-TLS, though some RADIUS server options do make it simple to accomplish machine auth using PEAP-MSCHAPv2 (including Windows NPS, as outlined in the example config below).
The following example configuration outlines how to set up Windows NPS as a RADIUS server, with Active Directory acting as a userbase:
Microsoft's RADIUS server offering for Windows Server 2008 and later is their Network Policy Server (NPS). Please refer to the following two Microsoft documents for instructions on adding the NPS role to Windows Server, and registering the new NPS server in Active Directory (allowing it to use AD as its userbase):
A RADIUS server must host a certificate that allows both network clients and Meraki APs to validate the server's identity. There are three options for this certificate:
Once a certificate has been acquired, please refer to Microsoft documentation for instructions on how to import a certificate.
In this scenario, APs communicate with clients and receive their domain credentials, which the AP then forwards to NPS. In order for an AP's RADIUS access-request message to be processed by NPS, it must first be added as a RADIUS client/authenticator by its IP address. Since only gateway APs have an IP address on the LAN, all gateway APs in the network must be added to NPS as RADIUS clients. To quickly gather all gateway APs' LAN IP addresses, navigate to Wireless > Monitor > Access points in Dashboard, ensure that the "LAN IP" column has been added to the table, and take note of all LAN IPs listed. APs with a LAN IP of "N/A" are repeaters, they do not need to be added as RADIUS clients:
Once a list of gateway APs' LAN IPs has been gathered, please refer to Microsoft's documentation for instructions on adding each AP as a client in NPS. Take note of the shared secret configured in NPS, this will be referenced in Dashboard.
NPS must be configured to support PEAP-MSCHAPv2 as its authentication method. This is accomplished in three steps, outlined below for NPS in Windows Server 2008:
Creating an NPS Policy
Change the Policy Process Order
The following image outlines an example of an NPS policy that supports user authentication with PEAP-MSCHAPv2:
For a seamless user experience, it may be ideal to deploy a PEAP wireless profile to domain computers so users can easily associate with the SSID. Though optional for user auth, this is strongly recommended for machine authentication. The following instructions explain how to push a PEAP wireless profile to domain computers using a GPO, on a Domain Controller running Windows Server 2008:
Once a RADIUS server has been set up with the appropriate requirements to support authentication, the following instructions explain how to configure an SSID to support WPA2-Enterprise, and authenticate against the RADIUS server:
Aside from the RADIUS server requirements outlined above, all authenticating APs will need to be able to contact the IP address and port specified in Dashboard. Make sure that your APs all have network connectivity to the RADIUS server, and no firewalls are preventing access.
Dashboard offers a number of options to tag client traffic from a particular SSID with a specific VLAN tag. Most commonly, the SSID will be associated with a VLAN ID, so all client traffic from that SSID will be sent on that VLAN. With RADIUS integration, a VLAN ID can be embedded within the RADIUS server's response. This allows for dynamic VLAN assignment based on the RADIUS server's configuration. Please refer to our documentation regarding Tagging Client VLANs with RADIUS Attributes for configuration specifics.
Dashboard has a built-in RADIUS test utility, to ensure that all access points (at least those broadcasting the SSID using RADIUS) can contact the RADIUS server:
Optionally, RADIUS accounting can be enabled on an SSID that's using WPA2-Enterprise with RADIUS authentication. When enabled, "start" and "stop" accounting messages are sent from the AP to the specified RADIUS accounting server. The following instructions explain how to enable RADIUS accounting on an SSID:
At this point, "Start" and "Stop" accounting messages will be sent from the APs to the RADIUS server whenever a client successfully connects or disconnects from the SSID, respectively. 8.6.1
Cisco Meraki access points can be configured to provide enterprise WPA2 authentication for wireless networks using Cisco Identity Services Engine (ISE) as a RADIUS server. This article will cover instructions for basic integration with this platform. For more detailed information on how to configure Cisco ISE, please refer to the Cisco Identity Services Engine User Guide. Prerequisites
After installation, Cisco ISE generates, by default, a self-signed local certificate and private key, and stores them on the server. This certificate will be used by default for WPA2-Enterprise. In a self-signed certificate, the hostname of Cisco ISE is used as the common name (CN) because it is required for HTTPS communication. Adding Managed Network Devices
Cisco ISE supports policy sets, which allows grouping sets of authentication and authorization policies, as opposed to the basic authentication and authorization policy model, which is a flat list of authentication and authorization rules. Policy sets allow for logically defining an organization's IT business use cases into policy groups or services, such as VPN and 802.1X. This makes configuration, deployment, and troubleshooting much easier.
|