ISE - how-to prevent mac spoofing

Question

I've built an ISE lab (1.1.3.124) and have an authorization policy which permits access to profiled Cisco-Access-Points. For the purpose of the lab, these devices have full access.
Profiling is working correctly. I have a 1231 AP which is correctly profiled and placed in an endpoint group, Cisco-Access-Point.
From a Linux laptop, using macchanger, I can successfully spoof the mac of the AP and gain full access - for some reason ISE isn't profile checking the laptop and I'm not sure why. The laptop obtains an IP using DHCP. I have the following profile checks enabled: NetFlow, DHCP, RADIUS, DNS, SNMP.
When I check Live Authentications, apart from the session IDs, there is no difference when comparing the authz between the AP and the spoofed laptop.
I was hoping that ISE would recognise the spoofed attempt and let it fall through to the deny policy.
I'm happy to attach any screenshots if required.
Thanks.

Answer 1

This may or may not be already known, so I'm going to describe how I would expect ISE to work.
Authentications based on profiling The first time a device comes through ISE, it could get the wrong result you would expect the device to get. This is due to the fact that ISE has a bit of a challenge - to identify and authorize new users to its system before the probes can learn anything about these endpoints.
For example, DHCP and HTTP are fairly useless until after the port becomes authorized since no client traffic can flow before an authentication occurs. ISE might apply the catch-all CWA result allowing it on the network, but then the DHCP class identifier could say 'Cisco AP'.
ISE knows that any new profiled information could result in a different AuthZ policy, so it issues a CoA to inform the NAD to re-authenticate that particular session.
The same authentication occurs now, but ISE now already knows the device appears to act like a Cisco AP and hands back the WAP result this time instead of CWA.
Any future authentications that occur for this Cisco AP, we pass back the Cisco AP result since we know he was previously an AP. Our probes would still learn as much as they can about the 'new' authentication, but no data would change from our end since the probes learn redundant information for this legit Cisco AP.
So, what you're describing is you're performing MAB and swapping out the profiled Cisco AP with another device that is spoofing the MAC address. MAB literally stands for 'MAC Address Bypass', so when ISE is presented with the MAC address it checks its internal host store and finds out he does in fact know 'AA-BB-CC-DD-EE-FF'. The spoofed device was previously known to be a Cisco AP, so ISE will hand out the Cisco AP result allowing it on the network infrastructure VLAN with a special DACL if you're getting fancy.
Your point here is that the spoofed PC is allowed on the network, when in fact it isn't a Cisco AP. What should happen at this point is the probes start doing their magic. The only way a device becomes a 'Cisco-Access-Point' is if the CDP entry in the switch contains 'AIR' or the dhcp-class-identifier includes 'Cisco AP'. So what I would expect happen is if you have SNMP Query/Trap probes setup and working, as soon as the linux laptop plugs in with the spoofed MAC the switch would inform ISE that a link came up/up. ISE sends back an SNMP Query asking for more information, which the switch then provides. ISE would then realize that there's no CDP information there (unless your linux test box is utilizing CDP, then this is a mute point anyways) and update the session endpoint in its internal hosts either during or before the actual authentication occurs. If it's during, ISE would trigger a CoA, which would cause the endpoint to reauthenticate then fall into (probably) the Cisco-Devices group based of the OUI of the MAC.
The other way to become a Cisco-Access-Point by default is through the dhcp class identifier. So lets say your linux box authenticates, ISE passes back the AP result, and you're allowed on the network. Once you issue a DHCP Discover from your box, ISE should recieve it and learn that the DHCP class identifier has changed from what it expected ('Cisco AP') to something different and issue a CoA. The linux box will reauthenticate, and get passed back the generic CWA profile.
Ultimately the entire job relies on either the DHCP probe, SNMP Trap/Query Probes, and CoA...unless you've modified the profiling settings from the default. Since you mentioned deleting the MAC address from the internal hosts section forces ISE to send back CWA, i'm thinking that your switch config might be missing the CoA portion.
1. What probes do you have enabled. This by default requires DHCP, DHCP Span, or SNMP Query/Trap.
2. Can you see the successful CoA from the switch?
3. If you wait ~5 minutes after the linux box with the spoofed address authenticates and check the internal host, what does ISE know about that device? If my CoA theory is right I would expect after even a couple minutes we would recognize that the device isn't a Cisco WAP.