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.
Note: Please refer to RFC 2865 for details on these attributes, additional notes for certain attributes are included below.
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).
Note: Certificate-based authentication using EAP-TLS is also supported by the Meraki platform, but is outside the scope of this document. For more information on WPA2-Enterprise using EAP-TLS, please refer to our documentation.
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).
Note: "Machine Authentication" is not the same as MAC-based authentication, which is another configuration option in Dashboard under Wireless > Configure > Access Control. Machine authentication, specifically, refers to devices authenticating against RADIUS
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.
Note: To save time, entire subnets can also be added to NPS as RADIUS clients, and any requests coming from that subnet will be processed by NPS. This is only recommended if all APs are on their own management VLAN and subnet, to reduce security risks.
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:
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:
For Trusted Root Certification Authorities select the check box next to the appropriate Certificate Authorities and click OK.
Click OK to close out and click Apply on wireless policy page to save the settings.
Apply the GPO to the domain or OU containing the domain member computers (refer to Microsoft documentation for details).
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.