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.
Thanks, this really helped us as we were also experiencing devices only being assigned the top profile and ISE seemingly not receiving the LLDP/CDP attributes even though the switch is configured to send them. Once we implemented your work around, devices were being profiled correctly again.. is there a way of implementing this long term without having the effect of everything in the radius log showing a status of authorised? or should this method only be used during the profiling stages of implementation. Currently we have changed the default policy to have the result policy outlined in your work around.
I am not aware of any other way at this point outside of just creating a rule specifically to allow profiling only so you can run reports filtering that out. From what I can tell, and I’m no switch expert, it would take something in the IOS/IOS XE code to allow accounting to continue even with an access-reject.
Looking for any input as I am running ISE 2.4 as I try to find an option that will help me determine if an IP Address is DHCP or Static.
Is there an output in the API Calls ro some other option , maybe in profiling that would help give this information ?
We are using a few ISE API calls to extract information about the MAC Address and its time on the network but I am not able to use the APIs to find anything about DHCP/Static mappings.
There is a command from within the CLI that gives some information about DHCP but it is a hit/miss. The application configure command but I am not sure what information is used to populate some of the DHCP information such as Access-REQUEST as this is not consistent.
Any ideas or info would be appreciated
Just found this post whilst looking for something else, can confirm that I ran into this problem with my first ISE install after Device Sensor become available as a means to gather info regarding an endpoint for profiling purposes. Ticket was raised to TAC at the time and they confirmed that in order to receive the info from device sensor via accounting you needed access-accept to be returned. They suggested dumping unknown devices into a ‘Guest’ VLAN with appropriate security controls in place or ‘as this blog post states using a DACL to otherwise deny them access to the network.
One side note that I have found through my installs with ISE is that its not worth leveraging a feature to create profiling policies if those features can’t be uniformly deployed across the network, for example modern catalyst switches support Device Sensor to obtain DHCP and CDP / LLDP info but older Catalyst switches and Meraki switches don’t so if your NAD estate is mixed you should use the lowest common denominator when deploying profiling probes (often this will be DHCP realy) otherwise a device connecting via a legacy Cat or Meraki switch will be missing the info required to profile it.
Thanks for that info, Neil. I’m really hoping the Meraki team adds device sensor abilities in the upcoming lines. I know they are already adding more features to make it work better with ISE (ie dynamic ACL/Group Policy assignment for wired devices versus the current VLAN switching requirement).
I am beating my head against a wall trying to make this work. The only way I can get a Cisco IP-Phone to send the Device Sensor CDP accounting is to set the switchport to authentication open. I’ve tried every other combination of Policy Sets including this DHCP only profile. I’ve even set the default MAB rule to Access-Accept with no dACL restrictions but I can’t get the CDP details. Any suggestions? Running ISE 2.6p5 and my switch is on 15.2(4)E8.