MS Switch Access Policies (802.1X)

Host Modes

There are four authentication host modes to choose from:

• Single-Host (Default)
  With single-host authentication, a connected device will attempt authentication and if it fails to authenticate, the client will be denied access. This mode is recommended for switchports with only one client attached. If multiple devices are connected to the same switchport (for example a device connected via a hub or daisy-chained off of a VoIP phone), only one client will be allowed network access upon successful authentication. All subsequent authentication requests from other clients will be ignored and they will not be granted access as a result.
   

• Multi-Domain
  With multi-domain authentication, one device can be authenticated on each of the data and voice VLANs; if a second device is detected on one of the VLANs, the device will not be granted access. In this mode, Hybrid Authentication is used and Voice VLAN authentication is required.  This mode is recommended for switchports connected to a phone with a device behind the phone.  Authentication is independent on each VLAN and will not affect the forwarding state of each other.
  Cisco Meraki switches require the following attribute pairs within the Access-Accept frame to put devices on the voice VLAN:

  • Cisco-AVPair
        device-traffic-class=voice

• Multi-Auth
  With multi-auth, each connected device is required to authenticate. Multiple devices may be connected to each port. After a VLAN is assigned to a host on the port, subsequent hosts must have matching VLAN information or be denied access to the port. Only one client is supported on the voice VLAN. Guest VLANs are not supported in this mode.
• Multi-Host
  With multi-host, a single successful authentication will put the port into a forwarding state.  All subsequent authentication attempts are ignored. This is recommended in deployments where the authenticated device acts as a point of access to the network, for example, hubs and access points.

Access Policy Types

There are three options available for an access policy in Dashboard:

• 802.1X (Default)
  When an 802.1X access policy is enabled on a switchport, a client that connects to that switchport will be prompted to provide their domain credentials. If the RADIUS server accepts these credentials as valid, their device will be granted access to the network and get an IP configuration. If no authentication is attempted, they will be put on a "guest" VLAN, if one is defined.
  802.1X access policies are commonly used in enterprise environments, since they can authenticate against the existing domain userbase.
   
• MAC Authentication Bypass (MAB)
  When a MAB access policy is enabled on a switchport, the client's MAC address is authenticated against a RADIUS server without needing to prompt the user. If the server accepts the MAC as valid credentials for the network, the device will be allowed access.
  MAB access policies are useful for a more seamless user experience, restricting the network to specific devices without needing to prompt the user.
   
• Hybrid Authentication
  When a hybrid access policy is enabled on a switchport, the client will first be prompted to provide their domain credentials for 802.1X authentication. If 802.1X authentication fails, or if the switch does not receive any EAP packets within 8 seconds to begin 802.1X authentication, then the client's MAC address will be authenticated via MAB. If both methods of authentication fail, the device will be put on a "guest" VLAN, if one is defined.
  Hybrid authentication is helpful in environments where not every device supports 802.1X authentication since MAB exists as a failover mechanism.

Change of Authorization (CoA)

Meraki MS switches support CoA for RADIUS reauthentication and disconnection as well as port bouncing.  For more information, please see the following KB article.

• URL Redirect Walled Garden (Supported on MS210/225/250/350/355/390**/410/420/425)
  By default, URL redirect is enabled with CoA.  This can be used to redirect clients to a webpage for authentication.  Before authentication, http traffic is allowed but the switch redirects it to the redirect-url.  The walled garden can be used to limit access to the web server only.  This feature will only be enabled if one or more supported switches are in the network.  Configurations on this feature will be ignored by unsupported switches.

• For URL redirect on the MS390, there needs to be a walled-garden ACL name sent with the access-accept message from the RADIUS server. The first access-policy in the list will require an ACL name of Walled-Garden-00 and each subsequent access-policy will increment by 1. e.g. Access Policy 2 will be Walled-Garden-01. The Walled Garden ACL on the MS390 will allow DHCP, DNS, and IP access to the walled garden IP addresses. 

Other RADIUS Features

• RADIUS Accounting
  RADIUS Accounting can be enabled to send start, interim-update (default interval of 20 minutes) and stop messages to a configured RADIUS accounting server for tracking connected clients. Meraki’s implementation follows the IETF’s RFC 2869 standard.
  As of MS 10.19, device sensor functionality for enhanced device profiling has been added by including CDP/LLDP information the RADIUS Accounting message (MS120/125/220/225/250/320/350/355/410/425/450). As of 14.19 the MS390 also supports device sensor with enhanced attributes across LLDP, CDP, and DHCP for profiling. 
   
• RADIUS Testing
  Meraki switches will periodically send Access-Request messages to these RADIUS servers using identity 'meraki_8021x_test' to ensure that the RADIUS servers are reachable.  If unreachable, the switch will failover to the next configured server.
   
• RADIUS Monitoring
  In addition to the mechanism in RADIUS Testing, if all RADIUS servers are unreachable, clients attempting to authenticate will be put on the Guest or Critical Auth VLAN depending on which is defined.  When the connectivity to the server is regained, the switchport will be cycled to initiate authentication.  Please contact Meraki Support to enable this feature.

  This feature must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

  RADIUS test messages are sent every 5 minutes.

    
