ISE 2.3, C3PL, and DHCP profiling

[Joseph Johnson]

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.

[Joseph Johnson]

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.

[Craig Hyps]

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

[Joseph Johnson]

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.

[Craig Hyps]

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

[Joseph Johnson]

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.

[Jason Kunst]

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

[Timothy Abbott]

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

[Joseph Johnson]

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.

[katmcnam]

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)

[Craig Hyps · Accepted solution]

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

[katmcnam]

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

[Craig Hyps]

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.

[Craig Hyps]

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

[Joseph Johnson]

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.