How To: Integrate Meraki Networks with ISE

[thomas]

Authors: Tim Abbott, Alex Burger, Victor Cho, Tony Carmichael

Table of Contents

• Introduction
• Capability Matrix
• Overview
• Components
• Network Diagram
• Meraki Wireless Network Configuration
• Configure Meraki Wireless Group Policy
• Add ISE as a RADIUS Server for Dot1x SSID
• Add ISE as a RADIUS Server for Guest SSID
• Add ISE as a RADIUS Server for Wireless MAB SSID
• Meraki Wired Network Configuration
• Add ISE as a RADIUS Server for Wired 802.1X
• Apply Access Policy to Switch Ports
• Meraki VPN Network Configuration
• Configure Client VPN Access
• ISE Configuration
• Enable Policy Sets
• Add Meraki Access Point as a Network Access Devices
• Add Meraki Switch as a Network Access Device
• Add Meraki Security Appliance as a Network Access Device
• Add Meraki Cloud RADIUS Clients as Network Access Devices
• Authorization Profiles
• Allowed Protocols
• ISE AAA Configuration
• Wireless Authentication Rule
• Wireless 802.1X Authentication
• Wireless MAB Authentication
• Wireless Local Web Authentication
• Wired 802.1X Authentication Rule
• Wired MAB Authentication Rule
• RA VPN Authentication Rule
• Wireless 802.1X Authorization
• Central Web Authentication (CWA) Examples
• Wireless LWA Authorization
• Wired Authorization Policy[2]
• RA VPN Authorization
• Profiling Considerations
• Wireless Network Profiling
• Wired Network Profiling

Introduction

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:

Capability Matrix

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	-	-	-	-	-	-	-	-

Overview

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  

Components

• Cisco ISE 1.3 or later
• Cisco Meraki MS 350-48
• Cisco Meraki MR42 Access Point
• Cisco Meraki MS350-24X Switch
• Cisco Meraki MX100 Security Appliance
• Cisco Meraki Cloud Management Platform
• Microsoft Active Directory 2012 R2

Network Diagram

Meraki Wireless Network Configuration

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.

Configure Meraki Wireless Group Policy

1. Select the wireless network for use with ISE from the Network: drop down menu.
2. Select Configure ➔ Group policies in the Meraki dashboard.
3. Select Add a group.
4. Name the group policy Employee.
5. If needed, configure any group policy settings. Leave Splash as Use SSID Default.
6. Click Save Changes.
7. Repeat steps 1 through 6 for the Contractor Group Policy.
8. Repeat steps 1 through 6 for the Guest Group Policy.
9. Repeat steps 1 through 6 for the Workstation Group Policy.

Add ISE as a RADIUS Server for Dot1x 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.

1. Under the Configure menu in the Meraki dashboard, select Access control.
2. Select the SSID from the drop-down menu that is used by the Employee Identity Group.
3. Ensure the WPA2-Enterprise radio button is selected along with my RADIUS server in the drop-down menu.
4. Select Cisco Identity Services Engine (ISE) Authentication.
5. In the RADIUS servers field, enter the IP address, port 1812 and secret of the ISE policy service nodes.
6. Disable RADIUS testing.
7. Enable RADIUS accounting.
8. In the RADIUS accounting field, enter the IP address, port 1813 and secret of the ISE policy service nodes.
9. In the RADIUS attribute specifying group policy name field, select Airespace-ACL-Name.
10. Ensure that Assign group policies by device type is disabled.
11. Ensure that Walled garden is enabled, then add DNS and ISE policy service nodes.
12. Select Bridge mode for Client IP Assignment.
13. Set the VLAN tagging option to Don’t use VLAN tagging.
14. Click Save Changes to complete the configuration of the SSID.  Refer to figure 3 for an example.

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

Add ISE as a RADIUS Server for Guest SSID

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.

