ISE profiling rule certainty factor

[Stuart Patton]

Hi,

Running ISE 2.7 with patch 6 (don't ask, we'll be upgrading in the next 12 months) and struggling to understand an issue with profiling rules and certainty factors.

I have created a profiling policy that has a MCF of 500.  My policy is made up of four rules that have to be met:

• DHCP hostname (200)
• MAC OUI vendor (200)
• DHCP class identifier (50)
• DHCP parameter request list (50)

If I bounce a switchport and delete the endpoint, the port goes through dot1x (fails), falls over to MAB and is successfully identified as one of the devices per the above rules.  After a period of time, eg the following day, when I check the device has seeming been reclassified as microsoft-workstation by the Cisco-supplied rule that has a MCF of 10. I think the specific element of the microsoft-workstation policy that we're matching is the same DHCP class identifier.  The device I'm profiling *is* a Microsoft OS, it's just that it's managed by a third party and cannot be domain joined, and we push identity certs for dot1x out through GPO so it's not a viable option for us.

We are assigning an SGT in the auth rule for segmentation, so the misclassification is a problem for us.

Everything that I've read in the forums and on external websites advise to use higher MCF for your own rules as this should win versus a lower MCF.  Is my understanding of that correct?  Or is there a caveat that I'm missing?  Or is it possible we're hitting a bug in 2.7 patch 6? We can probably go to patch 10 if needed.

Thanks

[davidgfriedman]

Thoughts: I've seen MS SSCM GP updates push a new DHCP hostname and other things, which can cause profile changes similar to the ones you have shown. Have you run a Profile Endpoint summary to see if these are the only two profiles it changes into/through? Have you gone back into the endpoint attributes AFTER the endpoint group profile change, to verify the conditions are still the same and still match, character for character 100%?  You might find one of the conditions has changed. If it is safe to add that, you might need to add that changed condition as an OR case to ensure it works after any MS / GP policy pushes, if that is what is happening to you. I'm sure Cisco TAC would ask the same questions. 

[Stuart Patton]

These are not joined to the domain so don't get GPOs applied.  The comment in my original post was that we use GP to deploy identity certs for dot1x on our corporate machines during the build process, but because these are not domain joined we can't do dot1x on them.  Well, we could install certs but it would be a manual and laborious process. 

[Arne Bier]

I feel your pain!  Having struggled a bit with profiling myself. I have never seen an endpoint being "down-graded" like that. If after an endpoint delete and port bounce the MCF = 500 then that should stay like that. Are you perhaps purging those endpoints?

I have also witnessed similar thing to what @davidgfriedman found - certain conference phones boot up with an OS DHCP stack and get profiled as Microsoft-Workstation, and then after some time, another process kicks in and sends a different DHCP class-identifier. This causes the ISE Anomaly Detection to go nuts. 

Once the endpoint is in this mis-profiled state, is the hostname and DHCP parameter request list different than before? (you can perhaps check the Device Sensor cache on the switch for that endpoint). If these values are the same as before (when your Policy matched) then it smells like a bug. I also just assumed that the MAC OUI didn't miraculously change overnight either

Here is also a very handy Community Post that shows us the ISE Profiler Probe frequency behaviours - the page has a ton of info - you might have already seen this.

[Stuart Patton · Accepted solution]

Dammit, thanks for the pointers @Arne Bier and @davidgfriedman!  The DHCP parameter request list has changed so I now have a third variant.  I've added a rule in to match that and bingo, they all matched my rule and reverted.  So it looks like when the switchport is bounced, the DHCP PRL at linkup is different to the PRL later on.  Looking at the DHCP lease time for my SDA pools, this is almost certainly at the renewal point.

Thanks for the help.