on
06-20-2016
10:04 AM
- edited on
07-30-2024
10:05 AM
by
shaunwhi
Authors: Tim Abbott, Alex Burger, Victor Cho, Tony Carmichael
Table of Contents
This configuration example illustrates how to use Cisco Identity Services Engine (ISE) to authenticate users attempting access to Meraki wireless, wired, and VPN networks. ISE uses predefined Meraki Group Policies to assign network users an access policy based on group membership in Microsoft’s Active Directory (AD), Guest user credentials, or Endpoint information. The example uses the following Identity Groups: Employees, Contractors, Guests and Workstations. Using these groups, the document outlines the steps necessary to configure 802.1X, MAC Authentication Bypass (MAB), Local Web Authentication (LWA), Central Web Authentication (CWA), Remote Access (RA) VPN and Profiling where applicable. For the latest documentation please visit the Cisco Meraki documentation:
Model | 802.1X | MAB | VLAN | Group Policy ACL | Adaptive Policy | URL Redirect | CoA | Profiling |
Wireless | ||||||||
MR20, MR70, MR28, MR78 | ✔ | ✔ | ✔ | ✔ | - | ✔ | ✔ | - |
MR30H, MR36, MR42/E, MR44, MR45, MR46/E, MR52, MR53E, MR56, MR57, MR74, MR76, MR86, CW916x | ✔ | ✔ | ✔ | ✔ | ✔ 802.11ac Wave2 or higher. Minimum 27.6 |
✔ | ✔ | - |
Teleworker | ||||||||
Z3/C | ✔ | ✔ | - | - | ✔ Transport MX18.1+ |
- | - | - |
Switching | ||||||||
MS130 | ✔ | ✔ | ✔ | - | - | - | ✔ | CDP+LLDP |
MS130X/MS130R | ✔ | ✔ | ✔ | - |
✔ No IP-SGT, No SGACL Logging |
- | ✔ | CDP+LLDP |
MS120, MS125 | ✔ | ✔ | ✔ | - | - | - | ✔ | CDP+LLDP |
MS210, MS225, MS250 | ✔ | ✔ | ✔ | ✔ | - | ✔ | ✔ | CDP+LLDP |
MS350, MS355 | ✔ | ✔ | ✔ | ✔ | - | ✔ | ✔ | CDP+LLDP |
MS390, C9300-M | ✔ | ✔ | ✔ | ✔ | ✔ Minimum 14.12 |
✔ | ✔ | Full Device Sensor CDP/LLDP/DHCP/HTTP |
MS410, MS425, MS450 (aggregation) | ✔ | ✔ | ✔ | ✔ | - | ✔ | ✔ | CDP+LLDP |
Security & SD-WAN | ||||||||
MX64/W, MX67/C/W, MX68/CW/W, MX75, MX84, MX85, MX95, MX100, MX105, MX250, MX450 | ✔ 802.1X or MAB |
✔ 802.1X or MAB |
- | - | ✔ Transport MX18.1+ | - | - | - |
vMX, vMX100 | - | - | - | - | - | - | - | - |
This guide assumes that both ISE and a Meraki network have been installed and are functioning properly. A step-by-step guide on how to set up Meraki networks is available at documentation.meraki.com. The Meraki wireless networks should be configured with three SSIDs. The Meraki wired network should be configured with Employee and Guest VLANs. A subnet for RA VPN clients should also be identified. Cisco ISE will use AD as an external identity source for user authentication and differentiated authorization policy assignment. Any AD groups intended for use in authorization policy should be preconfigured in the documentation.meraki.com ISE as well as Sponsored Guest Policy. Reference the ISE User Guide for more information or how to configure Sponsored Guests and to integrate ISE with AD. For information on Meraki's Adaptive Policy feature-set from theory to configuration, please refer to the following documentation article links:
Adaptive Policy Overview
Adaptive Policy and Cisco ISE
Adaptive Policy and Catalyst Interoperability
Using Meraki Group Policies, configure a Group Policy for the Employee and Contractor groups in AD. Then add ISE as the RADIUS server for the Dot1x, LWA/CWA and MAB SSIDs. Users who belong to the Employee or Contractor AD group will be able to connect to the Dot1x SSID. Users with Guest credentials will be able to connect to the LWA SSID and devices belonging to the Workstation Endpoint Identity Group in ISE will be able to associate to the MAB SSID.
This section shows an example configuration for an 802.1X-protected SSID using ISE as the RADIUS server. During authentication, ISE tells the Cloud Management Platform which Group Policy to assign using the Airespace-ACL-Name RADIUS vendor specific attribute (VSA). In addition, selecting Cisco ISE for the splash page setting allows for advanced use cases such as Native Supplicant Provisioning, MDM enrollment, and Posture Assessment.
Note: Optionally, you may configure Per-User VLAN tagging in addition to the Group Policy assignment. ISE can tell the Cloud Management Platform which VLAN to assign to the user. This method would allow you to further differentiate user groups and assign different access policies during authentication.
Dot1x SSID Access Control |
|
Network Access | |
Association Requirements | WPA2 Enterprise with my RADIUS server. |
Splash Page | Cisco Identity Services Engine (ISE) Authentication |
RADIUS Servers | IP address, port 1812 and secret of ISE policy service node(s) |
RADIUS Testing | RADIUS testing disabled |
RADIUS Accounting | RADIUS accounting is enabled |
RADIUS Accounting Servers | IP address, port 1813 and secret of ISE policy service node(s) |
RADIUS attribute specifying group policy name | Airespace-ACL-Name |
Walled garden | Enabled, Add DNS and ISE policy service node(s) |
Assign group policies by device type | Disabled: Do not assign group policies automatically |
Addressing and traffic | |
Client IP assignment | Bridged Mode: Make clients a part of the LAN |
VLAN tagging | Don’t use VLAN tagging |
This section shows an example of how to configure LWA using ISE as the RADIUS server. The captive portal web page is served from the Cloud Management Platform and must be able to communicate with ISE across the Internet for credential validation. The Meraki Security Appliance must be configured to allow RADIUS traffic on UDP ports 1812 and 1813 from the Cloud Management Platform to ISE. Reference http://docs.meraki.com/ for information on how to configured firewall rules on the Meraki Security Appliance. Guest credentials are created on ISE and sent to the guest user via the Sponsor Portal.
Note: The AP Tag must be configured on the access point for the configuration to take effect and the link between the switch and access point must be a VLAN trunk. In this scenario, ISE will not need to assign the VLAN ID, as each user attempting to authenticate to the Guest SSID will use the Guest VLAN. See Meraki Cloud Managed Wireless documentation for more information.
Guest SSID Access Control |
|
Network Access | |
Association Requirements | Open (no encryption) |
Splash Page | Sign-on with my RADIUS server |
RADIUS for splash page | IP address, port 1812 and secret of ISE policy service nodes |
Assign group policies by device type | Disabled: Do not assign group policies automatically |
Addressing and traffic | |
Client IP assignment | Bridged Mode: Make clients a part of the LAN |
VLAN tagging | Use VLAN tagging |
VLAN ID | AP Tag and VLAN ID of guest VLAN on upstream switch |
RADIUS override | Ignore VLAN attribute in RADIUS responses |
MAB SSID Access Control | |
Network Access | |
Association Requirements | MAC-based access control (no encryption) |
Splash Page | Cisco Identity Services Engine (ISE) Authentication |
RADIUS Servers | IP address, port 1812 and secret of ISE policy service node(s) |
RADIUS Testing | RADIUS testing disabled |
RADIUS Accounting | IP address, port 1813 and secret of ISE policy service node(s) |
RADIUS attribute specifying group policy name | Airespace-ACL-Name |
Assign group policies by device type | Disabled: Do not assign group policies automatically |
Walled garden | Enabled, Add DNS and ISE policy services node(s) |
Addressing and traffic | |
Client IP assignment | Bridged Mode: Make clients a part of the LAN |
VLAN tagging | Use VLAN tagging |
VLAN ID | AP Tag and VLAN ID of Workstation (MAB) VLAN on upstream switch |
RADIUS override | Ignore VLAN attribute in RADIUS responses |
This section outlines the configuration steps necessary to use ISE as a RADIUS server for use with Meraki switches. Employee workstations will authenticate via 802.1x. Guest and non-802.1x devices will authenticate via CWA. Meraki switches operate in a closed mode. In contrast to Meraki wireless networks, you do not have the ability to apply Meraki Group Policy during authentication. Optionally, you may configure a guest VLAN. This is useful in the event of authentication failure or for wired guest access to the network.
In this section, we first configure Policy Sets. Next, the Meraki access points and Cloud RADIUS Clients are added into the ISE deployment as network access devices. Then, configure an Authorization Profile for Employees, Contractors and Workstations. Configure allowed protocols for use in Authentication Policy. Finally, configure Authentication and Authorization Policy.
Note: To use Meraki LWA, you must add the Cloud Management Platform itself as a network access device (NAD). RADIUS requests from the Cloud Management Platform will come from one of four public IP addresses: 64.156.192.245, 64.156.192.68, 74.50.51.16, and 74.50.56.161. Create a NAD entry in ISE for each public IP address. Please check Meraki documentation to ensure those public addresses are still in use.
This procedure outlines the process necessary to tie ISE Authorization Policy to Group Policy on the Cisco Meraki access point. We will create several Authorizations Profiles for use in Authorization Policy. For Cisco Meraki networks that will not use a Group Policy, we use the prebuilt Authorization Profile PermitAccess in Authorization Policy.
Note: The Airespace ACL Name is the name of the group policy configured on the Meraki cloud controller (Figure 3) for use with ISE Authorization Profile. The Meraki cloud controller can be configured to look for 1 of 3 compatible RADIUS messages from Cisco ISE: Filter-ID, Airespace-ACL-Name and Reply-Message. This example uses Airespace-ACL-Name.
Note: This example uses PEAP-MSCHAPv2 as the protocol to 802.1X authentications. Be sure you understand the needs of clients on your network prior to enabling or disabling allowed protocols. Reference Figure 10 as an example configuration.
Status | Name | Description | Conditions |
|
Meraki | AAA for Meraki Infrastructure. | DEVICE:Device Type CONTAINS Device Type#All Device Types#meraki |
Note: You have the ability to reorder the policy set list by dragging them into order of preference. Reference Figure 11 as an example.
In addition to URL-Redirect and RADIUS CoA support, Meraki wireless networks now support RADIUS Service Type = Frame and Call Check. This allows us to reuse some of the default compound conditions in ISE to describe the type of authentications that occur. For LWA, we need to create conditions specific for that type of authentication.
Cisco Best Practice: Once configured, your Authentication Policy will look similar to Figure 12. If these rules are used in a production environment, be sure to set the Default rule to use DenyAccess as the identity store. In addition, you can configure an Identity Source Sequence for use with authenticating Active Directory users as well as guest users via LWA. Simply change the LWA rule to use the name of the Identity Source Sequence instead of Active Directory. See the ISE Administrators Guide for more information on Identity Source Sequences.
Note: Reference Figure 13 for an example Wired Authentication Rule.
Note: Reference Figure 14 for an example VPN Authentication Rule.
The Authentication Policy for Meraki devices is complete. The policy is sectioned into three parts: Wireless, Wired, and RA VPN. The wireless section has subsections that describe the authentication types for 802.1X, MAB, and LWA. The Wired an RA VPN subsections use a default rule that outlines with Identity Store to use during authentication. Reference Figure 15 as an example policy.
Name | Conditions (If) | Allowed Protocols | Identity Store (use) |
Wireless LWA | Radius:NAS-Port-Type EQUALS Wireless – IEEE 802.11 AND Radius: Service-Type EQUALS Login | Meraki | Internal Users |
Wireless Dot1x | Wireless_802.1X or Wired_802.1X | Meraki | ActiveDirectory |
Wireless MAB | Wireless_MAB or Wired_MAB | Meraki | Internal Endpoints |
Default | DenyAccess | ||
Wireless | Radius:NAS-Port-Type EQUALS Ethernet | Meraki | |
Default | ActiveDiretory | ||
RA VPN | Radius:NAS-Port-Type EQUALS Framed AND Radius:Framed-Protocol EQUALS PPP | Meraki | |
Default | ActiveDiretory | ||
Default (If no match) | Default Network Access and use: DenyAccess |
This section illustrates some example use cases for Central Web Authentication. CWA can be used with both wireless MAB and wireless 802.1X protected SSIDs on Cisco Meraki MR Access Points. The following steps show how to configure ISE Authorization Policy for the desired use case.
This example outlines the steps necessary to configure guest access using a click-through wireless guest portal. Once the guest user associates to the guest SSID, they are URL-redirected to the HotSpot guest portal. Depending on your portal configuration, the user must either accept an Acceptable Use Policy, enter a passcode, or other task prior to being allowed guest access.
This example outlines the steps necessary to configure self-registration guest access. Once the guest user associates to the guest SSID, they are URL-redirected to the self-registration guest portal. There, they are able to request guest credentials, receive them, and upon entering those guest credentials, be granted guest network access.
Similar to local web authentication, guest users in this scenario will require guest credentials be sent to them by a sponsor. These credentials can be issued using the Guest Sponsor portal in ISE. Once the guest has received the credentials, they can associate to the guest SSID where they will be URL-redirect to the guest sponsor portal. After entered their credentials into the guest portal, guest network access will be granted.
This example outlines the configuration steps necessary to enable BYOD registration. The employee first connects to an open system, or wireless MAB SSID, although an 802.1X protected SSID is also supported. The wireless guest network is typically used but a dedicated provisioning network can be used as well. The employee logs in to the portal using their Active Directory credentials, which begins the BYOD registration flow. Note that these steps only outline the steps necessary for Authorization Policy. Supplicant resources and policy should have already been configured for the supported mobile devices in the network which is out of the scope of this document. Please reference http://www.cisco.com/go/ise for more design guides and details.
The following configuration steps build on the BYOD enrollment example to include the registration of BYOD devices with Meraki SM. Employees with registered devices who connect to the 802.1X protected wireless network that are not enrolled in Meraki SM will be prompted to enroll their device. Once enrolled, employees will gain network access. Note, that these steps assume that ISE has been properly configured to communicate with Meraki Systems Manager (SM). For information on how to integrate Meraki SM with ISE for MDM use cases, reference the HowTo: Cisco Meraki EMM Integration with Cisco ISE.
This example outlines the steps necessary to configure Authorization Policy for posture assessment. Before instituting the below configuration, be sure that you have Client Provisioning policy and Posture Policy correctly configured for your desired use case.
These steps show how to authorize guest users using the Splash Page hosted on the Meraki Cloud Platform. When a user associates to the SSID, the Meraki Cloud Platform will redirect the user to the Splash Page prompting for a username and password. The end user enters the credentials sent via the ISE Sponsor portal and once validated via RADIUS to ISE, the user will gain guest access.
These steps show how to configure ISE Authorization policy for wired employee access using 802.1X as well as supporting wired guest users with the hotspot portal. Just like Meraki Wireless platforms, Meraki switches now support advanced use cases such as MDM enrollment, Native Supplicant Provisioning (BYOD) and posture assessment. Please see the wireless section for information on how to configure these advanced uses cases.
Note: Unlike Meraki wireless networks, VPN users cannot be assigned a group policy during authentication at the time of this writing. However, you can allow VPN access based upon the user’s Identity Store membership. Once configured, your new Authorization Policy should be similar to the figure 16.
Below is a table listing all of the configuration examples for use in Authorization Policy. This policy can be modified to fit your desired use cases regarding BYOD, MDM, Posture, and Guest Services. Some of these services, such as BYOD, MDM, and Posture can be configured to be independent of each other. Lastly, all three guest service types are outlined. As with the above, include only the relevant configuration for your security policy
Rule Name | Identity Group | Conditions | Permissions |
Wireless Dot1x Employee | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Employees ) | MerakiWirelessEmployees |
Wireless Dot1x Contractor | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Contractors ) | MerakiWirelessContractor |
Wireless BYOD Access | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Domain Users AND Endpoints:BYODRegistration EQUALS yes | MerakiWirelessEmployees |
Wireless BYOD Enrollment | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Domain Users AND Endpoints:BYODRegistration EQUALS no | MerakiNSP |
Wireless MDM_BYOD Access | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Domain Users AND Endpoints:BYODRegistration EQUALS yes AND MDM:DeviceRegisterStatus EQUALS yes | MearkiWirelessEmployees |
Wireless MDM Enroll | Any | Wireless_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Domain Users AND Endpoints:BYODRegistration EQUALS yes AND MDM:DeviceRegisterStatus EQUALS no | MerakiMDMEnrollment |
Wireless Posture Assessment | Any | Wireless_802.1X AND AD:ExternalGroups EQUALS domain/Users/Domain Users AND Session:PostureStatus EQUALs Unknown | MerakiPosture |
Wireless Posture Compliant | Any | Wireless_802.1X AND AD:ExternalGroups EQUALS domain/Users/Domain Users AND Session:PostureStatus EQUALs Compliant | MerakiWirelessEmployess |
Wireless Guest Access | GuestEndpoints | Wireless_MAB | MerakiWirelessGuest |
Wireless HotSpot | Any | Wireless_MAB | MerakiHotSpot |
Wireless Self-Reg Guest | Any | Wireless_MAB | MerakiSelfRegGuest |
Wireless Sponsor Guest | Any | Wireless_MAB | MerakiSponsorGuest |
Wireless LWA | Guest OR ActivedGuest | Radius:NAS-Port-Type EQUALS Wireless - IEEE 802.11 AND RADIUS:Service-Type EQUALS Login | PermitAccess |
Wired Guest | GuestEndpoints | Wired_MAB | MerakiWiredGuest |
Wired Dot1x | Any | Wired_802.1X AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Domain Users ) | PermitAccess |
Wired CWA | Any | Wired_MAB | MerakiHotSpot |
RA VPN | Any | Radius:NAS-Port-Type EQUALS Framed AND Radius:Framed-Protocol EQUALS PPP AND ActiveDirectory:ExternalGroups EQUALS ise.local/Users/Employees ) | PermitAccess |
RADIUS and DHCP profiling using Cisco Meraki wireless networking equipment is compatible with ISE but with limitations. While Cisco Meraki access points can dynamically profile wireless devices during authentication, that information cannot be shared with ISE for use with Authorization Policy. Cisco Meraki access points that are not able to forward DHCP requests. As such, a Catalyst 3560X was used during this configuration example for the ability to forward DHCP requests. RADIUS profiling with Cisco Meraki access points is supported via the calling-station-id attribute.
Cisco Meraki switches lack the ability to forward DHCP requests or run a DHCP server. In a network consisting of only Cisco Meraki equipment, only RADIUS profiling is possible with ISE via the calling-station-id attribute. The only device capable of running a DHCP server is the MX Security Appliance. However, like the Cisco Meraki access point, it does not have the ability forward DHCP requests.
In the document time-stamped June 2017 the compatibility matrix says posturing is supported but requires an Inline Posture Node. Support for IPN was dropped as of ISE 2.0 AFAIK and earlier versions of ISE are End of Sale. There is no current version of ISE that supports IPN. Is posture supported with ISE 2 or later? How?
Posture is supported for MS and MR platforms.
Regards,
-Tim
Thanks Tim. So perhaps remove the IPN requirement from the Matrix? My understanding is IPN is not mandatory and ISE 2+ has dropped support for IPN
Agree with Jerome here. Had just been working on a customer query where the customer was not sure if MS and MR supported Posture, however, looking at Tim's response I have just confirmed it to the customer that it does. I guess having this reflected in the compatibility matrix will help a lot. Many thanks/Abhi
If we have FirePower and ISE integrated through pxGrid, can we implement Adaptive Network Contorl on ISE and send enforcement instructions to a Meraki LAN and/or WLAN?
I know ANC isn't support with 'none Cisco' networks, but where does Meraki sit in this?
Thanks,
Richard
Richard, ISE would ultimately issue a RADIUS Change of Authorization (COA) to the network device for an ANC action.
According to the ISE Compatibility Guides, both Meraki switching and wireless support RADIUS COA.
See ISE Design & Integration Guides > Cisco Meraki for all of your integration needs.
And since you asked, non-Cisco network devices we would do the same assuming that they too support RADIUS COA. For the really old and dumb ones, we could even use SNMP to change the authorization. For more about this, see ISE Third-Party NAD Profiles and Configs .
We have a profiling issue. Our Apple MAC Books are profiled as Apple Devices, so do our iPhones/iPads, can you please shed some light how do we profile these devices accurately. Radius Probes aren't enough. Our Windows devices are profiled as Intel devices. Appreciate if you could give me a fix.
Would suggest you open a new thread so not to clutter up the how-to posting
Not really replying as this thread is dated - has anybody had issues when a the end-user device is a Surface Pro with WIN10? I have an issue whereas if I turn off 802.1x as a condition of my ISE policy, everything works. If I use 802.1x, the users cannot log on. Oddest thing.
Ken please post a new community post with your issue instead of dragging on something on a document post
Is this up to date currently?
Tim's latest revision is 8 months old only so should be fairly current. If you have a specific question, please create it as a new discussion, as Jason suggested. Please also review the documents by Meraki, such as:
Hi , one question currently I have a set up in which Meraki AP is connected to the cisco 35XX switch and some test cases are working fine (AP is configured and added to ISE), now the requirement is to unplug that AP from 35xx and connect to a Meraki switch (this switch is also added to the ISE), my question is what we need to configure on that specific port of the meraki switch where we will connect AP, can you help me with the configuration and do we need to reconfigure the AP?
Hi Guys,
Few questions on Meraki profiling support for wireless and wired.
In the Cisco ISE compatibility matrix, it is mentioned that Meraki Wireless & Wired devices support full Profiling.
But in this document, it shows it only supports Radius calling station-id attribute ?? Hence i wanted to ask here if Meraki Wireless & Wired support other probes like DHCP, SNMP, etc or only Radius calling station-id attribute.
One last question, does Meraki wireless support critical vlan/guest vlan which is supported on Meraki wired ??
Thank you
Shivaprasad Gudsi
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: