topic ISE 2.3, C3PL, and DHCP profiling in Network Access Control

ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Thu, 26 Oct 2017 14:03:22 GMT

I am starting a deployment using the following:

Cisco ISE 2.3 with Patch 1 (updated patch)
Cisco 3850 with 03.07.05E
- C3PL is enabled

Device sensors are being used on the switch for profiling. Only HTTP, RADIUS, and Active Directory profiling is enabled on the PSNs. The device sensor configuration is as follows:

ip dhcp snooping

ip dhcp snooping vlan [comma-separated list of VLANs]

device-sensor filter-list dhcp list dhcp_list

option name host-name

option name requested-address

option name parameter-request-list

option name class-identifier

option name client-identifier

device-sensor filter-spec dhcp include list dhcp_list

cdp run

device-sensor filter-list cdp list cdp_list

tlv name device-name

tlv name address-type

tlv name capabilities-type

tlv name platform-type

device-sensor filter-spec cdp include list cdp_list

lldp run

device-sensor filter-list lldp list lldp_list

tlv name system-name

tlv name system-description

tlv name system-capabilities

device-sensor filter-spec lldp include list lldp_list

device-sensor notify all-changes

access-session attributes filter-list list sensor_list

cdp

lldp

dhcp

access-session accounting attributes filter-spec include list sensor_list

When I do a show device-sensor cache interface gi1/0/3 (Macbook Pro w/ OSX Sierra connected), I get the following details:

DHCP 12:host-name 11 0C 09 42 72 61 64 73 2D 4D 42 50

DHCP 50:requested-address 6 32 04 0A 4A 6C 3A

DHCP 61:client-identifier 9 3D 07 01 98 5A EB CD B8 B5

DHCP 55:parameter-request-list 12 37 0A 01 79 03 06 0F 77 FC 5F 2C 2E

In the ISE Context Visibility > Endpoints list, the laptop only shows up as Apple-Device based on the MAC OU. Nothing is hitting on the Workstation profile list. I suspect it is because IP:User-Agent isn't being processed. The same issue happens with a Windows 7 laptop. It is only seen as a Microsoft-Device and never a Windows workstation (or the specific Windows version). When I click on the details of the endpoint in Context Visibility, I do see dhcp-parameter-request-list and dhcp-requested-address in the list of attributes received along with the endpoint source being RADIUS Probe.

This is not an issue with CDP profiling. The test IP phone, a Cisco 7961, is profiled correctly almost immediately.

Am I missing something in the device sensor configuration? I have used a similar (not exactly the same) device sensor config in other deployments but they were not using the new style authentication without C3PL enabled. One of the old styles was using the command no macro auto monitor to disable the local device analyzer but I didn't find a similar command for the new style configuration. Not sure if that can cause an issue.

Re: ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Thu, 26 Oct 2017 17:48:44 GMT

I just double checked the device sensor cache. For the port the IP phone is connected to, the cache is showing DHCP class identifier information (DHCP option 60). The port where the Macbook is connected is not showing DHCP class identifier information.

Re: ISE 2.3, C3PL, and DHCP profiling

Craig Hyps — Thu, 26 Oct 2017 18:27:30 GMT

Not all Macbooks will populate Class ID and there is no default condition for Mac OS profile to match on DHCP options or Class ID. For Windows, you should see Class ID = MSFT and that would match the Windows-Workstation profile. If not seeing that, then requires further investigation. A screenshot of endpoint attributes for Windows WS would be helpful.

Craig

Re: ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Fri, 27 Oct 2017 00:51:10 GMT

The Mac OS profile includes IP:User-Agent. That info is found in the class identifier. Not sure why it's not showing up in this one, though. I've used the same laptop in other deployments and it profiled properly. I could test doing DHCP profiling but I doubt it will work since option 60 doesn't appear to be populating.

I'll test another Windows laptop ASAP and post the result.

Re: ISE 2.3, C3PL, and DHCP profiling

Craig Hyps — Fri, 27 Oct 2017 01:38:33 GMT

That is not correct. The user agent is extracted from HTTP data and we currently do not retrieve HTTP data for Wired connections via Device Sensor today--only wireless. User Agent is very different than DHCP Class ID. If think there is a difference in attributes, you can quickly tell difference by enabling DHCP probe on the PSN and adding an ip helper-address to the local gateway of the client which points to that same PSN.