1. Under the Configure menu in the Meraki dashboard, select Access control.
2. Select the SSID from the drop-down menu that will be used by the Guest Identity Group.
3. Ensure the Open (no encryption) radio button is selected for Association Requirements.
4. Select Single sign-on for Splash Page and ensure my RADIUS server is selected from the drop-down menu.
5. Under RADIUS for splash page, enter the publicly reachable IP address, port 1812 and secret of the ISE policy service node.
6. Ensure that Assign group policies by device type is disabled.
7. Select Bridge mode for Client IP Assignment.
8. Set the VLAN tagging option to Use VLAN tagging.
9. Under VLAN ID, select Add VLAN.
10. Enter the AP Tag name for the Guest VLAN ID.
11. For RADIUS override, select Ignore VLAN attribute in RADIUS responses.
12. Click Save Changes to complete the configuration of the SSID.  Refer to figure 4 for an example.

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

Add ISE as a RADIUS Server for Wireless MAB SSID

1. Under the Configure menu in the Meraki dashboard, select Access control.
2. Select the SSID from the drop-down menu that will be used by the Workstation Identity Group.
3. Ensure the MAC-based access control (no encryption) radio button is selected for Association Requirements.
4. Select Cisco Identity Services Engine (ISE) Authentication for Splash Page.
5. In the RADIUS servers field, enter the IP address, port 1812 and secret of the ISE policy service nodes.
6. Disable RADIUS testing.
7. Ensure RADIUS CoA support is enabled.
8. In the RADIUS accounting field, enter the IP address, port 1813 and secret of the ISE policy service nodes.
9. In the RADIUS attribute specifying group policy name field, select Airespace-ACL-Name.
10. Ensure that Assign group policies by device type is disabled.
11. Ensure Walled garden is enabled and enter the IP addresses for your DNS and PSN servers
12. Select Bridge mode for Client IP Assignment.
13. Set the VLAN tagging option to Use VLAN tagging.
14. Under VLAN ID, select Add VLAN.
15. Enter the AP Tag name for the Workstation VLAN ID.
16. For RADIUS override, select Ignore VLAN attribute in RADIUS responses.
17. Click Save Changes to complete the configuration of the SSID.  Refer to figure 5 for an example.

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

Meraki Wired Network Configuration

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.

Add ISE as a RADIUS Server for Wired 802.1X

1. Select the wired network for use with ISE from the Network: drop down menu.
2. Under the Configure menu in the Meraki dashboard, select Access policies.
3. Select Add an access policy.
4. Give the new policy a name. (For example, ISE-HYBRID).
5. In the Host field, enter the IP address of the ISE node.
6. In the Port field, enter 1812.
7. In the secret field, enter the shared secret.
8. Set RADIUS testing to RADIUS testing disabled.
9. Ensure RADIUS CoA is enabled.
10. Ensure RADIUS Accounting is enabled.
11. Enter the IP address, port, and shared secret of the ISE node in the accounting server field.
12. Set RADIUS attribute specifying group policy name to Filter-ID
13. Select the Host Mode type.
14. Set Access Policy Type to hybrid authentication.
15. If desired, enter the Guest VLAN for use when users fail 802.1X authentication.
16. Click Save.

Apply Access Policy to Switch Ports

1. Select Configure ➔ Switch ports.
2. Select the desired switch ports to apply the Access policy.
3. In the Access policy drop down menu, select the name of the Access Policy (For example, ISE-HYBRID).
4. Click Update 1 port.
5. Repeat steps 1 through 4 for each port intended to use this Access Policy.

Meraki VPN Network Configuration

Configure Client VPN Access

1. Select the VPN network for use with ISE from the Network: drop down menu.
2. Select Configure ➔ Client VPN in the Meraki dashboard.
3. Set the Client VPN Server to Enabled.
4. Enter a subnet that VPN Clients will use. (For example, 192.168.111.0/24)
5. Select Specify name servers… from the DNS name servers drop down menu.
6. Enter the IP address(s) of internal DNS servers.
7. Specify a secret that users will need to configure a L2TP over VPN client.
8. From the Authentication drop down menu, select RADIUS.
9. Click Add RADIUS server.
10. Enter the IP address, Port and Shared Secret for the ISE node.
11. Click Save.

ISE Configuration

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.

Enable Policy Sets

1. Navigate to Administration ➔ Settings ➔ Policy Sets.
2. Click Enabled.
3. Click Save.

Add Meraki Access Point as a Network Access Devices

1. Navigate to Administration ➔ Network Devices.
2. Click Add to create a new network device.
3. Enter a name for the Cisco Meraki access point.
4. Enter the IP address of the access point.
5. Define the Device Type and Location of the access point.
   Cisco Best Practice:  Predefined Device Type and Location in the Network Device Groups menu. Putting all Meraki access points in a unique Device Type group will allow you to reference them in authentication and authorization policy later.
6. Check the box for Authentication Settings and enter the shared secret.
7. Click Submit.
8. Repeat steps 1 through 7 for additional Meraki access points that will be used in the ISE deployment.
   Note: You have the ability to bulk import network access devices. Simply click on “Import” and then “generate a template.” Be sure to fill out all the required fields in the CSV template prior to uploading to ISE.

Add Meraki Switch as a Network Access Device

1. Click Add to create a new network device.
2. Enter a name for the Cisco Meraki switch.
3. Enter the IP address of the switch.
4. Define the Device Type and Location of the access point.
5. Check the box for Authentication Settings and enter the shared secret.
6. Click Submit.

Add Meraki Security Appliance as a Network Access Device

1. Click Add to create a new network device.
2. Enter a name for the Cisco Meraki security appliance.
3. Enter the IP address for the access point.
4. Define the Device Type and Location of the access point.
5. Check the box for Authentication Settings and enter the shared secret.
6. Click Submit.

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.

Add Meraki Cloud RADIUS Clients as Network Access Devices

1. Navigate to Administration ➔ Network Devices.
2. Click Add to create a new network device.
3. Enter a name for the Meraki access point.
4. Enter one of the IP addresses for the Cloud RADIUS client.
5. Define the Device Type and Location of the access point.
6. Check the box for Authentication Settings and enter the shared secret.
7. Click Submit.
8. Repeat steps 1 through 7 for the remaining three Cloud RADIUS Clients.

Authorization Profiles

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.

1. Navigate to Policy ➔ Results ➔ Authorization ➔ Authorization Profiles.
2. Click Add to create a new Authorization Profile.
3. Name the Authorization Profile MerakiWirelessEmployee and leave the access type set to Access_Accept.
4. Under Common Tasks, Check the box for Airespace ACL Name and enter Employee.
5. Click Submit to save the new Authorization Profile.
6. Repeat steps 1 through 5 and name the profile MerakiWirelessContractor and use Contractor for the Airespace ACL Name.
7. Repeat steps 1 through 5 and name the profile MerakiWirelessWorkstation and use Workstation for the Airespace ACL Name.
8. Repeat steps 1 through 5 and name the profile MerakiWirelessGuest and use Guest for the Airespace ACL Name.
9. Repeat steps 1 though 5 and name the profile MerakiWiredGuest and do not assign an ACL but assign the guest VLAN.
10. Click Add to create a new Authorization Profile.
11. Name the Authorization Profile MerakiHotSpot.
12. Under Common Tasks, Check the box for Web Redirection and select HotSpot and the HotSpot guest portal from the drop-down menus. Enter CWA as the redirect ACL.
13. Click Submit to save the new Authorization Profile.
14. Repeat steps 9 through 12, name the profile MerakiMDMEnrollment, and select MDM Redirect and MDM Portal from the drop-down menus.  Enter CWA as the redirect ACL.
15. Repeat steps 9 through 12, name the profile MerakiNSP, and select Native Supplicant Provisioning and BYOD Portal from the drop-down menus. Enter CWA as the redirect ACL.
16. Repeat steps 9 through 12, name the profile MerakiGuestRedirect, and select Central Web Auth and Self-Registered Guest Portal from the drop-down menus. Enter CWA as the redirect ACL.
17. Repeat steps 9 through 12, name the profile MerakiPosture, and select Client Provisioning (Posture) and Client Provisioning Portal from the drop-down menus. Enter CWA as the redirect ACL.

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.

Allowed Protocols

1. Navigate to Policy ➔ Results ➔ Authentication ➔ Allowed Protocols.
2. Click Add.
3. Enter a name for the new allowed protocols list. (For example, Meraki)
4. Check the box for Allow PAP/ASCII.
5. Under Allow PAP/ASCII, check the box for Detect PAP as Host Lookup.
6. Check the box for Allow PEAP and under Inner Methods check Allow PEAP-MSCHAPv2.
7. Click Submit.

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.

ISE AAA Configuration

1. Navigate to Policy ➔ Policy Sets.
2. Create a new Policy Set by clicking the green then Create Above.
3. Click Edit to customize the Policy Set rule.
4. Enter and Name and Description (optional) for the Policy Set rule.
5. Click the in the conditions box and select Create New Condition (Advanced Option).
6. Navigate to Select Attribute ➔ DEVICE Device Type.
7. Change the operator drop-down from EQUALS to CONTAINS.
8. Select the Device Type group defined earlier in this guide that contains all Meraki devices that apply to the new Policy Set.  Reference Figure 5 as an example.
9. Click Done on the right side of the policy set rule.
10. Click Submit.

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.

Wireless Authentication Rule

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.

Wireless 802.1X Authentication

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule.  Example:  Wireless 802.1X.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select Existing Condition from Library.
5. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
6. For allowed protocols, selects Meraki.
7. In the Use field, select ActiveDirectory as the identity store.
8. Click Save.

Wireless MAB Authentication

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule.  Example:  Wireless MAB.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select Existing Condition from Library.
5. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
6. For allowed protocols, select Meraki.
7. In the Use field, select Internal Endpoints as the identity store.
8. Under Options: If user not found, select Continue.
9. Click Save.

Wireless Local Web Authentication

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule. Example:  Wireless LWA.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select the attribute RADIUS ➔ NAS-Port-Type.
5. Leave the operator box set to EQUALS.
6. In the last drop-down box, select Wireless - IEEE 802.11.
7. Click the down arrow next to the gear icon and select Add Attribute/Value.
8. Select RADIUS Service-Type.
9. Leave the operator box set to EQUALS.
10. In the last box select Login.
11. For allowed protocols, select Meraki.
12. In the “Use:” field, select Internal Users as the identity store.
13. Click Save.

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.

Wired 802.1X Authentication Rule

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule.  Example:  Wired 802.1X.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select Existing Condition from Library.
5. Select Select Condition ➔ Compound Condition ➔ Wired_802.1X.
6. For allowed protocols, selects Meraki.
7. In the Use field, select ActiveDirectory as the identity store.
8. Click Save.

Note:  Reference Figure 13 for an example Wired Authentication Rule. 

Wired MAB Authentication Rule

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule.  Example:  Wired MAB.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select Existing Condition from Library.
5. Select Select Condition ➔ Compound Condition ➔ Wired_MAB.
6. For allowed protocols, select Meraki.
7. In the Use field, select Internal Endpoints as the identity store.
8. Under Options: If user not found, select Continue.
9. Click Save.
10. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
11. Enter a name for the new rule.  Example:  RA VPN.
12. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
13. Select the attribute RADIUS  NAS-Port-Type.
14. Leave the operator box set to EQUALS.
15. In the last drop-down box, select Framed.
16. Add a new Attribute/Value by selecting the gear icon.
17. Select attribute RADIUS  Framed-Protocol.
18. Change the EQUALS operator to EQUALS.
19. In the last drop-down box, select PPP.
20. For Allowed Protocols, select the profile previously configured (Example: meraki).
21. Click the in the Use field and select ActiveDirectory.
22. Click Done and save then Save.

RA VPN Authentication Rule

1. Create a new Authentication Policy rule by clicking the down arrow next to Edit and select Insert New Rule Above.
2. Enter a name for the new rule.  Example:  RA VPN.
3. Click the in the conditions field to access the drop-down menu and select Create New Condition (Advanced Option).
4. Select the attribute RADIUS  NAS-Port-Type.
5. Leave the operator box set to EQUALS.
6. In the last drop-down box, select Framed.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select attribute RADIUS  Framed-Protocol.
9. Change the EQUALS operator to EQUALS.
10. In the last drop-down box, select PPP.
11. For Allowed Protocols, select the profile previously configured (Example: meraki).
12. Click the in the Use field and select ActiveDirectory.
13. Click Done and save then Save.

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

Wireless 802.1X Authorization

1. Navigated to Policy  Policy Sets.
2. Click the down arrow in the default authorization rule and select Insert new rule above. Note:  ISE Authorization rules are matched from top to bottom with the first matched rule being selected.
3. Enter a name for the new Authorization Rule. Example:  Wireless Dot1x.
4. Leave the Identity Group field to Any then click the in the Condition(s) field.
5. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
6. Add a new Attribute/Value by selecting the gear icon.
7. Select attribute  Active Directory  ExternalGroups and select Employees.
8. Click the in the field for Permissions.
9. Click Select an item  Standard MerakiWirelessEmployees.
10. Click Save.
11. Repeat steps 1 through 15 and select Contractors for the AD group and MerakiWirelessContractors as the Authorization Profile.

Central Web Authentication (CWA) Examples

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.

HotSpot Example

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.

1. Click the down arrow in the default authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule.  Example:  Wireless HotSpot.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
5. Click the in the field for Permissions.
6. Click Select an item ➔ Standard ➔ MerakiHotSpot.
7. Click Save.
8. Click the down arrow in the Wireless HotSpot authorization rule and select Insert new rule above.
9. Enter a name for the new Authorization Rule. Example:  Wireless Guest Access.
10. In the Identity Group field, select GuestEndpoints then click the in the Condition(s) field.
11. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
12. Click the in the field for Permissions.
13. Click Select an item ➔ Standard ➔ MerakiWirelessGuest.
14. Click Save.

Self-Registered Guest Example

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.

1. Click the down arrow in the default authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule. Example:  Wireless Self-Reg Guest.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
5. Click the in the field for Permissions.
6. Click Select an item ➔ Standard ➔ MerakiSelfRegGuest.
7. Click Save.
8. Click the down arrow in the Wireless HotSpot authorization rule and select Insert new rule above.
9. Enter a name for the new Authorization Rule. Example:  Wireless Guest Access.
10. In the Identity Group field, select GuestEndpoints then click the in the Condition(s) field.
11. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
12. Click the in the field for Permissions.
13. Click Select an item ➔ Standard ➔ MerakiWirelessGuest.
14. Click Save.

Sponsored Guest Example

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.

1. Click the down arrow in the default authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule. Example:  Wireless Sponsored Guest.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
5. Click the in the field for Permissions.
6. Click Select an item ➔ Standard ➔ MerakiSponsoredGuest.
7. Click Save.
8. Click the down arrow in the Wireless HotSpot authorization rule and select Insert new rule above.
9. Enter a name for the new Authorization Rule. Example:  Wireless Guest Access.
10. In the Identity Group field, select GuestEndpoints then click the in the Condition(s) field.
11. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
12. Click the in the field for Permissions.
13. Click Select an item ➔ Standard ➔ MerakiWirelessGuest.
14. Click Save.

BYOD Enrollment Example

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.

1. Click the down arrow in the Wireless Guest Access authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule. Example:  Wireless BYOD Enrollment.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_MAB.
5. Add a new Attribute/Value by selecting the gear icon.
6. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select Endpoints:BYODRegistration EQUALS no.
9. Click the in the field for Permissions.
10. Click Select an item ➔ Standard ➔ MerakiNSP.
11. Click Save.
12. Click the down arrow in the Wireless BYOD Enrollment authorization rule and select Insert new rule above.
13. Enter a name for the new Authorization Rule. Example:  Wireless BYOD Access.
14. In the Identity Group field, select Any then click the in the Condition(s) field.
15. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
16. Add a new Attribute/Value by selecting the gear icon.
17. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
18. Add a new Attribute/Value by selecting the gear icon.
19. Select Endpoints:BYODRegistration EQUALS yes.
20. Click the in the field for Permissions.
21. Click Select an item ➔ Standard ➔ MerakiWirelessEmployees.
22. Click Save.

MDM Enrollment Example

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.

1. Click the down arrow in the Wireless Guest Access authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule. Example:  Wireless MDM Enrollment.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
5. Add a new Attribute/Value by selecting the gear icon.
6. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select Endpoints:BYODRegistration EQUALS yes.
9. Add a new Attribute/Value by selecting the gear icon.
10. Select MDM:DeviceRegisterStatus EQUALS no.
11. Click the in the field for Permissions.
12. Click Select an item ➔ Standard ➔ MerakiMDMEnrollment.
13. Click Save.
14. Click the down arrow in the Wireless MDM Enrollment authorization rule and select Insert new rule above.
15. Enter a name for the new Authorization Rule. Example:  Wireless BYOD_MDM Access.
16. In the Identity Group field, select Any then click the in the Condition(s) field.
17. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
18. Add a new Attribute/Value by selecting the gear icon.
19. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
20. Add a new Attribute/Value by selecting the gear icon.
21. Select Endpoints:BYODRegistration EQUALS yes.
22. Add a new Attribute/Value by selecting the gear icon.
23. Select MDM:DeviceRegisterStatus EQUALS yes.
24. Click the in the field for Permissions.
25. Click Select an item ➔ Standard ➔ MerakiWirelessEmployees.
26. Click Save.

Posture Assessment Example

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.

1. Click the down arrow in the Wireless Guest Access authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule. Example:  Wireless Posture Assessment.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
5. Add a new Attribute/Value by selecting the gear icon.
6. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select Session:PostureStatus EQUALS Unknown.
9. Click the in the field for Permissions.
10. Click Select an item ➔ Standard ➔ MerakiPosture.
11. Click Save.
12. Click the down arrow in the Wireless Posture Assessment authorization rule and select Insert new rule above.
13. Enter a name for the new Authorization Rule. Example:  Wireless Posture Compliant.
14. In the Identity Group field, select Any then click the in the Condition(s) field.
15. Select Select Condition ➔ Compound Condition ➔ Wireless_802.1X.
16. Add a new Attribute/Value by selecting the gear icon.
17. Select attribute AD:ExternalGroups EQUALS domain/Users/Domain Users.
18. Add a new Attribute/Value by selecting the gear icon.
19. Select Session:PostureStatus EQUALS Compliant.
20. Click the in the field for Permissions.
21. Click Select an item ➔ Standard ➔ MerakiWirelessEmployees.
22. Click Save.

Wireless LWA Authorization

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.

1. Click the down arrow in the default authorization rule and select Insert new rule above.
2. Enter a name for the new Authorization Rule.  Example:  Wireless LWA.
3. In the Identity Field, click the and select User Identity Groups  Guest.
4. Click the again and select User Identity Groups  ActivatedGuest.
5. Select Create New Condition (Advanced Option).
6. Select attribute Radius  NAS-Port-Type Wireless-IEEE 802.11.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select RADIUS Service-Type.
9. Leave the operator box set to EQUALS.
10. In the last box select Login.
11. Click the in the field for Permissions.
12. Click Select an item  Standard MerakiWirelessGuest.
13. Click Save.

Wired Authorization Policy[2]

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.

1. Click the down arrow in the default authorization rule and select Insert new rule above. Note:  ISE Authorization rules are matched from top to bottom with the first matched rule being selected.
2. Enter a name for the new Authorization Rule.  Example:  Wired Dot1x.
3. Leave the Identity Group field to Any then click the in the Condition(s) field.
4. Select Select Existing Condition from Library.
5. Click the down arrow and then select Compound Conditions.
6. Select Wired_802.1X.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select attribute  Active Directory  ExternalGroups and select the Employees.
9. Click the in the field for Permissions.
10. Click Select an item  Standard PermitAccess.
11. Click Save.
12. Click the down arrow in the Wired Dot1x rule and select Insert new rule below.
13. Enter a name for the new Authorization Rule.  Example:  Wired CWA.
14. Leave the Identity Group field to Any then click the in the Condition(s) field.
15. Select Select Existing Condition from Library.
16. Click the down arrow and then select Compound Conditions.
17. Select Wired_MAB.
18. Click the in the field for Permissions.
19. Click Select an item ➔ Standard ➔ MerakiHotSpot.
20. Click Save.
21. Click the down arrow in the default authorization rule and select Insert new rule above.
22. Enter a name for the new Authorization Rule.  Example:  Wired Guest.
23. Leave the Identity Group field to Any then click the in the Condition(s) field.
24. Select Select Existing Condition from Library.
25. Click the down arrow and then select Compound Conditions.
26. Select Wired_802.1X.
27. Click the in the field for Permissions.
28. Click Select an item ➔ Standard ➔ MerakiWiredGuest.
29. Click Save.

RA VPN Authorization

1. Navigated to Policy  Policy Sets.
2. Click the down arrow in the default authorization rule and select Insert new rule above.
3. Enter a name for the new Authorization Rule. Example:  RA VPN.
4. Leave the Identity Group field to Any then click the in the Condition(s) field.
5. Select Create New Condition (Advanced Option).
6. Select attribute Radius  NAS-Port-Type Framed.
7. Add a new Attribute/Value by selecting the gear icon.
8. Select attribute Radius  Framed-Protocol.
9. Change the EQUALS operator to EQUALS.
10. In the last drop-down box, select PPP.
11. Add a new Attribute/Value by selecting the gear icon.
12. Select attribute  Active Directory  ExternalGroups and select Employees.
13. Click the in the field for Permissions.
14. Click Select an item  Standard MerakiWirelessEmployees.
15. Click Save.

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

Profiling Considerations

Wireless Network Profiling

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.

Wired Network Profiling

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.

[Erik Witkop]

This is a great document, Tim. Can we do posture with AC 4.x and Meraki wireless?

[Timothy Abbott]

Erik,

Your Meraki network needs to have the open beta software that includes support for RADIUS CoA and URL-Redirect with SessionID.  If you do, then yes you can do posture assessment with Meraki wireless.

Regards,

-Tim

[guillermoochoa]

Hi Tim, do you know a date for this services to be available on the latest version and not in beta version?

Regards!

[mhaarala]

Is this document still up-to-date regarding ISE 2.1 & latest feature add-ons to Meraki?

[thomas]

This is still the latest but does not include the latest updates for the MS switching line announced a couple of weeks ago. Tim has an update in the works but he's out in London this week training people on ISE. Should be updated soon!

[gamccall]

Any word on MX support for CoA? Anchoring guest traffic to DMZ vs NAC is not a good tradeoff; I need both.

[Timothy Abbott]

Gabriel,

You'll need to reach out to the Meraki team for that information.  We aren't permitted to discuss roadmap items in this forum.

Regards,

-Tim

[antienho]

ISE released 2.2 now, Is there an update with ISE 2.2?

Thanks

Antien Ho

[Timothy Abbott]

An update to the guide is currently being worked on.

Regards,

-Tim

[nkingsbury]

Great write up Tim and Colin. Would you happen to know if something like this can work with the Meraki Z1 Teleworker devices?

[Timothy Abbott]

Hi Nathan,

Unfortunately, I don't have any experience with those devices so I couldn't tell you for sure.  Best way to find out is to put the two in a lab.

Regards,

-Tim

[gbekmezi-DD]

The Z1s are essentially the same as MX devices but they have wireless and their physical ports don’t do 802.1x :(. Are you thinking of ISE for wired or wireless endpoints on the Z1?

[nkingsbury]

I am trying to configure this for wireless, though I may need to try to set

it up on the ports at some point as well.

I am pretty close at this point with much help from this guide. I can successfully test RADIUS connection from the Z1 Wireless Settings tab, but I just tested connecting to the SSID

on the Z1 and it passed my computers credentials details, such as EndpointID and NAS IPv4, rather than the Z1's, so it fails with "Cannot locate AAA or Network Device" since the laptop it self is not a known network device.

Am I: wrong in assuming that the Z1's info should be whats being passed to the ISE as the network access device?

[yuyamagi]

How about an update for ISE 2.2 ?

Thanks,

Yuka

[Jason Kunst]

Why?

The integration required meraki to make changes to their software using ise conventions

There is no change on the ise side of things, besides some minor screen look and feel that's all that might have changed and this doesn't warrant a new doc