ISE 1.2 Profiling - User Agent attribute incorrect

[Stephen McBride]

Hi all,

Just troubleshooting some profiling issues and have found that multiple devices are profiling incorrectly eg MAC OSX profiling as Apple-Device. Basically the issue is the user-agent string profiled by ISE is incorrect meaning that only the OUI is matched. During the BYOD onboarding process, non Internet Browser, applications and services (games and OCSP Daemons etc) are presenting their specific user-agent strings eg "OCSPD\1.0.2" to ISE resulting in incorrect profiling.

Does anybody have any suggestions on how to resolve this issue as it is resulting in about 50% of devices been profiled at the "top level" ie Apple-Device or Windows Workstation (anything based on User-Agent). Can any one explain whether profiler works on the basis of first agent received, last agent received and why it doesn't hold onto a list of presented agents to make a decision? In my mind this is a pretty big issue in that some of the more popular device profiling policies are based on a user-agent string thus potentially preventing you from defining tight Authz policies eg IPAD only etc

[Saurav Lodh]

I would suggest the Profiler Feed services below

 

OUI Feed Service

The designated Cisco feed server downloads the updated OUI database from the following location: http://standards.ieee.org/develop/regauth/oui/oui.txt , which is the list of vendors associated to the MAC OUI. The updated OUI database is available for any ISE deployment as a feed that Cisco ISE downloads to its own database. Cisco ISE updates endpoints and then starts reprofiling endpoints.

The designated Cisco feed server is located at https://ise.cisco.com:8443/feedserver/ . If you have any issues accessing the service, ensure that your network security components (like a firewall or proxy server, for example) allow direct access to this URL.

[Justin bollinger]

An understanding of how the feed service works is not the underling issue. 

The issue is not that the ISE system does not contain the necessary rules to process the endpoint.  The problem in my case is that under the endpoint the useragent field displays "ccmhttp" 

The issue is that the first useragent the http profilier sees for an endpoint is the only useragent that the profiler sees.  Even if a more accurate useragent like "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" is used after this first useless useragent is "stuck" in the endpoint database. 

[Stephen McBride]

As Justin and myself have described - the feed service is not the drama the fact that the profiler is hanging onto the wrong user agent is causing the drama.

In essence this is breaking major Plus and Advanced license functionality such as profiling information in AuthZ rules and some client provisioning rules.

[nspasov]

What profiling probes do you have enabled? Also is this for wired or wireless?

[Stephen McBride]

Wireless use case in this case a CWA supplicant provisioning flow. RADIUS and DHCP probes. What you have to understand is that a lot of devices are profiling fine. As an example Apple iphones are profiling fine when the correct user agent is seen however an identical device that presents the incorrect agent is not. You can delete the endpoint from ISE and in some instances the device reprofiles fine. The issue with that approach is it means you have to onboard the device again...

[nspasov]

1. Hmm. I have done many ISE deployments and I haven't had the issue that you are experiencing. In fact, with MACs I have always used Firefox due to the Java issues with Safari.

2. What are the settings that you have in the "advanced" tab of the SSID?

3. You should probably turn on your HTTP probe in ISE as well. I believe that the HTTP and DHCP profiling info from the controller would come over a RADIUS message so you don't technically need that but I always enable it.

Unless you have suppression configured, ISE will continue to collect profiling data and will re-profile a device as long as a rule with higher certainty factor is hit. However, if the certainty factor is the same the device will remain at its originally profiled group.

[Stephen McBride]

1 - I've seen this issue on many deployments but until recently had not really looked at it.

2 - Standard type settings aaa override, RADIUS NAC, RADIUS client profiling DHCP and HTTP.

3 -I have just checked and HTTP probe is definately enabled on this deployment. Either way the user agent string from http is gathered successfully but as described ISE is holding onto the wrong string presented by other applications

[Justin bollinger]

"Unless you have suppression configured, ISE will continue to collect profiling data and will re-profile a device as long as a rule with higher certainty factor is hit. However, if the certainty factor is the same the device will remain at its originally profiled group."

The suppression feature will not affect the re-profiling of a device.  The suppression only affects the logging on the MnT node.  Since the Profiling is a PSN function the suppression has no affect on the outcome of a profiling event. 

You are correct in that a rule with a higher certainty factor "wins" and this is the profile that is chosen.  Again, an understanding of how profiles work is not the issue here.  

For example say only the RADIUS and HTTP probes are being utilized for an endpoint.  There are two endpoints one is a iPad and the other an iPhone.  The endpoint attributes that are known about the device are the MAC OUI and the useragent. 

