I’ve seen this a couple of times at customer locations. They are using a default deny if the endpoint fails all other authorizations rules. When they check for endpoint details (profiling), only the top level profile (ie Cisco-Device) was assigned. The child profile is not analyzed so therefore any authorization rule that relies on that child profile is never hit. This was especially an issue with IP phones, both Avaya and Cisco phones, because the CDP/LLDP info was not complete. Why?
The issue was caused by the access-reject triggered in the deny access authorization result. Device sensor data utilizes the RADIUS accounting packet to deliver that information to the Cisco ISE node. When you send an access-reject, you end all accounting for that session. The only way to trigger a new session is for the endpoint to disconnect and reconnect or a session timeout to occur. A new session will trigger the RADIUS authentication and accounting to start again which will send more information to the ISE node.
So how can you get around this? The way I’ve found is to utilize an access-accept authorization profile that utilizes a simple dACL:
# Allow DHCP
permit udp any eq bootpc any eq bootps
# Deny all other access
deny ip any any
Once that was implemented, accounting will continue even though the endpoint has no real network access (DHCP only). The customer was able to see the proper child profile hit which allowed the correct authorization rule to be triggered. If you are concerned about DHCP access, or only concerned with received CDP/LLDP info, you can remove the line to allow DHCP.