Anamolous detection issue for ise 2.3

[Karry]

Hello everyone,

Many of Windows workstation are detected as Anomalous in ISE 2.3 . Even though the desktop of corporate desktop without any change . As per the log endpoints detected as anomalous because of the DHCP class identifier change as in the case below.

2018-09-18 03:20:39,272 INFO   [MACSpoofingEventHandler-52-thread-1][] com.cisco.profiler.api.MACSpoofingManager -:ProfilerCollection:- Anomalous Behaviour Detected: 10:60:4B:77:98:61 AttrName: dhcp-class-identifier Old Value: MSFT 5.0 New Value: MS-UC-Client

The attribute values “MSFT” and “MS-UC-Client” are both part of “Microsoft-Workstation” profiling policy rules. I’m unsure why ISE is finding the new value after a while – this change in attribute is causing the anomalous detection.

Can anyone help with the resolution or workaround for the same.

[yalbikaw]

the issue here is changing on the class identifier value !
because ISE will consider it as anomalous detection.
maybe you can disable the enforcement and keep the detection then you can quarantine manually, this maybe some sort of workaround but not a solution for the issue.

[hslai · Accepted solution]

yalbikaw is correct on this. Please engage Cisco TAC to investigate why the UC client making DHCP requests, when it appears not bridged with its own MAC address.

[howon]

See CSCvh24575 (Ability to filter or ignore certain attributes for Anomalous Client detection)

[DIEHARDave]

I am having this issue in ISE 2.4 as well. Thousands of workstations being detected... Makes it a bad option to enable enforcement until this can be fixed.

[Damien Miller]

Depending on which version/patch combination you are on, this bug also creates false positives, it is not just 4500's as the description would suggest.  https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvk10674

[Panos Bouras]

My take on enabling Anomalous Detection also didn't work correctly, I engaged TAC and it turned into a dead end. I'm also seeing lot of false detections when we turn this on, so I cannot recommend this for enforcement, but rather as an indication for things to check.

I believe that a stronger profiling policy along with proper network design is more effective, if utilizing Dot1x is not possible.

[DIEHARDave]

Not sure why this was "solved" simply saying open a TAC case but from what I have found it has something with Skype changing the DHCP class identifier when it launches so depending on when the DHCP packets are sent it could show MS-UC-Client or MSFT 5.0.

There is already a bug report for this apparently: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCum61422

Workaround:
Manually create a profiler workstation policy to match against a DHCP-Class-Identifier using "MS-UC-Client"

I have cleared my Anomolus list and will let you know if i see it fill back up!

[DIEHARDave]

I read the original post again and they already had this in their Workstation configs... They started showing up again in my list as well after clearing it and trying the "workaround".

The issue remains the DHCP identifier changes therefor it's Anamolous as that alone triggers it. Even if you add the UC agent string to and existing or new profile. :(

What was TAC's response?

[ommaayah]

Hello

Did you get this sorted out ? what was the solution ?