@RichardAtkin wrote:
To be honest with you, I still don't get why you think your use case is different to anybody else who does profiling. Why cant you create Authz rules for the various device types to grant them the access you want them to, then anything else (ie, new stuff not profiled yet) hits the default rule which grants enough access to allow profiling to take place. Can you share a screenshot of your policies and some info about the devices you're connecting?
I'm a bit of a newcomer to this community and this is my first thread. I realize that you are probably a subject matter expert here and I appreciate your input. However, the question I posed originally and as stated in the title is pretty straightforward: How to create an ISE authorization condition to match a newly created endpoint. I have supplied additional information in response to queries about why we need it and how we'll use it but at the end of the day it's still a straightforward question which could conceivably be found on a Cisco certification exam. I would be interested in your solution to the problem, if you have one.
I realize that my explanation of our particular profiling logic may have left you with questions. Our situation may not be unique but while there is always room for improvement our solution has worked well for us for several years. Perhaps a more complete explanation with screenshots would help but it was never my intention to get into a lengthy discussion about profiling logic designs.
Also, the device its self doesn't need to know anything about CoA. If it's having trouble with stuff like VLAN changes caused by CoA (which in its self is caused by the profiler deciding it now knows what something is), just bounce the switchport as part of the CoA action.
You might want to think very carefully about using port bounce. Environments that use multi-auth, PoE or devices with built-in switches/hubs may present unexpected challenges with this approach.
