topic Re: Endpoint present in ISE via Radius probe but no additional atributes in Network Access Control

Endpoint present in ISE via Radius probe but no additional atributes

joeharb — Thu, 27 May 2021 15:25:14 GMT

We are deploying a new model of Cisco AP's and I added that model to our existing policy. We have one deployed and I can see it as an endpoint in ISE and it shows up via Radius probe, but for some reason non of the lldp/cdp information is associated with it. I can verify that other endpoints (phones/old ap's) are profiled correctly and have the correct attributes. The switch is a Catalyst 9300 and debugging is different, anyone have any suggestions on how to troubleshoot? How to see if the attributes are being sent to ISE? We are in the early stages of our ISE deployment and even if a device fails authentication we still allow network access via the ACL on the interface. Does a device have to pass authentication for these attributes to be available, seems like a chicken and egg scenerio.

Any debugging tips or where to look would be appreciated.

Joe

Re: Endpoint present in ISE via Radius probe but no additional atributes

lrojaslo — Fri, 28 May 2021 12:32:10 GMT

CDP/LLDP attributes are not collected via regular RADIUS probe unless you have Device sensor configured. If you don't have device sensor, then SNMP Query probe will be a good probe to collect those attributes, anyways I would recommend having device sensor configured on the switch.

Regarding debugging on 16.x codes:

set platform software trace smd switch active R0 radius debug -> Radius Debug

In order to view collected info, you can either run a show logging or show platform software trace message smd switch active R0

Re: Endpoint present in ISE via Radius probe but no additional atributes

joeharb — Fri, 28 May 2021 13:59:49 GMT

device-sensor is enabled.

I did a wireshark caputure and cleared all access-sessions. I watched filtered out the Radius Accounting packets and could not find one for the interface/device in question.

I will do the debugs today to see what I can get but I assume from what you have said I should be debugging device-sensor?

Thanks,

Joe

Re: Endpoint present in ISE via Radius probe but no additional atributes

lrojaslo — Fri, 28 May 2021 15:02:14 GMT

if it is enabled, then yes, you need to confirm device sensor is working fine "show device sensor cache mac/all".

There is known issue after a switch reload where device sensor stops and requires to be re-configured to work again.

If issue persists after that, you might need to open a case with TAC.

Re: Endpoint present in ISE via Radius probe but no additional atributes

joeharb — Fri, 28 May 2021 15:08:49 GMT

I do see the entries for device-sensor. I do have a question, if the response from ISE is access-reject from the authorization result does this stop the radius accounting, therefore these attributes will never be sent to ISE?
Thanks,
Joe

Re: Endpoint present in ISE via Radius probe but no additional atributes

lrojaslo — Fri, 28 May 2021 15:55:04 GMT

That's correct, accounting session won't be stablished if the response is reject, so if the attributes are transferred via accounting start, those won't reach the ISE.

Re: Endpoint present in ISE via Radius probe but no additional atributes

joeharb — Fri, 28 May 2021 16:00:13 GMT

I have found several posts that people have used a "pre_device_sensor" policy that will catch them and do an access-accept but give a dacl that denies...I am going to test with with a profile that matches Logical Profile Cisco Devices.

Will update with the results, this is what I mentioned in the original about the chicken and the egg scenerio.

Thanks,

Joe

Re: Endpoint present in ISE via Radius probe but no additional atributes

joeharb — Tue, 01 Jun 2021 15:21:08 GMT

I created an authorization policy for PRE_DEVICE_SENSOR (which currently matches if the Device is Profiled as a "Cisco Device", I am sure I will need to add other conditions in the further for other endpoints) that sends back an ACCESS_ACCEPT with a specific DACL that allows dns and dhcp but denies everything else. A clearing of the access-session or reauthentication allows for the device to be authorized appropriately after this occurs. The process is not automated but it works...

Device comes online....sends some Radius information but is denied by the default authorization profile, we do get that it is a Cisco-Device. Created a Logical Profile that matches Cisco_Device and have the end result of this to be ACCESS_ACCEPT with the above DACL. In order to match the new authorization profile a COA has to occur...it matches the new PRE_DEVICE_SENSOR policy and with a 20 seconds timeout but now we have all the attributes needed to profile and authorize appropriately. Reauthenticates and matches appropriate policy.

Hope this helps others...maybe there is a better way but without the ACCESS_ACCEPT you don't get the benefit of device sensor.

Thanks,

Joe