01-17-2023 01:43 PM
I've read through the great design guide on ISE profiling and have a question about CoA based on what I have observed with my deployment.
I have a policy set with authorization rules that do not reference any profiles. I can see clients that match that policy being sent CoA messages because they either got profiled for the first time or changed profiles. I didn't expect to see that, given their policy set doesn't contain any profiles in the authorization rules. Is this expected behavior?
If I wanted to disable CoA globally by setting the CoA setting to "no CoA," would I still be able to use CoA for policies that do reference profiles?
Solved! Go to Solution.
01-17-2023 02:27 PM - edited 01-17-2023 02:27 PM
In short, yes. The Reauth action can be set directly on a profiling policy and it will override the global setting.
If you set the global setting to No CoA, then endpoints will only be reauthed on profile change if the profile they match has the "Associated CoA Type" set to Reauth/Port Bounce.
01-17-2023 02:27 PM - edited 01-17-2023 02:27 PM
In short, yes. The Reauth action can be set directly on a profiling policy and it will override the global setting.
If you set the global setting to No CoA, then endpoints will only be reauthed on profile change if the profile they match has the "Associated CoA Type" set to Reauth/Port Bounce.
01-17-2023 02:35 PM
It looks like all the CoA packets being sent are for the cause "first time profiled" and not because the change in profile would affect how an authorization rule list would be processed. Too bad I can't just disable CoA for first-time profile, If you set the global setting to No CoA, that doesn't impact guest portals, does it? I wouldn't think so because even though guest uses CoA it is not related to profiling.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide