Meraki and ISE profiling

[AIN UL BADAR]

We have a profiling issue with ISE 2.3. Our Apple MAC Books, iPads and iPhones ALL are profiled as Apple Devices, can you please shed some light how do we profile these devices accurately. Our Windows devices are profiled as Intel devices. We are using Radius probes, and it turns out to be Not enough.  Appreciate if you could give me a fix.

Used this document as a reference.

How To: Integrate Meraki Networks with ISE

[ldanny · Accepted solution]

For your reference ISE profiling design guide.

How To: ISE Profiling Design Guide

[Craig Hyps]

Meraki access devices do not support Device Sensor so cannot get detailed attributes via RADIUS Accounting.  RADIUS alone will provide minimal data, such as MAC address (OUI).  To get additional data, see if possible to send DHCP info to ISE via IP helper and alternatively SPAN.  RADIUS Accounting and DHCP can also populate the IP address used for other probes such as DNS and NMAP.  It is also possible for ISE to use SNMP to query access device or L3 gateways for useful data.  HTTP can also be acquired via web redirection flows to ISE or alternatively via SPAN.

AD probe is also useful for Windows clients, but will require 802.1X machine auth, DHCP, or DNS to perform the AD lookup.

[AIN UL BADAR]

Thanks Craig, but based on the document and experience with Meraki, I can't get endpoints to profile accurately. Here is the snippet from the Meraki ISE integration document.

Page 36.

How To: Integrate Meraki Networks with ISE

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.

[Timothy Abbott]

In the document, the Meraki access points were configured in bridge mode so that DHCP in addition to RADIUS information could be sent to ISE.  ISE needs additional information beside the OUI to determine what the device is.  Like Craig said, try forwarding DHCP requests which will further assist ISE in matching a more granular profile policy.

Regards,

-Tim

[AIN UL BADAR]

Thanks Tim.

I'll see what mode we have configured for Meraki.

Regards,

Ain

[hslai]

In one project I worked on involving Meraki gears, we configured the DHCP settings on the security appliances like below, where 10.1.100.100 is the real DHCP server and 10.1.100.21 is the ISE. This way ISE can get a copy of the DHCP requests.

We've also tried mirroring the client traffic to a wired switch port that connect to another ISE interface and ISE able to collect DHCP and HTTP that way.

[Taylor Cook]

I am facing this same problem now, but on the Z3 appliances which do not allow for DHCP relay configuration.  My scenario is that I need to be able to identify when a domain-joined device connects to the Meraki Z3 appliance vs a personal laptop so that I can provide access accordingly.  Since there are no additional DHCP values or RADIUS attributes shared with ISE during the initial connection (and Z3-hosted splash page), ISE only records the system as a generic "Dell-Device".  This profile is selected because of the lack of information learned from the RADIUS authentication message and therefore I don't have an ability to determine if it is a corporate asset or a personal device.

If I can at least get the hostname information in the RADIUS request, that should be enough for me to perform an AD lookup of that hostname object in Active Directory, and therefore be able to determine if the device is joined to the domain or not.

Any ideas?

[cjjones]

Adding the PSN to the ip helper list on the SVI fixed this problem I was only seeing with raspberry pi devices. DHCP is working full circle now for all of our devices!