Cisco ISE Anomalous Behavior dhcp-class-identifier Imaging Issue

[PRANetworkTeam]

Hello Cisco brains, 
I recently deployed Cisco ISE (3.1P3) and I'm running into an issue with Anomalous Behavior and Detection. I understand that in order for ISE to trigger an anomaly, it must hit the following:

1. NAS-Port-Type - Determines if the access method of this endpoint has changed. For example, if the same MAC address that connected via Wired Dot1x is used for Wireless Dot1x and visa-versa.
2. DHCP Class ID - Determines whether the type of client/vendor of endpoint has changed. This only applies when DHCP class ID attribute is populated with a certain value and is then changed to another value. If an endpoint is configured with a static IP, the DHCP class ID attribute will not be populated on ISE. Later on, if another device spoofs the MAC address and uses DHCP, the Class ID will change from an empty value to a specific string. This will not trigger Anomouls Behaviour detection.
3. Endpoint Policy - A change in endpoint profile from Printer or IP phone to Workstation. 

We have our switches filtering attributes based off lldp, cdp, dhcp, and vlan-id then being sent to ISE.
The issue we are running into is with our imaging process for new machines on the network. Whenever a device is being imaged, we use Ivanti with PXE so the machine's dhcp-class-identifier shows as "PXEClient". After the imaging process for installing windows is complete, the dhcp-class-identifier changes to "MSFT 5.0" which then triggers the Anomalous Behaviour. I currently have Anomalous Behaviour Detection enabled but I kept Anomalous Behaviour Enforcement disabled so it won't restrict network access. Our security team would prefer to keep enforcement enabled to protect us against mac spoofing. 

Does anyone out there have recommendations for imaging new machines while keeping ISE enforcement active?

Thank you! 

[ahollifield]

Have a specified set of "build ports" in a secure area that do not have authentication enabled?  

[PRANetworkTeam]

@ahollifield That would be an easy way out however our Security Team wants us to enable ISE on all ports. Unfortunately having a select group of ports on the network open is not an option. 

[ahollifield · Accepted solution]

Yeah this is a really common thing with any wired NAC deployment.  I've seen customers solve this mainly in these ways:

1. Open build ports like I mentioned above
2. Make an authz profile for the PXE devices that uses a dACL (SGT, or other type of enforcement) to limit the access of that device only what it needs to go through the build process.
3. Use the guest network/VLAN (for the use-case of autopilot).

[PRANetworkTeam]

Thanks for the input! @ahollifield . The goal is to keep things as simple as possible without restricting access to deploying new machines. These options helped confirm our thought process as well. 

[Arne Bier]

I don't think one can influence the PXE Boot client to send a custom client identifier - if you could fake it to be MSFT then it would perhaps solve the issue. I think there is no real solution to this - other than to perform a "clean-up" operation after the PXE boot is done. Deleting the endpoints and then letting them re-auth "clean" is what I would do. I find Anomaly detection quite bothersome to be honest. Perhaps because I haven't found much functionality in ISE to deal with these occurrences. 

On a related note, in the Report "Endpoint Profile Changes" I can see that endpoints are constantly being re-reprofiled as the same thing (Current Profile is the same as the Previous Profile) - and then ISE flags that as something I should care about, but provides no data or tools to manage this. At least it tells me that the re-profile event was not due to an update to the Profiler Feed  

[andrewswanson]

A few years ago, I had a look at using powershell scripts to add/remove PXE clients to ISE using ERS.

I used the site below - it worked well but management decided against using it in production. Could perhaps be a way of working around Anomalous Behaviour and Detection.

hth
Andy

https://www.asquaredozen.com/2018/09/29/configuring-802-1x-authentication-for-windows-deployment-part-5-dynamic-whitelisting-using-the-cisco-ise-external-restful-service/