Configuring RADIUS Authentication with WPA2-Enterprise

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.

Overview

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:

Supported RADIUS Attributes

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.

• User-Name
• NAS-IP-Address
• NAS-Port

• Called-Station-ID

  : Contains (1) the Meraki access point’s BSSID (all caps, octets separated by hyphens) and (2) the SSID on which the wireless device is connecting. These 2 fields are separated by a colon. Example: “AA-BB-CC-DD-EE-FF:SSID_NAME”.

Note: BSSID MAC addresses will be different for each configured SSID. Additional information is available for Calculating Cisco Meraki BSSID MAC Addresses .

Note: SSIDs broadcasted by repeater APs in a mesh deployment can’t use NAS-IP-Address attribute because repeater APs do not have IP addresses assigned. You can use NAS-ID attribute instead, which by default carries NODE_MAC:VAP_NUM.

• Calling-Station-ID

  : Contains the MAC address of the wireless device (all caps, octets separated by hyphens). Example: “AA-BB-CC-DD-EE-FF”.

• Framed-MTU
• NAS-Port-Type
• Connect-Info
• Meraki-Device-Name: Name of the Meraki device as configured in the dashboard 

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:

• Tunnel-Private-Group-ID

  : Contains the VLAN ID that should be applied to a wireless user or device. (This can be configured to override VLAN settings that an administrator has configured for a particular SSID in the Cisco Meraki Cloud Controller.)

• Tunnel-Type

  : Specifies the tunneling protocol. Example: VLAN.

• Tunnel-Medium-Type

  : Sets the transport medium type used to create the tunnel. Example: 802 (which includes 802.11).

• Filter-Id

   / 

  Reply-Message

   / 

  Airespace-ACL-Name

   / 

  Aruba-User-Role

  : Any of these attributes can be used to convey a policy that should be applied to a wireless user or device. (The attribute type should match that which is configured under the Configure tab > Group policies page in the Cisco Meraki Cloud Controller. The attribute value should match the name of a policy group configured on that page.)