Context Visibility and Docking Stations

[ryanbess]

As we've started to roll out ISE to more and more endpoints, we have started to see some odd behavior in context visibility.  The oddness seems to be related to docking stations where various endpoints throughout the day are using the same docking station.  Example, lets say we have a docking station of 11:24:9B:7A:C5:69 (as an example).  In the beginning of the day a windows endpoint plugs into the docking station.  ISE postures, profiles, and does all its prob stuff about the windows endpoint plugged into the docking station.  All this data is then fed into Context visibility.  The windows user unplugs and goes home.  At noon a mac user plugs into the same docking station and ise does all the same things.  If you then go look at the context visibility for that mac, you will see in some attributes saying the endpoint is windows, some saying it's a mac.  Go into applications you'll see some C:\program files\ XXXX and others like /Application/Cisco.

How do we prevent ISE from doing this.  Its like it just uses the mac address as the primary key and dumps all things under that mac and thus providing data in an odd way.     

[Rob Ingram]

@ryanbess Investigate enabling MAC Address Passthrough mode on the laptops, so that the MAC address of the laptops are used instead of the MAC address of the docking station.

[ryanbess]

Yeah thought of that but was hoping there was another way.  Not sure every laptop or OS will support it.  Have you had good luck with it?

[Rob Ingram]

@ryanbess Windows OS on DELL and Lenovo hardware works well, no idea about MacOS tbh.

[ryanbess]

i'll give it a shot.  My understanding was this required docking stations that supported mac passthrough....

[Greg Gibbs]

"Its like it just uses the mac address as the primary key and dumps all things under that mac"

This is exactly how it works. In most cases, ISE uses the MAC address as the key attribute in the database. It does not flush all of the Profiling attributes learned for a particular MAC address when a device disconnects, so you will see this behaviour with shared docks/dongles. It will only replace new profiling attributes learned for that same MAC address.

To avoid this, ISE would need to see a unique MAC address (or GUID) from the endpoint to keep the profiling data separate. AFAIK, only Windows laptops still support a unique burned-in MAC address that can be passed through on docks/dongles (assuming the dock supports it). Macbooks do not have any such burned-in Wired MAC address.

In addition, Macbooks do not send any useful profiling network information (like DHCP class identifier) that would replace the info previously learned from the Windows laptop.

[GregoryLeggett]

What about the use of a DUID (Device Unique ID) or GUID (Global Unique ID)?  I've heard mention of this several times, but I haven't seen any good examples of it in production.  This would decouple a computer from MAC bloat (i.e. multiple wired and wireless MAC's) and tie them all to a common device identifier, and also solve the problem of whether or not to use MAC privacy.

This is one of the biggest issues I see with ISE right now is that one computer might have 2-5 entries in context visibility, which requires ISE to profile each of them separately, instead of knowing about the device from a previous connection method.

I would love to see some thoughts from Cisco about how to move in this direction, and if possible, what requirements are needed (e.g. licensing, ISE features, endpoint agent, etc.).

[Greg Gibbs]

@GregoryLeggett , that feature enhancement was introduced in ISE 3.2 as per the Release Notes.

The common use case would be an MDM (like Intune) inserting the GUID into the certificate(s) enrolled on the device used for EAP-TLS.
I describe that process in my blog on Cisco ISE with Microsoft Active Directory, Entra ID, and Intune

This feature itself does not require any additional licensing, so the license consumed would be based on what additional features are used in the session. If you were also using a registration/compliance check against Intune, for example, it would consume a Premier license.

[ryanbess]

Hey Greg,

So if the cert gets replaced / updated, this would result in a new entry for that device in ISE?  Is there no option to use the GUID of the AnyConnect client install.  

[Greg Gibbs]

Not necessarily a new entry, but if a different MAC address is seen for the endpoint presenting that same GUID, the MAC address would be replaced for that endpoint entry.

The AnyConnect DUID is not the same as a GUID from an MDM, so it would not meet the conditions stated in the documentation.

[ryanbess]

Morning Greg,

I'm not following, is there a way to tell ISE to track endpoints by the AnyConnect DUID?  Also is there a way to configure the context visibility database to purge data older then X days?

[Greg Gibbs]

No way that I'm aware of to track endpoints by AnyConnect DUID. 

There is nothing specific to scheduled purging in the Context Visibility function, only the Endpoint Purge Policy.