Based on the default profiling rules there are two three things that need to be identified either an iPhone or an iPad.  The first common item is that the MAC OUI is identified as apple.  This increases the certainty factor by 10.  The second is either the HTTP User agent containing either iPad/iPhone or the DHCP hostname containing either iPad/iPhone.  Both of those conditions would increase the certainty factor by 20 for a total of 30.  Since DHCP is not being used in this example we can remove that for a possibility and say that for an iPhone to be profiled as an iPhone it must both have a MAC OUI of apple and the useragent must contain iPhone.  Same goes for iPad, but iPad in the useragent. 

Like smcbridebpc stated every application that uses HTTP will have a useragent string.  The profiler rules assume that the useragent that is being used contains either the word iPhone or iPad to distinguish these types of devices.  If an application on the device sends a useragent string such as  "OCSPD\1.0.2" which is obviously the OCSP Daemon.  This useragent string is "stuck" on the endpoint and no other usable useragents can be used to profile the device.  Therefore a race condition exists and depending on the application that wins determines if the profiler will be accurate or not.   

The only two solutions that I can think of would be to have a useragent filter that would allow you to manually filter out useragents like "OCSPD\1.0.2" (or the ISE developers could filter known unusable user agents out on the backend)  OR everytime a new useragent is presented to the profiler for a device the useragent is joined to a list of useragents. 

If the useragent was overwritten everytime a new useragent was presented then it would cause the device to be reclassified everytime the different applications presented useragents which would not be good.  

It does look like a bug may have been filed and marked as fixed in release pending, but the bug notes do not list enough information to identify if this is the same issue that we are seeing.

https://tools.cisco.com/bugsearch/bug/CSCuj45373

[nspasov]

By suppression I meant "profiling suppression" aka endpoint attribute filter :) This is an intriguing problem that I really have not noticed before. I will be playing around this weekend in my lab.

The bug looks promising too but let me ask you this: Are you only having issues with Apple devices or other devices too?

I like your idea of filtering the OCSPD manually. Let us know if you try it and what the outcome is. I will also try it in my lab.

Overall very nice post (+5 from me)

[mohanak]

Cisco ISE profiling has categories for devices obtained from the cloud or through customization. Each category has specific “weights” assigned that are measured against the device data. As Cisco ISE profiling captures data, different specifications trigger categories as assign weight values are met. For example, a iPad will move from UNKNOWN to APPLE DEVICE based on MAC, network card manufacture type and other info. As more data is collected about the iPad, Cisco ISE profiling will use other attributes to match it from APPLE DEVICE to iPad. Custom categories can be created from UNKNOWN or existing profiles however the majority of device profiles are obtained through the cloud.  Profiling is continuous meaning if a device is spoofed, its behavior will give away it’s true identity to provide continuous monitoring of device types on your network.

https://supportforums.cisco.com/document/128386/profiling-cisco-ise

[Stephen McBride]

I appreciate your information but this has nothing to do with custom categories or incorrect profiler policies. Further to this I do understand the profiling policies and have created my own polices for corporate machines etc however these are not the profiles in question. The standard MAC OSX polices are there but the device is presenting incorrect and random information ie incorrect user agent from another application - it would appear as though ISE does not continue to reprofile these devices.

In my case as an example you do a CWA redirect enter credentials in the portal using mozilla and are subsequently onboarded. Problem is despite using Mozilla ISE has picked up the user agent from the OCSP daemon meaning the apple device is not profiled as mountain lion (MAC OS etc in user agent). I have tried with other browsers and the problem persists. I have checked that browsers have not had their agent strings overwritten thus proving that other apps agent strings are been held by ISE.

It seems to me that ISE is not reprofiling or not considering the browser string which is presented at some point during the process.

[manjeets]

Here is the related link :

http://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/design-zone-security/howto_30_ise_profiling.pdf

[Stephen McBride]

No offence but can you explain to me the point of this post in the context of everything that is discussed here in this thread? For what it is worth I know how to configure profiling but have no idea how to get around the fact that ISE receives the wrong information and won't reprofile or select the right information to make a descision. For this particular version of ISE the only workaround has been to manually assign the device to the right profile. I haven't seen the issue in 1.3 yet so hopefully it is fixed but yeah not so sure.

Is there something in your link that has the answer or is it a throw away link to bump a post count?

[stevburn@cisco.com]

Was this ever resolved... running into a similar problem with ISE 2.2.0.470