• Dynamic VLAN Assignment
  MS switches can dynamically assign a VLAN to a client device by configuring the switchport to use the VLAN ID received via the RADIUS attribute Tunnel-Pvt-Group-ID. It may be necessary to perform dynamic VLAN assignment on a per computer or per user basis. This can be done on your wired network via 802.1X authentication (RADIUS).

  MS390s support multi-vlan assignment, when using Multi-Auth as the host mode. This means that multiple client devices connected in the Data domain, on the same port can be mapped to different VLANs through RADIUS assignment. 
  
  This functionality is currently supported only on the MS390 switches.

  
  In order to do so, the following RADIUS attributes must be configured and passed in the RADIUS Access-Accept message from the RADIUS server. Once these attributes are configured on the RADIUS server, client devices can receive their VLAN assignment dynamically.
  • Tunnel-Medium-Type: Choose 802 (Includes all 802 media plus Ethernet canonical format) for the Attribute value Commonly used for 802.1X. 
  • Tunnel-Private-Group-ID: Choose String and enter the VLAN desired (ex. "500"). This string will specify the VLAN ID 500.
  • Tunnel-Type: Choose Attribute value Commonly used for 802.1X and select Virtual LANs (VLANs)
  
  Dynamic assignment of the VLAN for the Voice domain requires an additional attribute, device-traffic-class=voice, to be included in the Access-Accept message from the RADIUS server.

  Support for Dynamic VLAN Assignment for the Voice VLAN / domain was introduced in firmware version MS 15.

  
  For more information on how to configure with NPS, visit Microsoft's article on Configuring a Network Policy for VLANs.
• 802.1X Control Direction (Wake-on-LAN support)
  802.1X Control Direction is set by default to "both" directions. In this mode, the switchport doesn't allow ingress or egress traffic through the switchport until after the port is authorized via 802.1X or MAB authentication. Control Direction can also be set to "inbound-only", in which case the switchport doesn't allow ingress traffic, but will allow limited egress traffic from the network through the switchport to reach the connected device. This is often used to allow Wake-on-LAN magic packets to wake a sleeping host on the connected port, at which point the host can attempt a normal 802.1X or MAB authentication to authorize the switchport for full ingress and egress traffic.

• Guest VLAN
  Guest VLANs can be used to allow unauthorized devices access to limited network resources. This is not supported on the voice VLAN/domain.

  RADIUS Monitoring must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

   
• Failed Authentication VLAN
  A client device connecting to a switchport controlled by an access-policy can be placed in the failed authentication VLAN if the RADIUS server denies its access request. 

  Client devices may fail RADIUS authentication because they do not comply with the network's security requirements. The failed authentication VLAN provides such clients with limited access to network for remediation purposes.

  Failed Authentication VLAN is only supported in the Single Host, Multi Host and Multi Domain modes. Access policies using Multi Auth mode are not supported.

• Re-authentication Interval
  When the Re-authentication Interval (time in seconds) is specified, the switch will periodically attempt authentication for clients connected to switchports with access policies. Apart from providing for a better security policy by periodically validating client authentication in a network, the re-authentication timer is also enable the recovery of clients placed in the Failed Authentication because of incomplete provisioning of credentials.
  
  Re-authentication will not occur if no re-authentication interval has been configured, or if a reauthentication-interval has been configured but the switch has lost connectivity all the RADIUS servers listed under ther access policy.

• Critical Authentication VLAN
  The critical authentication VLAN can be used to provide network connectivity to client devices connecting on switchports controlled by an access-policy when all the RADIUS servers for that policy are unreachable or fail to respond to the authentication request on time.
  
  When the RADIUS servers are not reachable from the switch, authentication requests for clients attempting to connect to the network will fail, resulting in clients being denied access. Critical authentication VLAN ensures that these clients are still able access the business-critical resources, by placing them in separate VLAN, also allowing network administrators better control the network access available to clients when their identities cannot be established using RADIUS.

  The critical data and critical voice VLANs should not be the same.

  RADIUS Monitoring must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

  Configuring Critical Authentication VLAN or Failed Authentication VLAN under an access policy may affect its existing Guest VLAN behavior. Please consult the Interoperability and backward compatibility section of this document for details.

• Suspend port bounce
  When connectivity between the switch and any of the RADIUS servers is restored, the switch will attempt to authenticate the clients which it had placed in the Critical Authentication VLAN. The switch does this by bouncing (turning off and on) the switchports on which these clients are connected. If required, this port-bounce action can be disabled by enabling the Suspend port bounce option. When port-bounce is suspended, the clients will be retained in the Critical Authentication VLAN until a re-authentication for these clients is manually triggered.

RADIUS Attributes

When an access policy is configured with RADIUS server, authentication is performed using PAP. The following attributes are present in the Access-Request messages sent from MS switch to the RADIUS server.

• User-Name
• NAS-IP-Address
• Calling-Station-Id: Contains the MAC address of the Supplicant (all caps, octets separated by hyphens). Example: "AA-BB-CC-DD-EE-FF".
• Called-Station-Id: Contains the MAC address of the Meraki MS switch (all caps, octets separated by hyphens).
• Framed-MTU
• NAS-Port-Type
• EAP-Message
• Message-Authenticator