This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Since I apply Patch 3 on ISE version 2.6, ISE does't send CoA (reauth) after profiling an endpoint (working with Patch 2).
I notice a problem of timestamp on accounting log (see picture), it may be a link.
Does someone had the same problem ?
Is there a trick or a workaround ?
Solved! Go to Solution.
@Damien Miller wrote:
I have the same issue with 2.4p10, where P9 appeared to work fine.
Possible that this also applies to 2.6 but the bug hasn't been updated or no one has opened a case on it yet.
Please do open a tac case and attach
So far, 13 service cases have been opened for the Lack of CoA issue after applying PB#3 to 2.6 so does anybody know if this is being worked by Cisco?
I have 3 servers that I need to upgrade to 2.6, but if keeping current for IAVA's and such is going to break CoA (dACLs and dynamic VLANs) which we rely on, then I will stay at 2.2 for now since it is stable.
Cisco, please do a better job of testing these patch bundles!!! I know lab testing cannot cover everything, but having to pull multiple (2-3) patch bundles off your website last year because too many deployments were breaking, that should be caught beforehand, lab or no lab. Do these patches get moved to Cisco's production ISE servers or are we the guinea pigs?
Please open a TAC case and likely you need TAC to request a hot patch because Cisco Identity Services Engine Software Version 2.3 Product Bulletin says,
Starting June 17th 2019 only sev1 and security vulnerability issues will be addressed.
The problem with CoA on ISE 2.6 Patch 3 persist, on Patch 2 profiling is ok but we have a test failure for "DNS A/AAAA record low level API query".
So, now we are up to 21 reported cases (bug write up) of the 2.6 PB#3 breaking CoA on ISE. I'm sure many more cases exist out there. The other ISE versions had the same issue at the same time it appears when their respective patch bundles were released. The only Cisco recommendation so far is to call TAC and ask for a HOT FIX.
How about pulling down the affected PATCH BUNDLES from the Cisco site and uploading the corrected PATCH BUNDLES that incorporates the HOT FIX to save everyone a LOT of time and effort, especially if you have to do a bare metal rebuild and you forget about that little hot fix.
CoA is a core element of ISE....this should be given more attention, priority, and resources than it appears to have been. It looks like v2.4 may be fixed so when can we expect 2.6 to be resolved?
ISE 2.6 Patch4 is out! It should resolve the issue.
Later edit: it was withdrawn by Cisco from the download page due to some profiling bug...
I confirm that ISE 2.6 patch 3 has the CoA issue. ISE 2.6 non-patched does not have this issue.
I'm about to test 2.6 patch 2.
2.4 patch 10 has the same CoA issue. 2.4 patch 11 seems ok.
Regarding the test failure for "DNS A/AAAA record low level API query", I assume it's common. I get the same error.
Later edit: ISE 2.6 patch2 does not have this issue.
I've attached a screenshot with the correct flow.
The endpoint is landing on default rule which is an Access-Accept with a dACL with deny ip any any.
ISE sends a CoA for the unknown device type to cisco-device based on the profiling exception action (first time profiling) and the reauth is sent afterwards by the switch that basically doesn't change anything (the session lands on the same Default profile).
Still, after ISE gets CDP info and changes the profiling policy of the endpoint (from cisco-device to cisco ip phone) it will send another CoA so the session lands on a more specific authorization profile (voice domain permissions).
I'm running 2.4 patch 11 and i'm having this issue. (you mentioned p11 appears to be ok).
I have a profile policy and specify coa=reauth (global settings = no coa) When I make my test profile and refresh context/visibility and verify my device gets the new profile - I see no reauth in the live logs. This would also utilize a different authZ policy hence changing the SGT and i see the SGT stays the same.
If I got to radius - live sessions and force a coa - i see the reauth and the SGT updates because of the new AuthZ policy. But the newly applied profile with coa=reauth does nothing. Which is annoying because I'm adding 10-20 switches a weekend and have a default MAB policy for stuff to get permit access until I get all the profiles created. And this default policy applies an SGT of 'unknown'. Ideally I can go through my profiles and create/modify appropriately - see my devices get the correct profile - a CoA is issued and now the device uses the correct AuthZ rule applying the correct SGT. having to go to switches and 'clear auth session' is annoying.
I do have a TAC case opened. I'll report back if anything interesting comes of it.
Sorry to hear that it's not working for you. To be honest I don't know if your setup would ever work.
When the global CoA setting is 'No CoA' sending of CoA is supressed no matter what or at least this is my understanding based on the user guide:
No CoA (default)—You can use this option to disable the global configuration of CoA. This setting overrides any configured CoA per endpoint profiling policy.
I can confirm. The same issue on 2.4 Patch10. After opening case at Cisco TAC they confirm the problem:
CSCvs05437: ISE 2.4p10 Conditional CoA ignored due to duplicate CoA upon EndPoint Identity Group change:
CSCvr98395: No profiling CoA for ip based profile policy:
Recomendation was to install latest Patch11 on ISE 2.4.
After installing Patch11 CoA is trigger properly. Problem solved !