ISE 1.2 Profiling - User Agent attribute incorrect

Question

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

Answer 1

"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