Hi board,
I'm not quite sure if this belongs here or in the switching section. I'll give it a try here first.
I'm using IBNS 2.0 on my switches. My ISE use-case is 802.1X and MAB with profiling. Formerly, I did profiling using the DHCP probe and SNMPQuery probe to gather CDP and LLDP attributes - simple enough!
Now I'm testing the Catalyst 2960-X SW Version 15.2(4)E4 and thought, that the device sensor would be a great alternative and to only activate the RADIUS probe on my PSNs. Despite the usual hassle regarding the device-sensor syntax in IBNS 2.0 I finally got it working and verified the testing results by a RADIUS accounting capture with the device sensor AVPs with an existing endpoint in my endpoint database. So far so good.
The only thing, which is not working is the device sensor in combination with new endpoints, which initially are rejected, because there is no match in the authentication and/or authorization policy.
Obviously, the Cat. switch is only sending out RADIUS accouting messages, containing device-sensor attributes after successful authentication (staus: authorized).
I stumbled over the bug CSCux48616, which describes this behavior. The bug description states that this is a documentation bug instead of a switch bug.
First question: Anybody knows this behavior on switches? Where's the documentation for this? I couldn't find any hint's except in this bug note.
Second question (object to discuss):
If this is the normal behavior, the device sensor functionality doesn't make much sense from my point of view. New devices, that have never been on the network and perform a MAB authentication are rejected by nature, because:
- these devices are not in any endpoint identity group (not profiled) and fail authentication (authentication failure) OR
- these devices are profiled (e.g. Cisco-Device because of OID) but there is no authorization rule for this group (authorization failure).
Even if the devices are rejected by the ISE, link-local operations (CDP,LLDP) are still possible. When using "authentication open" with a pre-auth port ACL, DHCP is possible as well (if allowed in the ACL). At least the local device sensor cache on the switch is populated correctly, even on failed authentication ports.
So why on earth shouldn't the switch give this valuable information to the ISE?! It would help to profile the device to a matching endpoint identity group - eventually issue a CoA, resulting in a passed authorization.
A dirty workaround would be to:
- Modify the MAB authentication policy to "continue" in case the user is not found (for new - not profiled devices)
- Modify the authorization policy to make sure there are no rejected (DenyAccess rule) authorizations (e.g. "if any then dACL DenyAll")
But come on .... this is nonsense ..... or not?!
Or is there a config command to enable device sensor accounting for failed authentication attempts?!
Please share your thoughts.
Kind regards
Johannes