/Craig

Re: ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Fri, 27 Oct 2017 15:02:57 GMT

I guess I am confused on the way Mac OSX is profiled. I know I've profiled OSX machines in the past with just DHCP because they didn't go through any portal (guest, URL redirect, etc.) so HTTP wasn't utilized. I'll check into it further. I may just have to create a custom profile using the OUI and DHCP parameter request.

Re: ISE 2.3, C3PL, and DHCP profiling

Jason Kunst — Fri, 27 Oct 2017 15:11:32 GMT

If you’re using network device sensor then you were likely to get http probes as well with that and better increase your profile accuracy

https://communities.cisco.com/docs/DOC-71879

Re: ISE 2.3, C3PL, and DHCP profiling

Timothy Abbott — Fri, 27 Oct 2017 15:21:27 GMT

Joseph,

The information we typically get to help profile Macs are OUI, User-agent and operating system. If we just get the OUI, it will fall into the "Apple-Device" policy which will then kick off an OS NMAP scan of the endpoint where we learn the operating system. That is for wired networks of course. If wireless, WLCs with HTTP profiling enabled on the SSID will send the User-agent string and can profile it with only that information.

Regards,

-Tim

Re: ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Fri, 27 Oct 2017 15:25:01 GMT

I wonder if there is any HTTP info coming from the way OSX checks for a captive portal on networks. I could enable the HTTP sensor and grab that if it exist. I'll test that out. I appreciate all the responses.

Edit: They don't want to enable NMAP on the limited number of PSNs they have so that probe is out at the moment. Would be helpful.

Re: ISE 2.3, C3PL, and DHCP profiling

katmcnam — Fri, 27 Oct 2017 15:29:12 GMT

Are you doing posturing at all? If you're doing CPP, I would assume ISE could get the user-agent from that as well (Tim and co will correct me if I'm wrong)

Re: ISE 2.3, C3PL, and DHCP profiling

Craig Hyps — Fri, 27 Oct 2017 16:42:26 GMT

Points of clarification:

We do not use posture data for profiling today 😞
Counter to popular belief, HTTP probe does NOT need to be enabled to capture user agent data. We auto capture user agent when client connects to ISE portal
DHCP PRL May contribute but may not see Class ID populated
HTTP in Device Sensor is only supported on wireless today unlesss there was some more recent IOS-XE or Polaris code release that changed that for wired clients on current switch platforms.

Again, actual endpoint details will reveal what is being captured and if opportunity to expand on profile based on available data, or detection of missing probe opportunities. For example, AD probe is one of the best and simplest options for gathering detail Windows classification.

Craig

Re: ISE 2.3, C3PL, and DHCP profiling

katmcnam — Fri, 27 Oct 2017 16:46:06 GMT

Oh I meant profiling when the endpoint hits the CPP since that's technically an ISE portal when they initially connect

Re: ISE 2.3, C3PL, and DHCP profiling

Craig Hyps — Fri, 27 Oct 2017 16:52:04 GMT

Yes, any web interaction with ISE including Hotspot, CWA, BYOD, MDM, Posture, Client Provisioning, Sponsor/MyDevices Portal should capture user agent automatically. The enablement of HTTP probe is typically used only for SPAN or local promiscuous capture of HTTP traffic.

Re: ISE 2.3, C3PL, and DHCP profiling

Craig Hyps — Fri, 27 Oct 2017 18:00:03 GMT

I need to clarify my previous response regarding ability to leverage posture in ISE profiling. (Thanks Hsing for calling out potential confusion).

AC and NAC Agent do have a web-enabled application and their user agents are also captured by ISE when they hit an ISE portal. There was a specific defect where this was not working in some releases and addressed by CSCuz59037.

In other words, it is possible to indirectly capture user agent from endpoint via posture agent. The point I was calling out is that we do not currently extract detailed posture info learned from Posture (or MDM) process for the purpose of profiling.

Hope that clarifies. /Craig

Re: ISE 2.3, C3PL, and DHCP profiling

Joseph Johnson — Sat, 28 Oct 2017 15:53:48 GMT

Unfortunately, there is no posture planned at this phase of the customer's deployment. That would make it a lot easier to profile for sure. Profiling for workstations is only for visibility and no authorization rules. Profiling for IP phones, printers, APs, etc. is going to be used for authorization but that is working so far with the device sensors.