Apple MAC OS -(wired dongle) getting profile as Unknown?

[Parag Mahajan]

I have been facing issue, where MAC OS machines connecting through external wired dongle are getting profiled as unknown. Has anyone found the way how to profile it as an apple device or MAC workstation.

We are using MAB to authenticate those endpoints. We are using DNS, DHCP, DNS, NMAP, SNMP query and Trap profiling probes.

We do not want to create custom profiling policy based on MAC OUI/MAC address of dongle as their are various vendors for dongles and this approach will not be scalable.

We do not want to use web redirection as we are doing simple MAB auth. Even current ISE default profiling conditions dictates that MAC workstation gets profied only with HTTP web redirection and anyconnect.

[Greg Gibbs]

The Profiling policies are hierarchical, so the endpoint will not be profiled as an Apple-MacBook unless it first matches the Apple policy (which is based on OUI).

When the Profiler fails to match any policies and falls the Unknown, it should trigger an NMAP scan (if you have the NMAP probe enabled).

To use NMAP to Profile the MacBook as a Macintosh-Workstation, you would need to create a new Profiler condition matching on 'operating-system CONTAINS Apple Mac', then add that new condition to both the 'Macintosh-Workstation' and parent 'Workstation' Policies.

Example:

[Craig Hyps]

While it is true that the Profiler Policy rules are hierarchical, the endpoint should still match the Workstation branch which includes Mac OS.  If provide the output of the endpoint details, it can be compared to current ruleset and determine if tuning is warranted.

Craig

[Parag Mahajan]

grgibbs

We thought on the same line. But it will not work. Please find screenshot. nmap scan did scanned the endpoint but failed to gather correct information. OS result for MAC , it was showing as Nexus 7000 switch

[Craig Hyps · Accepted solution]

The reason for not matching is not the USB plug, but simply lack of sufficient data.  The two attributes which are helpful include the PRL and the hostname.  I assume this is a Macbook Air?    Please enter the DHCP Parameter Request List as text in thread.  It seems to be using an add combination, but that may simply be clarity of screenshot.  TCPIP stack should not chnge with adapter.

Craig

[Parag Mahajan]

[Parag Mahajan]

Yes this MACbook air. What do you mean by PRL ? When you refer TCPIP stack should not chnge with adapter. Which attribute you are targeting to get correctly profiled.

[Craig Hyps]

DHCP options are the same regardless of network adapter used.  PRL = Parameter Request List = DHCP Option 55.

Try the profiles for Apple MacBook Air and OS_X I posted here:

https://communities.cisco.com/tags/ise-endpoint-profile

/Craig

[Parag Mahajan]

I imported both profiling policy , it's not working. As new profile gets added under Apple device parent policy and then under Apple MACbook. So I believe, It should first match the Apple device profiling policy. Since the third party USB ethernet adapter MAC OUI was not listed under Apple profiling policy, so it did not work.

Once we added that MAC OUI under apple device profiling  it did worked. But still this is not scalable approach as there so many vendors manufacturing usb ethernet adapter for MACbook air and we can not add each and everyone under parent policy.

According to you how should we scale this

[Craig Hyps]

No, the MacBook Air policy would not match since predicated on Apple.  It would not be reasonable to add to the Workstation branch since that starts branching off based on OS versions rather than hardware platform.  The Mac OS X WS policy should certainly match which I thought was the original requirement.  If not matching the WS policy, let me know and I will recheck the conditions, but it looks correct based on the DHCP info provided in last screenshot.

[Parag Mahajan]

Hi Craig,

I got it, what are you trying to achieve. It is not matching WS thats why its not matching 'Macintosh-Workstation' or 'OS_X-Workstation' where you added 'MacOS_X-DHCP-PRL-Check1' this custom condition . Do you think the rule 'MacOS_X-DHCP-PRL-Check1' should be part of workstation profile or does it require other tuning as you mentioned that 'It would not be reasonable to add to the Workstation branch since that starts branching off based on OS versions rather than hardware platform'

Edit : We are using MACbook air with macOS Sierra - 10.12

[Craig Hyps]

It was applied to parent policies, so should match up the tree.  Check actual PRL against the value in condition.  Could be issue with spacing or other which not catching in condition.

[Parag Mahajan]

When you refer that it was applied to Parent policy do you mean 'Workstation' or 'Macintosh-Workstation' profiling policy.

My understanding with profiling is that (might be wrong), for e.g to match OS_X_Sierra-workstation in below it should match 'Workstation'. Hope my understanding is correct.  

I did confirm that PRL against the value in condition and its matching.

What is risk if 'MacOS_X-DHCP-PRL-Check1' should be part of workstation profile ?

[Craig Hyps]

For some reason, the rule was not getting added to parent in the export file, even though present in UI.  I manually updated the XML file to include it in the parent policies.  Try re-posted version.

[Parag Mahajan]

Hi Craig,

Really thanks for all the effort!! You are the Gem!

Its working..Just for wider audience for reference posting below

DHCP Parameter Request List Option 55 Used to Profile Endpoints Configuration Example - Cisco